For AI to take hold in the factory, the key is not just the model. The key is a runtime environment where AI can read industrial data, operate system tools, and stay inside clear safety boundaries.
A dialog box is not AI adoption
Over the past two years, a common pattern has appeared across industrial software: vendors add a large language model to an existing product as a chat window. The platform stays the same. Users type natural language, the system forwards it to the LLM, and the LLM returns an answer. In marketing terms, the product now has Chat BI.
In practice, many users stop using it within a month.
The problem comes down to three disconnects.
First, a disconnect in data semantics. A general-purpose AI looking at a bare number like temp_3 = 245 cannot tell what parameter it represents, what its unit is, what its normal range is, which equipment it belongs to, or which upstream and downstream measurement points it relates to. The business context of industrial data is scattered across engineers’ experience, process manuals, and inconsistent naming conventions across systems. AI receives the data, but it cannot read it.
Second, a disconnect in system capabilities. A conversational AI can output “we recommend checking the bearing,” but it cannot query trend data, create a monitoring panel, configure a Stream Processing rule, or trigger root cause analysis on its own. Once it answers, every operational step still has to be done by a person. AI can talk, but it cannot act.
Third, a disconnect in trust. Large language models can hallucinate. When they lack relevant knowledge, they may assemble answers from weak or fabricated context. In a consumer setting, this is easy to shrug off. In an industrial setting, one wrong analytical conclusion can stop a production line or waste materials. AI sounds confident, but the system still has to prove why it should be trusted.
These disconnects are not an implementation detail specific to one vendor. They are a structural flaw in the “build the platform first, bolt on the LLM later” approach. When a system was never designed with a place for AI, the AI added afterward stays on the surface. It can generate text, but it does not reach business meaning or operational capability.
Escaping this dead end does not require only a stronger LLM. It requires a different system architecture. That architecture must answer four questions:
- Can AI access and understand data directly?
- Can AI call system capabilities directly?
- Can industry knowledge be retrieved and cited during AI reasoning?
- Can AI complete actions autonomously within its permissions?
If the answer to any of these is no, AI inside that platform remains a surface-level chat component.
TDengine’s answer is to treat AI from the start as a consumer of data, an operator of systems, and a user of applications. On top of the high-performance time-series engine in TDengine TSDB, TDengine IDMP builds the semantic and operational layers needed for industrial AI. Industrial Ontology attaches business context to data and answers: “Can AI understand the data?” On top of Industrial Ontology sits Industrial Agent Runtime (IAR), which answers the other three questions in one place: “Can AI call system capabilities?”, “Can AI retrieve knowledge?”, and “Can AI execute actions under control?”
IAR: turning AI from a guest into the host
IAR (Industrial Agent Runtime) has a clear position: it does not build a large language model, and it does not ship a built-in LLM service. Instead, it works above LLMs to do two things: help AI understand industrial context, and keep AI behavior under control.
Making AI understand the industry. General-purpose AI does not adapt well to the factory floor because the industry’s most valuable knowledge, including process manuals, operating procedures, historical fault cases, and the judgment of experienced engineers, usually does not live on the public internet. It sits in internal files, maintenance records, and people’s heads. IAR’s Knowledge Base management lets enterprises upload process manuals, operating procedures, equipment maintenance guides, and historical fault cases, then indexes them automatically. When answering questions, running root cause analysis, or interpreting data, AI can draw on the enterprise’s actual processes instead of guessing from general knowledge. The Skills mechanism goes a step further: it codifies industrial experience into standardized workflows that AI can call. The procedure an experienced engineer uses to judge compressor surge can be defined as a Skill. After that, any engineer who invokes it can have AI follow the same playbook. The Knowledge Base defines the basis; Skills define the method.
Keeping AI under control. A chat assistant that gets one answer wrong usually does limited harm. An industrial AI that misreads a process parameter or misjudges equipment state can create lost materials, downtime, or safety risk. IAR builds its safety and governance framework around four dimensions: controllable, trustworthy, auditable, and resilient.
Thirteen AI assistants: the complete chain of industrial data consumption
Traditional industrial data platforms rest on a deeply rooted assumption: users are expected to write code. Querying data means writing SQL. Building a panel means configuring a data source. Doing analysis means writing Python. Setting up alerts means understanding a rules engine. The people who actually need answers from the data, process engineers, equipment supervisors, and shift leaders, are locked out. It is not that they cannot analyze. They are kept away from the data by technical tools.
TDengine ships thirteen AI assistants, each focused on a specific task. Together they cover the plant-floor data workflow, from querying data to writing reports. Users describe what they need in natural language instead of writing code.
Scenario 1: Data query and panel creation
“Show me the outlet moisture trend of the dryer from 10 PM last night to 2 AM, add steam pressure and shared airflow, and put the three lines together.” In tens of seconds, the curves are overlaid and the suspect range narrows. “Turn these lines into a real-time Trend Chart with a target value and reference lines.” The Panel is generated and published automatically. The experience changes from “ask IT to write SQL and wait days” to “say one sentence and get the chart in tens of seconds.” This is not just an efficiency gain. It changes who can see and use the data.
Scenario 2: Analysis task and alert configuration
“Check the steam pressure average every 5 minutes. If it drops more than 0.05 MPa over the past 10 minutes, generate a Major alert Event and notify the on-duty engineer.” This request is translated into a Stream Processing task, with the trigger type, window parameters, and Output Attributes configured, then created and enabled. Alert quality depends on how close the rule author is to the plant floor. Give this work back to the people who know the process best, and missed alarms and false alarms can both decrease.
Scenario 3: Anomaly detection and forecasting
Many anomalies show signs before any value crosses a limit: small fluctuations over several days, swings that grow day by day, or values that remain inside the normal Threshold while the pattern changes. Traditional alerts may never react. Anomaly detection does not only ask whether a value exceeded a limit. It analyzes how the data pattern changes. Forecasting goes further by projecting future behavior from history and warning before the problem occurs. Threshold alerts tell you that a limit was exceeded. Anomaly detection tells you that something looks off. Forecasting tells you that trouble is likely next.
Scenario 4: Root cause analysis
The most time-consuming part is not finding the anomaly. It is working out how the anomaly propagated. The root cause analysis assistant can start when an alert Event fires and trace back layer by layer along the equipment relationship network already built into Industrial Ontology: which upstream equipment the anomaly relates to, whether similar equipment showed anomalies during the same period, and whether the Knowledge Base contains a relevant historical case. Each step is recorded and evidence-based, and the result is a structured investigation report that moves from what happened to why it happened.
Scenario 5: Event query and comparative analysis
“All Major-level steam pressure fluctuation events over the past year” returns a complete list in seconds. “Overlay the impact on Line A and Line B during the same fluctuation to compare” gets it done in one sentence. Comparison is not for looks. It is for finding the pattern, the gap, and where to act first.
Scenario 6: Health assessment, metric calculation, and report generation
Health assessment tracks the operating state of every piece of equipment, produces a score and a degradation trend, and maintenance resources follow the data. Metric calculation turns composite business metrics such as OEE and energy efficiency ratios into standard assets in the system that stay updated. Report generation strings these capabilities into one action. “Generate the operating report for the drying section of Line 3 for last week” automatically brings charts, analyses, events, and metrics together into a structured report. People’s time should go to reading reports and making decisions, not to assembling data and formatting layouts.
Extending assistant capabilities: knowledge base, skills, and custom AI functions
TDengine ships an industrial knowledge management system for private enterprise knowledge. It centralizes process knowledge, turns accumulated experience into reusable AI Skills, and lets users build personalized AI Functions on top of those Skills.
Knowledge Base management
Enterprises can upload Word, PDF, Markdown, process drawings, on-site photos, and other documents directly to the matching equipment node inside TDengine. The system parses and indexes the content semantically and builds a Wiki-style knowledge graph without manual keyword tagging or classification. This knowledge graph is connected to Industrial Ontology. Upload a fan fault case to a fan, and it can be linked to other fans of the same model, similar equipment in the same workshop, and the upstream measurement points and downstream process steps involved in the same fault. Knowledge stops being an isolated file and becomes a node in the larger Industrial Ontology network. More importantly, every AI feature in TDengine searches this enterprise Knowledge Base first. Only when no relevant information is found does it fall back to general knowledge, keeping AI answers grounded in the factory’s real experience.
Skills management
A skill is a Markdown document. It requires no programming, only natural language, and describes a complete business scenario and operating procedure. A skill is different from a Prompt: a Prompt is an instruction sent to an LLM, while a skill is a standardized task flow with execution requirements that the system manages, versions, and reuses. Once uploaded, an AI agent can execute it step by step in the matching business scenario. TDengine ships a skills management framework for creating, editing, testing, publishing, rolling back, and versioning skills. TDengine also ships validated general-purpose skills. Each of the thirteen AI assistants covered in this article is assembled from multiple skills. Enterprises can upload custom skills to build workflows around their own equipment characteristics and management processes. Every skill can be public or private, and it can be assigned to a specific LLM, so different AI tasks can run on the model that fits them best.
Personalized AI Function configuration
Users are not limited to the built-in AI assistants and skills. In the TDengine admin console they can create their own AI Functions: choose the model to connect to, upload custom skills, configure preset Prompts and output rules, set whether other users can see them, and decide whether they appear in the dropdown menu of an analysis button on a page. The built-in AI Functions are validated base capabilities and cannot be edited, while user-created AI Functions can be modified and iterated at any time. That lets every enterprise and every team build its own AI capabilities instead of passively using a fixed set of vendor-preset features.
From seeing to acting: the last mile of AI adoption
The thirteen assistants described above solve the seeing and understanding side. They make data accessible, analyzable, and interpretable for more people across the plant.
But the value of industrial AI does not stop at seeing. At 2 AM, a piece of equipment goes abnormal, and nobody is standing in front of the big screen. An alert rule is configured. The system sees the anomaly and sends a notification. Then what?
The on-duty engineer receives the notice and still has to log in, pull up the trend chart, judge the severity, and decide whether to dispatch someone. The notification went out, but the action chain is not complete. Between seeing a problem and solving it sits a gap that has been ignored for twenty years.
TDengine’s Real-Time Analysis engine defines what “then” means when a Stream Processing rule fires. The analysis creation form has a built-in Action section. When the condition is met, the configured action executes automatically. The current release supports notification actions including email and Telegram, managed centrally in the Libraries through contact channels and Action Templates.
In the longer-term plan, the Action Library brings every capability that issues instructions to the outside world into unified Action Templates governed by risk levels from L0 to L4. L0, the information class notifications,reports, can run fully automatically. L3, the production-impact class adjustingalertthresholds, requires human review. L4, the on-site command class startingorstoppingequipment,invokingaPLC, requires human review plus a second confirmation. AI, automation, and people trigger the same action through the same approval flow. Actions at medium risk or above cannot run fully automatically, and a timeout never releases them. Getting from seeing to acting is not about adding a notification button. It is about moving “and then what?” out of people’s heads and into the system’s execution chain.
Industrial AI safety boundaries: controllable, trustworthy, auditable, resilient
The trustworthiness of enterprise AI does not come from the AI being naturally reliable. It comes from the AI being embedded in a runtime environment that is governable, controllable, and traceable.
Controllable
The agent sandbox runs every AI agent in an isolated environment where it cannot access the underlying database directly. Inherited identity permissions mean an agent has no separate identity of its own. Its permissions on every call are exactly those of the user who started it. Data the user cannot see, the AI cannot see either, and the sandbox enforces this at the tool-call layer. Two-layer guardrails inject ontology context and permission boundaries at the Prompt layer, then re-check every operation before it runs at the tool-call layer. The code of conduct presets three boundary types: may complete autonomously, requires human confirmation, and must never be delegated. Task safety levels follow risk: low-risk tasks execute autonomously, medium-risk tasks require user confirmation, and high-risk tasks require Human-in-the-Loop.
Trustworthy
AI’s reasoning path is confined within the information structure of Industrial Ontology. Deviations are rejected. Every conclusion must state its data source, analysis path, and ontology node, and it is cross-validated against the ontology before output. Output that references no ontology object is labeled “not bound to an industrial object” and cannot drive downstream actions.
Auditable
IAR records every key node of an agent workflow, from task triggering, Skill invocation, and LLM interaction to tool execution and user feedback, forming a complete evidence chain. Logs cannot be tampered with.
Resilient
The TDgpt time-series AI engine runs independently of external LLMs. Anomaly detection, forecasting, and missing data imputation do not depend on an external AI service. Once created, AI-generated Panels and Real-Time Analyses keep running without the AI. Even if external LLMs are unavailable, data ingestion, storage, querying, stream processing, and alert notifications continue independently. AI is an enhancer, not a dependency.
Openness is the ecosystem: AI is not private property in a closed kingdom
“The thing we fear most when choosing a platform is being locked in.” Spend years moving your data and processes into a system, then find you cannot connect new tools and cannot export data for analysis. The cost of switching becomes too high to switch at all. TDengine defines its understanding of openness through a series of don’ts.
No tightly coupled architecture
Every component deploys independently. Customers can replace the matching modules with their existing collection tools, the BI tools they already know, or their own model services. Nobody gets locked to a vendor.
No built-in LLM
The LLM market changes too fast. IAR connects uniformly to mainstream LLMs, and enterprises choose for themselves. DeepSeek today, GPT-5 tomorrow: models can change, while data, capabilities, and configuration stay in the platform.
No data silos
JDBC/ODBC connects to BI tools. A native Excel plugin lets business users query directly. Kafka/MQTT supports real-time data subscription and publication. Data should flow freely to every place that needs it, carrying its full business semantics.
No closed system
Through MCP (Model Context Protocol), more than 50 system capabilities are exposed to external AI agents as standardized tools. Remotely, agents can query Elements along semantic paths, retrieve Events, create analyses, and generate Panels. The CLI serves scripting and automation, and the REST API is fully described by the OpenAPI specification. Any external program or AI agent can call the platform’s full capabilities in a standard way.
No deployment restrictions
Deployment options include fully managed public cloud AWS,Azure,GoogleCloud,andAlibabaCloud, on-premises deployment across a broad range of operating systems and CPU platforms, and edge-cloud collaboration where the edge keeps running independently through a network outage and re-syncs when the connection is restored.
No black boxes
Page operations can be reviewed as backend SQL. Skills can be edited. The Knowledge Base can be read online. The full model training and inference process is traceable.
Every open capability above shares one precondition: matching permissions. Role permissions are fine-grained down to the Element level, and API keys, MCP, and CLI all run under the permission framework. The more thorough the openness, the stricter the management.
On a closed platform, every new requirement becomes a wall. On an open platform, every new requirement can become a new channel. For decades, industrial software has often been built as a platform first, with features added later. Every addition becomes another patch on an architecture that reserved no real place for AI. TDengine chose to put AI at the center of the architecture from the start. How much AI can do depends not only on the model, but also on how much room the platform gives it. That room is IAR: an industrial runtime environment that takes AI out of the dialog box and into real productivity.
IAR is TDengine’s enterprise-grade runtime environment for industrial AI. It connects uniformly to mainstream LLMs. Through the Knowledge Base and Skills, it turns tacit industrial knowledge into digital assets AI can call. It ships thirteen out-of-the-box AI assistants covering the full chain from data query to report generation, and it builds a safety and governance system around four pillars: controllable, trustworthy, auditable, and resilient. Here, AI is not an added-on dialog box. It is native to the architecture as a consumer of data, an operator of systems, and a user of applications.
