A problem that hides in plain sight
A process engineer starts the day with a familiar request: a piece of equipment on last night’s production line exceeded its monitoring threshold, and the manager wants the root cause within half an hour.
He opens SCADA to check trend changes, switches to MES to dig through batch records, goes to LIMS for inspection data, and finally searches the shared drive for a post-mortem document from a similar incident two years ago. Half an hour passes. He is still piecing data together. Which upstream shared measurement point feeds this equipment? Who owns it? Where is the relevant process specification, and which Word document contains it? None of this information is lost. It has just never been brought together and managed in one place.
This is an ordinary morning. It is also a story that plays out every day on industrial shop floors.
Data is not the problem. From DCS to PLC, from SCADA to MES, and on to LIMS, EAM, and ERP, industrial enterprises have accumulated vast amounts of data over the past two decades. What users often lack is a way to systematically manage the information that already exists across the plant floor. Equipment relationships, the business meaning of parameters, and historical fault attributions were never lost. They were just never treated as information assets worth maintaining centrally.
Where the problem comes from
To understand the problem, start with a more basic question: what is an industrial site made of?
Which plants, workshops, production lines, and pieces of equipment does an enterprise own? How are these levels organized? What measurable parameters does each piece of equipment have, what are their units, and what are their normal ranges? How do pieces of equipment relate to each other: which is upstream, which is downstream, which is the backup, and which measurement points are shared? The same metric may use different names in different systems and among different teams. How do you reconcile them? What Events have occurred on this equipment historically? What Real-Time Analyses are attached to it? What documents are associated with it?
Tie all of this together and you have the complete digital representation of a factory. In most plants, that complete information structure has never been built.
First, each industrial object’s information is split across systems. A single fan exists as dozens of tags in SCADA, one row in the asset system, one symbol on the P&ID, and one QR code in the inspection app. Every system believes it manages that fan. No system can show the full picture.
Second, relationships between industrial objects are rarely maintained explicitly. Measurement point A’s anomaly is usually caused by equipment B. A shared measurement point serves three production lines. Two adjacent pumps are mutual backups. These connections are not absent. They live in engineers’ heads, in the footnotes of process manuals, or in a column of an Excel spreadsheet.
Third, the business semantics and context of data are not managed effectively. An engineer can look at the number 4.7 on a screen and interpret it because they carry the equipment’s operating context in their head. But an external system, an upper-layer application, or an AI model sees only a floating-point number. Making data understandable to more people and more systems cannot be solved by collecting more data.
What is Industrial Ontology?
TDengine’s Industrial Ontology is a unified semantic layer between the data storage layer and the data application layer. It does not store raw data itself. Instead, it builds a semantic network on top of raw data that AI, applications, and people can understand, access, and use.
It consists of three parts:
- A unified data portal for AI, applications, and people;
- A global data map and catalog;
- A data association network that carries business semantics.
It gives every object in the factory an identity, makes relationships explicit, and attaches business semantics to data.
The Industrial Ontology that TDengine builds contains multiple layers of information architecture.
The foundation is the data source and storage layer. Industrial Ontology itself does not store raw data. In industrial environments, SCADA, DCS, OPC, and other industrial systems continuously generate raw monitoring signals. TDengine uses TDengine TSDB, its high-performance time-series data engine, to collect and store these massive data volumes.
Above this sits the core of the Industrial Ontology: the data model layer. TDengine defines the information structure of digital objects in the industrial world across four dimensions:
- Industrial objects, the entities that need to be managed and accessed in industrial scenarios, including elements, attributes, real-time analyses, events, metrics, panels, analysis models, and business rules. In TDengine’s Industrial Ontology, every physical or logical asset in the industrial environment, such as a plant, production line, piece of equipment, or sensor, is represented as an element. Elements are the fundamental building blocks of Industrial Ontology. Elements contain Attributes. Attribute changes trigger real-time analyses, which in turn generate events. Elements have statistical metrics and visualization panels. They can also have associated business rules and analysis models.
- Object relationships, the reference connections between industrial objects. Between elements, there are strong references, weak references, composite references, and other relationship types. Attributes are attached to elements or events. Between attributes, there are calculation references and limit associations. Analyses and events connect to elements and attributes through “references,” and link the monitoring-to-alerting chain through “triggers” and “generates.” Templates and instances connect through “derivation,” enabling “define once, apply everywhere.” Beyond these reference relationships, elements also have production process relationships, control and redundancy relationships, and impact propagation relationships, such as upstream/downstream flows and interlocks.
- Decision actions, the actions and tasks that elements and events can trigger, such as alerts and notifications, internal operations, and external commands. TDengine converges all execution capabilities that can “change the state of reality” into globally managed action templates.
- Access control, permission management for resources within the Industrial Ontology. Different users and agents have different security-level access and management permissions for different resources. Specific sensitive operations have clearly defined process loops, such as Human-in-the-Loop.
Above the data model layer is the information organization layer. TDengine uses a tree model to build the asset hierarchy skeleton and a graph model to fill in the cross-level lateral relationships. Only when the tree model and graph model are overlaid do you get the complete Industrial Ontology.
The data service layer transforms the Industrial Ontology’s information into three types of externally available data services:
- Data catalog shields the complexity of underlying data, making data discoverable, searchable, and governable;
- Data context gives every numerical value its business semantics (unit, range, ownership, operating condition), making data understandable;
- Data standards perform automatic multi-source data transformation, ensuring global consistency of data standards and statistical definitions.
These data services are delivered to external consumers through the information consumption layer. People access data through zero-code web interfaces and natural language queries. AI agents traverse Industrial Ontology and invoke platform capabilities through Model Context Protocol (MCP). External systems and applications integrate data through REST APIs, SDKs, and message queues. Different consumers use different channels, but they share one semantic model.
TDengine’s Industrial Ontology
TDengine reorganizes decades of industrial software best practices: the tree handles the hierarchy skeleton, and the graph fills in the lateral relationships. Overlaid, they form a digital mirror rooted in the real industrial world, oriented toward industrial operations analysis and decision-making, and usable by both AI and people. This is the foundation of TDengine All-in-One, which combines the TDengine TSDB time-series engine with the TDengine IDMP semantic layer.
Tree model: the asset catalog
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 makes a key upgrade over traditional tree structures: it allows “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. For many industrial projects, once the tree is built, most Industrial Ontology work is in place.
Hierarchical ownership relationships between elements, through strong references (parent-child ownership), composite references (inseparable composition), and weak references (cross-perspective views), support the flexible organization of multiple asset management trees. Other objects in the industrial scenario, such as real-time analyses, panels, and events, can all be mounted on different nodes of this asset catalog for quick user access.
Graph model: what the tree cannot cover
Object relationships on the plant floor go far beyond “what hangs under what.” Cross-level, cross-branch connections cannot be expressed by a tree. TDengine uses object types and references to manage these relationships centrally. Each reference is a directed, semantically labeled triplet.
To make configuring object relationships easier, TDengine provides preset reference types for different object types through the enumeration sets mechanism. Users can select from these directly in the TDengine interface, or create and edit new relationship types based on their own business scenarios.
Production process relationships describe the flow of material, information, and energy between equipment, including feeds / feed-by, upstream-of / downstream-of, and measures / measure-by. For example, if equipment A’s output feeds directly into equipment B, configuring a single A feeds B reference captures it.
Control and redundancy relationships describe control chains and backup relationships between equipment, including controls / controls-by and interlocks-with. For example, if equipment A shutting down forces equipment B to shut down as well, configuring A interlocks-with B captures it.
Fault impact and propagation relationships describe how faults travel between pieces of equipment, including affects / affects-by and redundant-with. For example, if an anomaly in equipment A propagates to equipment B and causes B’s process parameters to deviate, configuring A affects B captures it.
Industrial Ontology turns these previously vague object relationships into standardized semantics that are configurable, queryable, and traversable by AI. With it in place, during root cause analysis, AI can trace back along explicit relationship links and labels layer by layer, knowing not just “who is related to whom,” but also “what type of relationship” and “what may have caused it.” The more complete this information network, the deeper AI can go, and the more accurately it can help pinpoint root causes.
Below is a fragment of an asset tree rooted at “Primary Processing Workshop,” where the same shared airflow measurement point appears under different process sections via Weak References:
/Elements/Cigarette Factory 1
└── Primary Processing Workshop
├── Line A
│ ├── Vacuum Conditioning Section
│ ├── Drying Section
│ │ ├── Thin-Plate Dryer-01 ← Composite Reference / Strong Reference
│ │ │ ├── Outlet Moisture (Attribute)
│ │ │ ├── Inlet Temperature (Attribute)
│ │ │ └── Steam Pressure (Attribute)
│ │ └── Shared Drying Airflow Point ← Weak Reference
│ └── Flavoring Section
├── Line B
│ └── Drum Airflow Drying Section
│ └── Shared Drying Airflow Point ← Weak Reference (same Element, different path)
└── Cut Tobacco Conditioning Line
└── Shared Drying Airflow Point ← Weak Reference (same Element, third path)
On top of this tree, rendering all reference relationships explicitly produces a directed network carrying multiple types of business semantics. The same object can appear from multiple perspectives, but underneath there is only one copy of the data and one copy of the semantics. Template changes propagate to all instances along derivation relationships.
Business value of Industrial Ontology
Turning scattered objects and relationships into an explicit, traversable network structure unlocks three capabilities: one for AI, one for the application platform, and one for the business.
For AI: making complex task automation possible. Every time AI understands, answers, finds, or drives action on the plant floor, it is traversing Industrial Ontology. The thirteen AI assistants covered in the companion IAR article all depend on this tree and network: the Data Query Assistant locates elements along the asset tree and finds metrics through attribute references; the Root Cause Analysis Assistant traces back layer by layer along “Event > Associated Element > Triggering Attribute > Upstream Shared Point > Upstream Element”; the Panel Insights Assistant pulls engineering units, upper and lower limits, and historical averages through Panel-to-Element reference relationships. The more structured the Element asset tree and the more explicit the relationship network, the more complex the tasks AI can take on: describing phenomena, diagnosing anomalies, pinpointing root causes, predicting impacts, and making recommendations.
For the application platform: giving AI and data applications a safety guardrail. Every object and every reference has a creator and a version, making them traceable. Permissions can be configured at the granularity of Elements, subtrees, and references: which roles can see which assets, which AI agents can traverse which relationship paths, and which Attributes are readable or writable. AI agents no longer need indiscriminate access to the entire database. They work within authorized, trusted subgraphs. Unauthorized access is rejected. With these guardrails in place, enterprises can let AI participate in more complex tasks, from root cause analysis and impact assessment to operational recommendations and controlled closed-loop workflows.
For business management: capturing expert knowledge. One of the most valuable assets in a factory is the map inside an experienced engineer’s head: which upstream measurement points to check first when this equipment acts up, where the bottleneck usually is when that production line slows down, and which similar fault happened two years ago. Historically, nearly all of this knowledge existed as tacit knowledge. When the person left, the knowledge left with them. After this map is embedded into Industrial Ontology, upstream/downstream relationships, backup equipment, related documents, and similar Events are connected to the object through references. When a new employee opens an Element, they do not see a few isolated curves. They see an organized operational overview. Knowledge captured at Plant A can be replicated to similar equipment at Plant B through templates. When expertise shifts from depending on individuals to depending on a system, an industrial organization’s knowledge assets can begin to accumulate.
Turning vague business information into AI-ready digital assets
Back to the engineer’s morning. If the platform had a fully built Industrial Ontology, he would not need to switch systems, screens, or search for filenames. Open the detail page for that equipment: which measurement point is upstream, which Real-Time Analyses are associated, what similar Events have occurred historically, and where the relevant process specifications are. All of it is connected to the equipment node through references. He does not need to assemble the information manually because the complete map is already built.
Industrial Ontology does not look like a single feature. It has no dedicated page and no standalone entry point. But TDengine product capabilities are built on top of it: Visualization Panels pull data from it, Real-Time Analyses trigger on it, Events are generated on it, AI reasons and analyzes on it, and system permissions are allocated through it.
Industrial Ontology is not just a standalone module of TDengine. It is the semantic foundation of TDengine’s product capabilities. Where the semantic foundation reaches, TDengine’s cognitive boundaries and system capabilities extend.
