General-purpose AI has read public information on the internet, but it has never seen your factory floor. It does not know the operating procedures for your equipment. It has never seen the post-mortem report for that failure. And it cannot interpret the judgment an experienced engineer makes from twenty years of work on the line.
TDengine’s knowledge management system turns private knowledge scattered across filing cabinets, shared drives, and people’s heads into enterprise assets that are manageable, reusable, and continuously accumulated. These assets can be used by people and called by AI Agents. When knowledge is managed systematically, it moves from personal memory to an enterprise asset that can keep appreciating in value. This makes knowledge management a core capability of TDengine All-in-One, where TDengine TSDB and TDengine IDMP work together for industrial data operations.
Knowledge lies scattered everywhere, never managed as an asset
Any factory that has been running for more than ten years has accumulated a large amount of business knowledge and experience.
Process engineers know the business meaning of every measurement point. Equipment managers can estimate remaining bearing life from the shape of a vibration curve. A shift leader may recognize a pattern after three anomalies. Process manuals record standard operating procedures. A folder on the shared drive holds the post-mortem reports of the past five years. The experience in a long-time employee’s head can identify an anomaly the moment it appears.
This knowledge exists. It has just never been brought together and managed in one place. Process manuals are locked in filing cabinets. Operating procedures sit on one department’s shared drive. Failure cases are scattered across engineers’ personal folders. Experiential judgment lives in people’s heads. When an experienced engineer retires, more than twenty years of accumulated experience may leave with them. New employees start from scratch and repeat the same mistakes. The same problem happened two years ago, was analyzed, and was solved, but the report cannot be found, or nobody knows it ever existed, so the problem plays out again.
TDengine’s knowledge management system takes the valuable knowledge an enterprise has accumulated and moves it from scattered to centralized, from tacit to explicit, and from personal memory to enterprise asset.
This knowledge management system is also a prerequisite for AI to work in industrial scenarios. For AI to answer questions about the factory and execute complex analysis tasks, it first has to know the factory. It needs to know what each piece of equipment is, what each parameter means, and what procedure to follow when an anomaly occurs. This private information can only be provided by the enterprise itself.
Five forms of knowledge, one management system
Knowledge management is not a new concept. Since the 1990s, the industry has used a clear theoretical framework. Knowledge is often divided into two broad categories: explicit and tacit. Explicit knowledge can be written into documents and compiled into manuals. Tacit knowledge lives in people’s heads, shaped by experience and intuition. The two need a conversion mechanism. Tacit knowledge is externalized into explicit knowledge. Explicit knowledge is combined into a system. Internalization then turns it back into new tacit judgment. Cycle after cycle, knowledge assets accumulate. Industrial research goes further, describing enterprise knowledge in progressive forms: raw data, structured information, patterns extracted from information, and reusable technical components. Each layer requires a different method of processing and extraction.
These theories all point to one core conclusion. Knowledge is not a single form. Different types of knowledge take different shapes, and each needs to be extracted, organized, and managed differently according to the specific use scenario. Tacit knowledge needs to be made explicit. Data knowledge needs to be standardized. Information knowledge needs to be structured. Pattern knowledge needs to be formalized. Technical knowledge needs to be modeled.
But on the industrial shop floor, knowledge management has lacked a systematic, productized platform to run on. How do you make an experienced engineer’s judgment explicit? How do you structure scattered failure cases? How do patterns learned from data become callable models? How does AI execute a complex operating procedure step by step?
TDengine’s knowledge management system answers these questions through five management mechanisms for five typical forms of industrial knowledge. Industrial Ontology manages data semantics and object associations. The Knowledge Base manages document and case assets. Calculation Expressions manage experiential rules. Analysis models manage patterns and regularities learned from data. Skills capture complex multi-step management procedures.
Data knowledge: helping AI understand every number
A bare number like temp_3 = 245 means nothing to AI. What parameter does it represent? Is the unit Celsius or Fahrenheit? What is the normal range? Which piece of equipment does it belong to? What measurement points upstream and downstream does it relate to? What events has it triggered historically?
TDengine uses Industrial Ontology to manage this kind of knowledge. Industrial Ontology is a unified semantic layer between the data storage layer and the data application layer. It does not store raw data itself. On top of raw data, it builds a semantic network that AI, applications, and people can understand, access, and use.
The core of Industrial Ontology is a two-layer information structure of “tree plus network” built around industrial objects. The tree model carries the hierarchical skeleton. Open TDengine and the first thing you see is an asset catalog tree: Group > Plant > Workshop > Production Line > Process Section > Equipment > Measurement Point, cascading level by level. Most daily operations revolve around this tree. TDengine supports “multiple trees coexisting, sharing the same instance.” The same fan can appear simultaneously under a geographic tree, an operational responsibility tree, and an equipment type library, with only one underlying object and one copy of the data. The graph model fills in what the tree structure cannot cover. Relationships on a factory floor go far beyond “what hangs under what.” Cross-level, cross-branch connections cannot be expressed by a tree. TDengine uses object types and reference types to manage these relationships centrally. Production process relationships describe the flow of material, information, and energy between equipment (feeds, upstream-of, measures). Control and redundancy relationships describe control chains and backup relationships between equipment (controls, interlocks-with). Fault impact and propagation relationships describe the paths a fault takes between pieces of equipment (affects, redundant-with). Every reference is a triplet with a direction and business semantics.
The tree tells AI “what this is and what it belongs to.” The network tells AI “what it relates to, what it affects, and what it is affected by.” Overlaid, the two form a digital mirror rooted in the real industrial world, one that both AI and people can operate.
Take a chemical plant’s distillation column as an example. The bottom temperature measurement point has clear process associations with four parameters: reflux ratio, feed temperature, overhead pressure, and reboiler heat load. A temperature swing may mean something went wrong on one upstream path. In the past, these associations lived in the process engineer’s head, and troubleshooting meant checking them one by one from experience. Now, Industrial Ontology connects these five attributes with explicit reference relationships. When AI performs root cause analysis, it can trace back along this relationship network. It is no longer guessing from isolated values. It is reasoning along the business paths the engineer built.
Document knowledge: turning the filing cabinet into a searchable knowledge graph
Every factory has a large number of business documents: process manuals, operating procedures, equipment maintenance guides, historical failure cases, and shutdown post-mortem reports. These documents hold valuable operating experience, but they are scattered across filing cabinets, shared drives, and departmental folders, hard to search and disconnected from each other. An engineer looking for a three-year-old post-mortem report might have to search four shared drives and ask three senior colleagues, and still not find it after half a day.
Building an enterprise knowledge base from documents and extracting a knowledge graph from it is a mature technology. The core flow is straightforward: parse unstructured document content through semantic analysis into vectorized representations, extract entities and relationships, and build a knowledge network that supports semantic retrieval and reasoning. Search engines, intelligent customer service, and enterprise knowledge management platforms have used this technology at scale for years.
TDengine brings this technology to industrial scenarios. An enterprise uploads Word, PDF, Markdown, process drawings, site photos, and other documents to the corresponding equipment nodes. The system parses and indexes the content and builds a vectorized knowledge graph, with no manual keyword tagging or classification. Entities in the documents, such as equipment models, fault types, operation steps, and process parameters, are extracted and linked to the corresponding objects in Industrial Ontology.
More importantly, this knowledge system is connected to Industrial Ontology. Upload a fan failure case to a fan, and it can link to other fans of the same model, similar equipment in the same workshop, and the upstream measurement points and downstream process sections involved in the same fault. Knowledge is no longer an isolated file. It becomes a node in the Industrial Ontology network. When an engineer opens a piece of equipment’s detail page, the relevant process manuals, operating procedures, and historical failure cases are already attached to the equipment node as references. The documents find the people who need them. TDengine’s AI features search this enterprise Knowledge Base first, and fall back to general knowledge only when nothing relevant is found.
Enterprises can also refine documents into structured case assets according to their business scenarios. An electronics factory’s SMT pick-and-place line sees first-piece defects on many product changeovers. The team refined three years of changeover anomaly post-mortems into a “changeover anomaly case library.” Each anomaly type maps to one structured record: anomaly symptom, work station, root cause category, remedy, handling time, and prevention suggestion. When the next changeover runs into an anomaly, AI can match the most similar historical case and push it to the field engineer. What used to take half a day of digging through documents can take seconds. Once a complete failure case library is built, its value goes beyond retrieval. New employee training, process improvement, and equipment selection can all build on this case asset.
Rule knowledge: turning experience into calculation expressions embedded in business flows
A large amount of operating experience can be abstracted into “if-then” conditional expressions. If a condition is met, execute an action. If compressor discharge pressure stays above 0.85 MPa for more than 5 seconds, generate a surge warning event. If the average transformer voltage exceeds 235V, notify the operations group. If the batch injection temperature drifts outside the normal envelope in the second half, trigger a quality warning.
In a traditional architecture, editing and deploying this kind of business rule often requires a separate rules engine. An enterprise has to deploy Drools, EasyRules, or another rules engine component, define a rule language, write rule scripts, and manage the integration between rules and business systems. It becomes a separate stack, and creating or modifying a rule requires IT involvement. Business users can only submit a request and wait in the queue for a development slot.
TDengine does it differently. It embeds the calculation expression mechanism directly into analysis scenarios such as real-time analysis, event management, and action execution. No separate rules engine. No extra middleware. In the creation form for real-rime analysis, business users can define trigger conditions, Event filter rules, output calculation rules, and action execution conditions directly with expression syntax like attributes['avg_voltage'] > 235. Expressions are configured with zero code. Any element in Industrial Ontology, and any attribute’s current or historical value, can be an input to an expression. An engineer does not need to write code to turn a piece of business experience into a monitoring rule that runs continuously.
This expression mechanism covers several key scenarios. The trigger rule of a real-time analysis decides when the analysis starts. The output rule defines what result the analysis produces. An event’s notification rule controls when a notification is sent, to whom, and the minimum interval between notifications. An action’s execution rule decides whether a preset action runs after a trigger. All rules are visible, verifiable, editable, and auditable. Rules are no longer hidden in code. They are exposed in the interface in a form business users can read and modify.
Take a cement plant’s rotary kiln process engineer. He has a piece of experience. If the kiln tail temperature rises more than 15°C within 30 minutes and the kiln head negative pressure drops more than 50Pa at the same time, ventilation inside the kiln has a problem and the grate cooler needs to be checked. In the past, this rule was only passed on verbally at shift handover. Now, he configures an event-window trigger rule in real-time analysis. The start condition is exactly this compound judgment expression, and the end condition is the parameter returning to normal. In the second week after the rule went live, it caught the precursor to a broken grate plate on the grate cooler and prevented a kiln shutdown.
Model knowledge: extracting patterns and regularities from massive data
Rules can express known experiential judgment, but some problems cannot be solved by rules.
Rules can handle deterministic logic like “alert when temperature exceeds 85°C.” But when the question becomes “will this equipment fail in the next week,” “is the quality of this batch stable,” or “is this energy consumption trend normal fluctuation or an anomalous signal,” the answer is no longer something a single threshold can give. It requires extracting the hidden patterns and regularities in historical data and using them to make quantitative inferences about the future.
This is where analysis models come in.
An analysis model is a computational process that applies statistics, mathematical theory, and quantitative methods to process data and output a quantitative prediction. Starting from a set of input variables, it uses the internal structure and parameters learned during training to output one or more quantitative results: a predicted value, a classification label, or an anomaly score. A model does not use rules written directly by people. It uses patterns and regularities that algorithms learned from data.
The process by which an analysis model learns regularities and patterns from data is called Machine Learning. Its basic logic is not complicated. Feed the model a large number of historical samples, where each sample contains input features and a desired output target. The model keeps adjusting its own parameters so the error between its predictions and the real results gets smaller. After enough iterations, the model learns the mapping between inputs and outputs. It captures patterns behind the data, and when it faces new data, it can often give reasonable predictions.
Machine Learning is one of the most mature and widely applied branches of artificial intelligence. From financial risk control to weather forecasting, from recommendation systems to medical diagnosis, analysis models are used across many industries. In industrial scenarios, predictive maintenance, quality anomaly detection, energy consumption optimization, and capacity forecasting all rely on different kinds of analysis models. The algorithm lineage spans classical statistics (ARIMA, Holt-Winters, exponential smoothing), traditional Machine Learning (Random Forest, XGBoost, SVM), deep learning (LSTM, Transformer, CNN), and recent time-series foundation models (PatchTST, TimesFM).
Machine Learning training comes in two broad modes. Supervised Learning requires labeled samples. Every training sample needs both input features and a known real result, and the model corrects its parameters by comparing its own predictions with the real results. This is common in scenarios with historical labeled data, such as training a fault prediction model from historical failure records. Unsupervised Learning needs no labels. The model discovers structure, identifies patterns, and finds anomaly points that deviate from normal behavior directly from the data itself. This matters especially in industrial scenarios, because many factories have never systematically labeled their historical data as “normal” or “fault.” Unsupervised anomaly detection can learn the characteristics of normal operation directly from data and recognize moments that do not look right.
TDengine lands this mature analysis model methodology on industrial time-series data with two core components: TDgpt and TDmodel.
TDgpt is the time-series data analysis engine built into TDengine TSDB. It consists of four components. The built-in analytics library integrates mature statistical algorithms such as statsmodels, pyculiarity, and pmdarima, covering classic scenarios like ARIMA and ADFuller tests. The built-in Machine Learning library ships with deep learning frameworks such as PyTorch, Keras, and scikit-learn, supporting more complex time-series modeling. The general LLM adapter module connects to external large models through an OpenAI-compatible interface, letting a large model’s reasoning ability act on industrial data. The time-series data model adapter connects to dedicated time-series models like Time-MoE and TDtsfm, solving complex pattern recognition problems that traditional statistical algorithms can struggle with. TDgpt uses a stateless design, deploys on demand, scales independently, and supports GPU acceleration. Analysis capabilities can be invoked with SQL statements, while data remains in the database.
TDmodel is the model development and management module in TDengine’s frontend application. It relies on TDgpt’s time-series analysis capability and the standardized, contextualized AI-Ready data in the Industrial Ontology, and provides a visual interface for the complete flow from data selection, algorithm configuration, model training, to model publishing. Users can manage the full lifecycle of an analysis model in one platform, without exporting data to Python, training it outside, and copying the results back.
Once training is complete, model deployment becomes a key differentiator for TDengine. A model can run directly inside the database as a SQL function.
One way is to deploy it as a UDF (User-Defined Function). Register your own model or algorithm as a UDF, then call it directly in a SQL query. SELECT my_model(temp, pressure) FROM sensor_data completes batch inference in one statement. The other way is to deploy through TDgpt as standard SQL functions, such as FORECAST(), ANOMALY_WINDOW(), and FILL_HOLE(), with unified syntax and out-of-the-box usability. Both approaches support the same principle: data stays in the database, and models run close to the data. There is no need to move data to an external model service or maintain a separate inference server. TDgpt also provides an open SDK that lets developers integrate their own algorithms or models into TDengine, after which they can be called with SQL.
This in-database computing model has direct advantages in industrial scenarios. A chemical plant’s centrifugal compressor runs under complex operating conditions, and the historical data was never labeled for faults. TDgpt learned normal operating patterns directly from two years of historical data and identified three anomalous operating intervals. Two were already known to the process team. One was an early-stage lubrication system degradation signal nobody had noticed. No labels. No Thresholds. The model found hidden patterns in the data itself. Throughout the process, the data stayed in TDengine from anomaly detection to result output.
AI support lowers the barrier to creating and deploying analysis models further. During model training, users can describe the business scenario in natural language, such as “train an energy consumption prediction model based on the past three months of data,” and AI can select the algorithm, configure parameters, and evaluate the results. During model deployment, UDFs that used to require writing and compiling C code can now be generated with one click and deployed quickly, reducing work that previously took weeks. For more complex business scenarios, users can also orchestrate multiple models and analysis steps through skills: first calling an anomaly detection model to find anomalous intervals, then a root cause analysis model to trace the cause, and finally generating an investigation report.
Process knowledge: writing complex tasks as skills
The most complex knowledge is the judgment and handling logic of a complete business process in a specific scenario: what to confirm first when equipment becomes abnormal, what to compare second, what to evaluate third, who to notify fourth, and what work order to create fifth. There are multiple steps, multiple judgment conditions, and coordination across multiple systems. This kind of knowledge has historically been difficult to manage systematically because it relies heavily on human experience and on-the-spot judgment.
Skills were created for this problem. The core idea is to encapsulate complex, multi-step task flows into standardized capability units that AI Agents can call methodically. A skill is a document written in natural language that describes the operating flow, judgment basis, and output requirements of a complete business scenario. It requires no programming. A business expert can write industry know-how into a skill.
A skill is fundamentally different from a prompt. A prompt is a temporary instruction to the large model. It often has to be rewritten, and it usually has no versioning, management, or reuse. A skill is a standardized task flow that the system manages, versions, and reuses, with lifecycle management for create, edit, test, publish, and rollback. Once uploaded to the system, an AI Agent can execute it step by step in the corresponding business scenario.
TDengine ships with dozens of validated skills covering common analysis and management scenarios on the industrial shop floor. Built on these skills, TDengine provides thirteen out-of-the-box AI Assistants: data query, panel creation, analysis tasks, alert configuration, metric calculation, anomaly detection, forecasting, root cause analysis, health assessment, Event query, comparative analysis, report generation, and document Q&A. Behind each assistant is a composition of multiple skills. The Root Cause Analysis Assistant, for example, orchestrates a series of skills: “anomaly event extraction,” “associated data retrieval,” “statistical exploration,” “knowledge retrieval,” “hypothesis validation,” and “report generation.”
Enterprises can also upload their own custom skills, tailoring dedicated workflows to their industry’s equipment characteristics and management procedures. A blast furnace foreman at a steel plant wrote the question “how do I judge and handle furnace condition anomalies step by step” into a skill.
- Check the relationship curve between blast volume and blast pressure.
- Compare the hot metal silicon content trend over the past 24 hours.
- Decide whether the coke burden needs adjustment.
- Choose who to notify based on severity.
- File the case and push it to the next shift. After this skill is uploaded, foremen on any shift can call it directly. The experience no longer belongs to one person.
Going further, TDengine lets users build personalized AI functions on pages that have data. Select the large model to connect, upload your own skills, configure preset prompts and output rules, decide whether other users can see the function, and decide whether it appears in a page’s analysis-button dropdown menu. Built-in AI functions are validated baseline capabilities and cannot be edited, while user-defined AI functions can be modified and iterated at any time. Every team can build its own combination of AI capabilities instead of passively using fixed vendor-preconfigured features.
Your knowledge, your assets
Industrial enterprises doing knowledge management cannot avoid one core concern. If valuable experience accumulated over decades is “learned” by a large model, will it leak to competitors? This knowledge and experience is a company’s core asset, not free training data for a large model.
TDengine’s position on this question is clear. Knowledge belongs to the user, not to the platform, and certainly not to a large model.
No built-in large model binding. TDengine does not bundle any specific large model service. Enterprises can choose based on their own compliance requirements and security policies: cloud large models, privately deployed large models, or a fully local model inside the plant. With local deployment, knowledge stays inside the plant, and the large model runs within the enterprise’s own data boundary. Large models can be replaced. Knowledge stays with the enterprise.
Five-level security policy. All knowledge assets in TDengine, Industrial Ontology objects, knowledge base documents, expression rules, analysis models, and skills, are system resources protected by a unified global five-level security policy: view, edit, submit a change reason when editing, second password verification, and MFA (Multi-Factor Authentication). Each resource’s security policy is configured independently and takes effect globally, independent of specific users and roles. Even a system administrator must complete secondary authentication to modify an MFA-protected Skill. A company’s most core process knowledge and fault handling experience is fully protected at the system level.
Granular permissions and audit traceability. TDengine implements granular control through a permission management system of users, user groups, and roles. Permissions can be precise down to every specific function, every element, and every piece of knowledge. Users and AI Agents in different roles have different levels of access and control over different resources. Nodes without permission are invisible to AI. Critical operations have complete audit logs, queryable by time, user, task, and element. Who changed what and when, who called which Skill, and what operation AI executed are all traceable end to end, and the logs cannot be tampered with.
Making knowledge a long-term enterprise asset
The competitiveness of an industrial enterprise has never been just equipment and capacity. It is the decades of “we know how to do this” experience accumulated on the production line. Equipment gets replaced, production lines get retrofitted, people come and go. The only thing that cannot be carried away and should not be forgotten is this experience.
But in the past, this experience existed almost entirely as tacit knowledge. It was fragile, depending on personal memory and handoff. It was scattered, across different systems, different formats, and different people’s heads. It could not be invoked. AI could not see it. New hires could not grasp it. Historical problems played out again and again.
TDengine’s knowledge management system gets tacit knowledge out of the filing cabinet, out of people’s heads, and off the shared drive, then turns it into manageable, reusable, continuously accumulated enterprise assets. Industrial Ontology gives every number business semantics. Document management makes historical experience searchable and citable. Calculation expressions turn experiential judgment into monitoring logic that runs continuously. analysis models surface hidden patterns from massive data. Skills let AI Agents execute complex handling tasks according to user-defined flows. Five forms of knowledge, one complete loop from accumulation to invocation, and one globally unified security management system.
When an enterprise’s tacit knowledge is fully managed, it no longer depends on any one person. Knowledge can be passed on, reused, and used easily by people, systems, and AI Agents. It can keep accumulating as the business evolves. Knowledge moves from personal memory to an enterprise asset that keeps appreciating in value.
