In one of my recent LinkedIn articles, I argued that asset-centric visualization is a much better fit for industrial operations than generic dashboarding. What pushed me to write it was not just product positioning. It was a comment from Andy Robinson of ConSynSys Technologies that captured the issue in very practical terms: industrial users do not want a workflow where every time they add a tag, they need to decide how to aggregate it, where to place it, and how to interpret it. He also made a deeper point in the discussion that I think deserves more attention: the real moat in industrial software is domain expertise.
That is exactly right.
In industrial settings, the challenge is rarely just collecting data or drawing charts. The challenge is turning large volumes of operational data into something that people on the plant floor, in reliability teams, and in operations centers can actually use. And that is where many generic dashboard tools fall short. They are flexible. They are visually capable. They can connect to many data sources. But flexibility is not the same thing as fitness for purpose.
Industrial users do not think in terms of disconnected tags.
They think in terms of real equipment, process areas, and production systems.
They think in terms of Boiler 3, Compressor A, Cooling Loop 2, Inverter Station 17, Packaging Line 4, or Chiller Pump B. They want to click into that asset and immediately see the temperatures, pressures, states, events, alarms, trends, and analysis that matter for that specific piece of equipment. They want to see the asset in context, not as a bag of unrelated signals.
That sounds obvious, but it has major implications for how industrial visualization should be designed.
The problem with starting from tags
Many dashboard tools effectively start from the signal. The workflow usually looks something like this: search for a tag, drag it into a panel, pick the aggregation, format the chart, then repeat the process for the next point. That can be fine for exploration or ad hoc monitoring. It is much less effective when you are trying to build something operationally durable.
Why? Because the meaning of the dashboard is not encoded in the system. It is encoded in the head of the person who built it.
That person knows that these five tags belong together because they all describe the feedwater section of a boiler. They know that one signal should be shown raw, one should be averaged, one should be correlated against a temperature rise, and another should only matter when the unit is in a certain operating state. They know that a current spike combined with a pressure drop means something very different from either signal alone.
But that knowledge is usually not native to the dashboard itself. It sits in tribal knowledge, local conventions, and undocumented design choices.
That is why generic dashboards often become hard to scale in industrial environments. One engineer builds one version for one site. Another engineer copies it and tweaks it for another site. A third person changes labels, time windows, or thresholds. Six months later, the company has thirty dashboards that all look similar, but behave slightly differently. Everyone is technically looking at data, but not always in a consistent or trusted way.
Industrial systems need operational structure
A historian for industrial use should do more than plot time-series signals. It should reflect how industrial operations are actually organized.
That means the system should understand assets, hierarchies, subsystems, attributes, calculations, and events. It should understand that a pump belongs to a skid, a skid belongs to a line, and a line belongs to a plant. It should understand that a boiler has subsystems such as air, fuel, steam, and feedwater, and that each of those subsystems has measurements, limits, derived calculations, and event conditions that matter to different users.
This is where asset-centric visualization becomes much more powerful.
With TDengine Historian, the core idea is that the asset becomes the primary organizing principle. The user does not start with a pile of signals and ask, “What can I build?” The user starts with an operational object and asks, “What should I see for this asset, and how should this information be organized so that operators, engineers, and managers can all use it effectively?”
That is a very different design philosophy.
It means the dashboard is no longer just a surface for charting. It becomes an operational view tied directly to real equipment and real workflows.
Why templates matter so much
This becomes even more important when you think about repeatability.
Industrial environments are full of repeated equipment classes. Ten similar boilers. Fifty similar pumps. Hundreds of inverter stations. Thousands of meters. A system that requires each one to be configured manually is not really industrial-grade from an operational deployment perspective.
That is why reusable templates matter.
In TDengine Historian, you can define templates not only for the asset or element itself, but also for the surrounding operational model: panels, dashboards, analyses, events, and notifications. That means you can define what a boiler should look like once, including its hierarchy, its key attributes, its standard views, its calculations, and its event logic, and then apply that to all similar boilers.
The benefit is not just speed. It is consistency.
Every similar asset can follow the same logic. Every operator sees the same key views. Every engineer works from the same baseline. Every site inherits the same operational model unless there is a reason to override it.
That is how industrial software should scale.
A boiler room example
Take a boiler room as a practical example.
In a generic dashboarding environment, someone might manually assemble charts for furnace temperature, steam outlet pressure, return air flow, fan speed, valve positions, and feedwater flow. They might build one page for Boiler 1, then copy it for Boiler 2, then adjust a few tags, then copy it again for Boiler 3.
At first, that seems manageable.
But over time, small inconsistencies start creeping in. One dashboard uses a five-minute average. Another uses raw data. One labels a flow point differently. Another omits a related pressure tag. One has a threshold line. Another does not. One panel was updated after a process change, but the copied versions were not.
Now imagine instead that the boiler is modeled once as an asset type. Its subsystems are defined. Its key attributes are attached. Its standard calculations are included. Its event logic is configured. Its standard operator view, engineer view, and maintenance view are templated.
Now Boiler 1, Boiler 2, and Boiler 3 are no longer just copies of a dashboard. They are instances of a repeatable operational model.
That is a much stronger foundation.
Why this matters even more in renewables and distributed operations
The value becomes even clearer in distributed industrial environments.
Take a renewable operator managing hundreds of inverter stations or battery energy storage units across multiple sites. In those environments, inconsistency kills efficiency. If each site has different dashboards, different naming conventions, different calculations, and different event handling logic, then troubleshooting becomes slower, training becomes harder, and trust in the system starts to erode.
An asset-centric approach solves that much more naturally.
You define the inverter model once. You define what should be visualized, what should be calculated, and what should trigger attention. Then you deploy that same framework across all similar assets.
Now when a performance engineer opens Inverter Station 17 at Site A and Inverter Station 42 at Site B, the experience is consistent. The structure is familiar. The views are comparable. The event logic is aligned. You can still support site-specific variation where needed, but the baseline remains governed and repeatable.
That is not just better visualization. That is better operations.
Context is what makes data useful
This is also why asset-centric visualization is fundamentally about context.
If a pump trips, users need more than a trend line. They need to know which pump it was, what upstream and downstream conditions looked like, whether a valve state changed first, whether motor current spiked, whether the event has happened before, and whether similar assets elsewhere have shown the same pattern.
In other words, they need the data to arrive already connected to operational meaning.
Generic dashboarding often makes users reconstruct that meaning themselves. Asset-centric systems make it part of the design.
That difference matters a lot in the real world. It changes how quickly users can diagnose a problem, how consistently teams interpret data, and how much cognitive load the system imposes during day-to-day operations.
Why AI works better on top of an asset model
This same principle becomes even more important as AI enters industrial software.
There is a lot of excitement right now about AI-generated dashboards, AI-assisted analysis, and natural-language interfaces. But AI only becomes truly useful in industrial environments when it has context.
If AI is operating on nothing but raw tags, it can generate charts, summaries, and suggestions, but those outputs are limited by the lack of structure. It does not inherently know whether a signal belongs to a boiler, a pump, or an inverter. It does not automatically know which related attributes should be considered together. It does not know which events matter operationally unless that knowledge is encoded somewhere.
That is why TDengine’s ability to generate panels with AI and provide AI-generated panel insights becomes much more meaningful in an asset-centric model. AI is no longer guessing over disconnected signals. It is working on top of a structured representation of the industrial environment. It knows the asset, the surrounding measurements, the relevant calculations, and the broader operational context.
That makes the output more relevant, more actionable, and more aligned with how industrial teams actually work.
In my view, this is one of the most important differences between an AI demo and an AI capability that can hold up in production. Industrial AI needs context. Asset-centric systems provide it.
The deeper takeaway: domain expertise wins
This brings me back to Andy’s other point: domain expertise matters more than ever.
As models get more capable, the advantage shifts away from simply being able to build software and toward understanding what the user in a specific domain actually needs. In industrial operations, that means understanding that engineers often want a fast way to locate tags, compare related signals, move from equipment to trends, interpret events in context, and work from familiar operational structures rather than raw data abstractions. That perspective came through clearly in Andy’s comment on your article.
That is why asset-centric visualization is not just a UI preference. It is a reflection of industrial domain knowledge. It acknowledges that the unit of meaning in industrial operations is usually not the tag. It is the asset, the subsystem, the process, and the event.
Software that understands that will be much easier to use, much easier to scale, and much more valuable over time.
Final thoughts
Generic dashboards are useful. They have a place. They are good at flexible charting and broad connectivity.
But industrial teams need more than charting.
They need a system that mirrors how operations are actually structured. They need repeatable models for similar equipment. They need context attached to every view. They need analytics and events connected to the asset. And increasingly, they need AI that can generate useful panels and insights based on that operational model rather than on disconnected signals alone.
A generic dashboard can show data.
An asset-centric historian should show the condition of a real asset, in the right context, with the right views, analysis, events, and insights already attached.
That is the difference.
