Data Has Grown, But Understanding Has Not
Industrial systems today generate more data than ever before. Sensors continuously stream high-frequency signals from every part of the operation, covering everything from temperature and pressure to vibration, flow, and equipment state. Modern infrastructure has largely solved the challenges of storage and throughput, and even large-scale analytics is no longer out of reach.
And yet, despite this progress, a fundamental problem remains. The availability of data has increased dramatically, but the ability to understand that data has not kept pace.
A single data point, taken in isolation, rarely carries meaning. A temperature reading of 85°C may indicate normal operation in one context and a serious issue in another. Without knowing which asset it belongs to, what process is active, and under what conditions the data was generated, the value itself is ambiguous. This gap is not caused by insufficient data or compute capacity, but by the absence of structure and context.
The Tag-Based Model and Its Limitations
For decades, industrial data systems have relied on a tag-based model. Data is stored as a collection of time-series signals, each identified by a tag name, timestamp, and value. This approach works well for data acquisition and storage. It is flexible, efficient, and relatively easy to implement at scale.
However, the model was never designed to support how industrial systems are actually understood and operated. Engineers do not think in terms of tags. They think in terms of equipment, systems, and processes. A pump, a boiler, or a production line is not defined by a single signal, but by a set of interrelated variables and behaviors.
When data is organized purely as tags, engineers are forced to reconstruct this context manually. They must determine which signals belong to which asset, how those signals relate to each other, and what the system is actually doing at any given moment. As the scale of the system increases, this reconstruction becomes increasingly difficult, and the gap between data and understanding continues to widen.
Reframing the Model Around Assets
Asset-centric modeling fundamentally changes the starting point of how industrial data is organized. Instead of treating individual signals as the primary unit, it begins with the assets themselves—equipment, systems, and process units—and organizes data as a representation of those real-world entities. Data is no longer just something that is collected; it becomes something that belongs to a system. A temperature reading is no longer just a tag, but the temperature of a specific boiler, reactor, or compressor. A pressure value is no longer an isolated number, but part of a process operating under specific conditions at a specific moment in time.
At first glance, this may appear to be a change in data structure, but in reality it changes how the system understands data. In a tag-based model, signals exist independently, and their relationships are implicit. Engineers must rely on their own knowledge or external documentation to interpret how signals are connected and what they represent. In an asset-centric model, those relationships become part of the model itself. The structure of the equipment, the attributes associated with each asset, and the relationships between signals are explicitly defined rather than inferred.
This is the point where the data model begins to align with the physical reality of industrial operations. Engineers do not approach problems by thinking about tags; they think in terms of systems—pumps, lines, and processes—and how those systems behave over time. By organizing data around assets, the system adopts the same perspective. Data is no longer a collection of values, but a structured representation of how the system is built and how it operates.
This shift also changes how industrial systems scale. In a tag-based model, scaling often means adding more signals, more dashboards, and more configuration. Each new asset introduces additional complexity, and consistency becomes difficult to maintain. In an asset-centric model, assets can be abstracted, standardized, and reused. A pump is not just a set of tags, but a defined model with attributes, calculations, and monitoring logic that can be applied across multiple instances. As the system grows, it scales through models rather than through configuration.
For this reason, asset-centric modeling is not simply about organizing tags under equipment. It represents a deeper transition — from treating industrial data as a collection of signals to treating it as a representation of systems. Only when this transition happens does data become something that can be consistently understood, reused, and ultimately leveraged by advanced analytics and AI.
What PI Got Right—and Where Modern Systems Fall Short
It is worth noting that this idea is not entirely new. Systems like PI System introduced the Asset Framework years ago, and it remains one of the most valuable components in the historian ecosystem. By organizing data around equipment and processes, PI Asset Framework allows engineers to move beyond raw tags and work with a model that reflects how industrial systems are actually structured.
This was a significant step forward. It addressed one of the most fundamental problems in industrial data: the lack of context. Many engineers who have used PI extensively will recognize that the Asset Framework is often where real value begins to emerge, not just in storing data, but in understanding it.
However, when we look at modern data infrastructure—data lakes, warehouses, and streaming platforms—we see a different picture. These systems are extremely powerful in terms of scalability, compute capability, and analytical flexibility. They can process massive volumes of data and support sophisticated analytics pipelines.
But they are not designed to model industrial systems. They treat data as generic records—rows, columns, and events—without a native understanding of assets, equipment relationships, or operational structure. As a result, the responsibility of building context is pushed back to the user. Engineers must recreate asset hierarchies, define relationships, and maintain consistency across systems, often through custom logic and external tooling.
This creates a fundamental gap. On one side, traditional historians understand industrial context but are limited in openness and scalability. On the other side, modern data platforms are powerful and flexible but lack the ability to represent industrial systems in a meaningful way.
The result is that neither approach, on its own, provides a complete solution for OT engineers.
Context as a First-Class Concept
The real value of asset-centric modeling lies not in the hierarchy itself, but in the context it provides. Once data is anchored to assets, the system gains an understanding of where data originates and how different signals relate within a piece of equipment or across a process.
This makes it possible to standardize how systems are modeled and analyzed. Instead of building dashboards and logic for each individual asset, engineers can define reusable models that apply across similar equipment. A pump, for example, can be defined once with its attributes, calculations, and monitoring logic, and then applied consistently across an entire fleet.
This consistency is not just an efficiency gain. It is what makes large-scale industrial systems manageable. Without a consistent model, every new asset introduces additional complexity. With it, systems can scale without losing clarity.
Why Context Becomes Critical in the AI Era
The importance of context becomes even more apparent when AI is introduced. AI systems do not operate on raw data alone; they rely on structured and meaningful input. When signals are presented without context, they appear as independent numerical sequences, making it difficult to identify patterns or distinguish between normal and abnormal behavior.
By organizing data around assets, the system provides the structure AI needs to interpret the data correctly. Relationships between signals become explicit, comparisons across similar equipment become possible, and patterns can be evaluated within the correct operational context.
This is why asset-centric modeling is not simply a modeling choice. It is a prerequisite for making industrial data usable in an AI-driven environment.
Structure Alone Does Not Capture Behavior
At the same time, asset-centric modeling does not fully capture how industrial systems operate. It provides a structured view of what exists, including equipment hierarchies, attributes, and relationships. However, industrial systems are not static. They evolve over time, and their behavior is defined by sequences of events.
A pump starts and stops. A batch begins and completes. A system enters an abnormal state and later recovers. These changes are not fully represented in a static asset model. They require a way to describe how the system behaves over time, not just how it is structured.
This highlights the next step in industrial data modeling. If asset-centric modeling answers the question of what exists, it does not fully answer the question of what is happening.
The Next Step: From Structure to Behavior
To fully understand industrial operations, data models must move beyond structure and begin to represent behavior. This requires introducing a model that captures meaningful time-based changes in the system, such as operations, transitions, and anomalies.
This is where event-centric modeling becomes essential. Events define what happens, when it happens, and how it relates to the underlying assets. They provide the missing layer between raw signals and operational understanding.
Industrial data is not just a collection of time-series signals. It is a representation of systems operating over time. Asset-centric modeling provides the foundation for understanding those systems. Event-centric modeling builds on that foundation to explain how they behave.
That is the direction we will explore next.
