Asset context
Context is the work. The AI is the easy part.
Pointing IDMP at a language-model endpoint is the quick part. Giving it a plant worth reasoning about takes engineering: an asset model that mirrors your site, the relationships between equipment written down, and the documentation your team has accumulated finally attached to the assets it describes.
What gives a raw tag its meaning?
A raw tag value carries no meaning. temp_3 = 245 does not say what is being measured, in which unit, on which machine, what counts as normal, or what sits upstream of it. TDengine IDMP supplies that meaning through an asset model: a hierarchical tree carrying the structure of the plant, plus a relationship network describing the connections a tree cannot express.
On top of that model you attach the plant’s documentation. IDMP parses and indexes each file so AI features can search them by asset, and associates the entities it extracts with the assets — links we verify during the load. When an AI feature is asked about an asset, it searches this knowledge first and only falls back to general knowledge if nothing relevant is found — which is why answers come back in your plant’s terms rather than in generic ones.
Tree and network
The hierarchy is the easy half
Site, area, line, equipment, measurement point — most operators can produce that structure from existing documentation. The relationships are what carry the engineering knowledge, and they are almost never written down anywhere.
Process flow
feeds, upstream-of, measures
How material, energy and information move between equipment. Lets an investigation walk backwards up a process chain.
Control and redundancy
controls, controls-by, interlocks-with
Which asset commands which, and what is forced to trip with it. Distinguishes a control action from a process disturbance.
Fault impact
affects, affects-by, redundant-with
How a fault travels, and which asset stands in as backup. Encodes the paths an experienced engineer walks when a symptom appears downstream of its cause.
A hierarchy tells you a pump belongs to a pump station. It does not tell you that this pump’s discharge pressure depends on upstream reservoir level, suction valve position and the duty pump it alternates with. That knowledge normally lives in a process engineer’s head and is applied from memory during troubleshooting. Encoding it as directed, typed relationships is what lets an investigation trace a real process path instead of correlating unrelated tags.
The same asset can also appear in more than one tree — a geographic view for operations, an equipment-class view for maintenance — pointing at one underlying object with one copy of the data. Different teams navigate the way they think, without anything being duplicated.
Knowledge base
How documents actually attach
Where a document attaches determines how much of this is a one-off effort and how much grows with your asset count.
Attach to an element
Documents specific to one physical asset — its calibration history, the incident report for a failure it suffered, a photograph of an as-built modification.
Attach to a template
Documents that apply to an entire equipment class. A manual for a pump model attaches once to the template, and every element built from that template inherits it. This is what keeps a large site maintainable.
Parsed on upload
Word, PDF, Markdown, process drawings and site photographs are parsed and indexed automatically. You do not need a keyword taxonomy upfront — files are parsed on upload. We still check that documents land on the right assets and templates.
Linked back to assets
IDMP extracts equipment names, fault types, operating steps and parameters from documents and suggests links to asset-model objects. We verify those links during load — a manual attached to the wrong pump is worse than no manual.
Recurring incident reports can be refined a step further into a structured case library — symptom, location, cause category, remedy, time to resolve, and prevention — so a new event can be matched against precedent rather than re-investigated from scratch.
Delivery
How we build it
Encoding relationships and loading documents are the first things a rushed project drops, and the two that decide whether the AI layer is worth having.
Model the assets
Build the asset model from your real plant structure: hierarchy, templates for repeated equipment classes, engineering units, limits and categories. Templates matter — they are what make a 400-pump site tractable.
Encode the relationships
Work through process flow, control and fault propagation paths with your process and maintenance engineers. This is the step most often skipped, and the one that decides whether root cause analysis can reason or only correlate.
Load the knowledge
Collect the manuals, SOPs, drawings and incident reports that exist and attach them at the correct element or template level. A structured case library — symptom, cause, remedy — is optional follow-on work if you want precedent matching, not something that happens when you upload a PDF.
Wire the language model
Connect an OpenAI-compatible endpoint — hosted or on-premises — configuring both an everyday query model and a deep-reasoning model for investigations. Set permissions before the agent is exposed to anyone.
Write the skills
Capture your own troubleshooting procedures as versioned skills so a specific plant’s judgement sequence is reproducible across shifts, not dependent on who is on duty.
Validate against known events
Replay incidents your team already understands and check the conclusions. An investigation assistant earns trust by getting known answers right before anyone relies on it for unknown ones.
Beyond AI
The model is worth building without the AI layer
Modelling the assets, limits and relationships changes how engineers use the historian day to day. None of what follows depends on an AI feature being switched on.
Navigable data
Engineers find a signal by walking to the asset, instead of knowing which table and tag name holds it.
Templated dashboards
Panels defined once on a template appear for every asset of that class, rather than being rebuilt per site.
Meaningful events
Limits and rules live with the asset, so an event carries engineering units, thresholds and the element it belongs to — not a bare tag name.
Retained knowledge
Experience stops leaving with people. When a long-serving engineer retires, encoded relationships and attached documents preserve more of what they knew — if those were modelled.
Frequently asked questions
What is the asset model in IDMP?
The plant structure IDMP uses to give tags meaning. It has two parts: a hierarchy (site, area, line, equipment) and typed links between equipment — what feeds what, what controls what, how a fault spreads. Together they let people and AI search by asset instead of by table name.
Why do asset relationships matter more than the hierarchy?
A hierarchy tells you a pump belongs to a pump station. It does not tell you that the pump’s discharge pressure depends on upstream reservoir level and downstream valve position. Those associations usually live in a process engineer’s head. Encoding them as typed relationships is what allows an investigation to trace back along a real process path instead of correlating unrelated tags.
What file types can be attached to an asset?
Word documents, PDFs, Markdown, process drawings and site photographs are parsed and indexed on upload. You do not need a keyword taxonomy upfront. IDMP extracts equipment names, fault types and operating steps from the documents and suggests links to the corresponding assets; we verify during load that documents land on the right assets and templates.
Do documents attach to every asset individually?
Not necessarily. Documents can attach to an element template as well as to an individual element, so a manual that applies to every pump of a given model is attached once to the template rather than repeated across hundreds of assets.
We have no document set worth loading. Is this still worth doing?
The asset model and relationships deliver value on their own — navigable data, templated dashboards, contextual events and better natural-language querying. The knowledge base then improves as documents are added. In practice most plants have more material than they expect, scattered across shared drives and filing cabinets; the harder part is usually collecting it rather than creating it.
Start with the asset model, not the AI demo
We scope your asset hierarchy, agree which relationships to encode first, and review the documentation you already have to load as a knowledge base.