Root cause analysis
The investigation starts before the engineer does
When a plant event is recorded, the first hour is mostly gathering — trends, related tags, last time this happened. That work is mechanical, and TDengine can run it before the engineer opens the event.
What that hour looks like on TDengine
On TDengine, an investigation starts from the event and does that hour before anyone has to: recent history for the asset, the statistics, the manuals you attached, likely causes tested against the measurements, and a structured report — typically within a few minutes once the asset model, relationships and LLM connection are in place. Plant manuals and failure history make the result yours, not a generic guess.
What makes the result more than a correlation exercise is the asset model underneath it. Relationships your engineers encode — what feeds what, what controls what, how a fault affects neighbouring equipment — are the paths an investigation can follow. Without those links, the analysis has the event’s own tags and public technical references, not a process chain.
Workflow
Eight steps from event to report
The mechanical hour: retrieve the traces, see what else moved, look up what the equipment is supposed to do, test the likely causes, and hand the engineer a report they can argue with.
Intent recognition
The system reads the event context and determines the analysis goal.
Element confirmation
The associated asset, device identity, occurrence time and symptom are taken from the event.
Data retrieval
SQL is generated to fetch time-series for that element around the event — typically the last ten days in TDengine’s documented workflow, not the whole archive.
Data exploration
Python analysis runs on the retrieved series to find outliers, trends and correlations.
Knowledge retrieval
When manuals, SOPs and failure history are loaded on the asset, TDengine’s AI features search that plant knowledge first. Public technical references and known failure modes for this equipment type are the fallback — and are what the built-in event RCA works from where no plant knowledge has been loaded.
Hypothesis decomposition
The problem is split into one or more candidate causes.
Hypothesis verification
Each candidate is tested against the actual measurements. Hypotheses the data contradicts are discarded.
Report generation
A structured Markdown report: overview, timeline, data findings, ranked causes with evidence, and recommended actions for the engineer to judge.
Prerequisites
What has to be true before this is worth switching on
An investigation assistant is only as good as the context beneath it. These four conditions decide whether the output is useful or merely fluent.
Reliable tag history
Signals landing in TDengine TSDB at a resolution that can actually show the sequence of a fault. An investigation cannot resolve cause and effect from data averaged into fifteen-minute buckets.
Relationships, not just hierarchy
The asset tree alone is not enough. Process flow, control and fault-impact links should be encoded, because those are the paths an investigation can walk to find candidate causes upstream.
Documents attached to assets
Manuals, SOPs and past incident reports on the assets they describe. Without them, knowledge retrieval has public technical references and general model knowledge — not your plant’s own precedent.
A deep-reasoning model configured
IDMP uses a fast model for everyday queries and a separate extended-reasoning model for investigations. Both are set up in the AI connection, and either can be self-hosted. RCA sends retrieved tag windows and document excerpts to that endpoint — choose local hosting if nothing may leave site.
The same fault, with and without context
An illustration of how the pieces interact. A water pumping station raises an event: discharge pressure has drifted low.
Without context, an assistant sees one tag falling. It can report what the value did, when, and by how much. Every explanation beyond that is a guess, because nothing tells it what else is connected to that pump.
With an asset model, the investigation can reach the equipment around the pump — upstream reservoir level, the suction-side valve, the motor, the standby set — rather than a single orphaned tag. Those links exist only if they have been encoded, and the built-in event analysis still begins with the asset’s own measurements before following them.
With the knowledge base loaded, AI Chat and the investigation search the pump manual and the SOPs attached to that asset first — the expected operating envelope, the procedure for low discharge pressure — and fall back to general references only where your own documents have nothing to offer. A post-mortem you attached earlier can surface as precedent, rather than precedent being invented.
What the engineer opens is a report: an overview, a timeline, the data findings, ranked causes with the evidence behind each, and recommended actions. The judgement is still theirs. The first hour of searching is not.
Skills
Encoding your own diagnostic sequence
Built-in assistants cover general analysis patterns. The valuable procedures are usually specific to your plant and currently exist only as verbal handover.
TDengine calls these skills: a procedure written in plain language, describing the steps to follow, the basis for each judgement, and the expected output. The system versions them, tests them and manages their lifecycle, which is what separates a skill from a prompt someone retypes each time.
A shift leader’s sequence for assessing an abnormal condition — check this relationship first, then compare that trend over 24 hours, then decide whether an adjustment is needed, then notify according to severity, then file the case for the next shift — becomes something any shift can invoke. The experience stops belonging to one person.
Writing these with your engineers is part of what we deliver. It is also what earns the team’s confidence, because the assistant then follows a procedure they already agree with.
Limits
What this does not do
An investigation assistant has real boundaries. These are the three that matter most once it is in daily use.
It does not decide
The output is a ranked set of hypotheses with supporting evidence. Acting on a plant is an engineering decision with safety consequences, and it stays with a person.
It cannot invent context
Relationships that were never encoded are paths it cannot follow. Documents that were never loaded are precedent it cannot find. The model quality is not the limiting factor — your asset model is.
It needs validation
Replay incidents your team already understands and compare conclusions before relying on it. An assistant that gets known answers right earns the benefit of the doubt on unknown ones.
Frequently asked questions
How long does an AI root cause investigation take?
TDengine reports a structured investigation report typically within a few minutes of launching it from an event detail page. The documented workflow retrieves a recent window of data for the event’s asset (typically the last ten days), explores it statistically, looks up technical references, then tests hypotheses. Plant manuals and failure history improve the result when they are loaded on the asset; they are not assumed to be present.
What has to be in place before root cause analysis is useful?
Four things: tags landing reliably in TDengine TSDB; an asset model — hierarchy plus the relationships between equipment, not just the tree; the relevant manuals, SOPs and failure history attached to those assets if you want plant-specific precedent; and a deep-thinking language model configured. Skip the model and documents and the analysis has only a recent window of tags and public technical references to work with.
Does root cause analysis need a different model to normal queries?
Yes. IDMP uses two models from one connection — a fast, inexpensive model for everyday natural-language queries and panel generation, and a separate deep-reasoning model invoked for extended analysis such as root cause investigation. Both are configured in the AI connection.
Can we encode our own troubleshooting procedure?
Yes. TDengine calls these skills: procedures written in plain language that the system versions and reuses, so an AI assistant follows them step by step. A shift leader’s diagnostic sequence becomes something any shift can invoke, rather than knowledge that leaves with the person.
Should we trust an AI root cause report?
Treat it as a prepared investigation, not a verdict. It should be validated against incidents your team already understands before anyone relies on it, and the report is structured to show the evidence behind each hypothesis precisely so an engineer can check the reasoning rather than accept a conclusion.
Validate this against an incident you already understand
The most useful first engagement is usually replaying a fault your team has already diagnosed, and checking whether the model and documents produce the same answer.