A plant running OSIsoft PI has 3,000 historian tags updating at sub-second intervals. The process engineer who configured the system can write a trend query in under two minutes. The afternoon shift supervisor, who makes production decisions when that engineer is off site, has never opened the PI client. This is not a skills gap. It is a product design gap: PI was built for people who understand control systems, not operators trying to determine why throughput dropped.
SCADA systems and their historian platforms are excellent at their intended work: collecting high-frequency time-series data from field devices, triggering alarms when values cross configured limits, and giving engineers tools to examine process behavior. That design brief does not include answering production questions for non-engineers. The capability was never part of the original design.
What SCADA Does Well
Modern SCADA platforms are sophisticated infrastructure. A well-configured Ignition installation can handle thousands of PLC tags across multiple production lines, maintain a historian archive, send alarm notifications by email or SMS, and provide real-time visualization through a web-based client. The data fidelity is strong. Sub-second timestamps, configurable retention policies, and hardware-level redundancy options are standard capabilities.
For a controls engineer or industrial automation specialist, this can be a complete tool. The query language is learnable. Alarm management can be configured down to individual tag conditions. Trend analysis is visual and reasonably intuitive for someone who already understands the underlying process.
For an operator responsible for throughput and quality on a specific line, rather than control theory, the system is largely inaccessible.
The Interpretation Layer That Is Missing
Between raw time-series data and a production decision sits an interpretation step. It requires knowing which data matters to the question and how to translate values and trends into operational terms. SCADA provides the data. A process engineer, or experienced operators who learned the system over years on the floor, has traditionally provided the interpretation.
This creates a structural dependency: operators with data questions rely on a small number of people who can interpret the data. In plants with 24-hour production schedules and engineering staff working standard hours, that dependency becomes a gap during second and third shift. A maintenance event associated with a production drop during a Thursday night shift may not be analyzed until Friday morning, after the conditions have changed and the window for a preventive decision has passed.
The missing layer is not more data. Plants already have enough. What they need is a translation mechanism between historian tag values and the question an operator or supervisor is asking.
What a Real Query Looks Like Without This Layer
A shift supervisor sees that Line 2 throughput dropped 12% in the last two hours and needs to understand what happened. In a plant without a translation layer, the path to an answer involves several steps:
- Phone the process engineer. The call, callback, and review take 20 to 30 minutes in the best case. Off-hours requests may wait until the next day.
- Open the historian client and manually compare the production drop with a sensor trend. This means knowing which tags to review, how to read the trend, and how to access and use the system. Most supervisors have access, but lack the SCADA knowledge to search efficiently.
- Open the CMMS and review maintenance events from the last two hours. This is only partial: it shows what maintenance logged, not how monitoring data matched the production drop.
- Accept that day shift will identify the root cause and focus on maintaining current output.
Supervisors most often choose the last option, not from indifference, but because finding an answer takes long enough that keeping operations moving comes first.
Where the Translation Sits
The missing interpretation layer is not another dashboard. Dashboards remain visual interfaces that require viewers to understand what they are seeing. The bridge between historian data and operational decisions is a query interface that accepts questions as operators naturally ask them and returns answers in terms of production significance, not tag values and timestamps.
"What happened to Line 2 throughput in the last two hours?" is different from "show me the SP-THRU-02 trend from 14:00 to 16:00." Both questions seek the same information, but only one is accessible to a supervisor without SCADA training. A translation layer can read the historian, correlate it with maintenance records, and return a plain-language summary of what the data shows. That is the capability SCADA was never designed to provide.
Tendrel's role in this architecture is the translation step. We connect to historian sources such as PI and Ignition, read relevant tag values and alarm logs, and return answers grounded in what those systems recorded. We are not replacing SCADA. SCADA continues doing its intended work, and the data quality it provides is the foundation for a useful interpretation layer.
What This Does Not Solve
Historian data quality varies by site. Poorly configured alarm limits, tags that have not been recalibrated since installation, and archive gaps during network events all affect the quality of a translation layer's answers. If the underlying data is unreliable, translating it into plain language does not make it reliable.
The translation layer addresses access, not data quality. Plants with clean, well-tagged historian data will see better results than plants whose tag hierarchy reflects years of ad-hoc additions without consistent naming conventions. This is not an argument against better data access. It is a reason to be clear about which problem you are solving first.
SCADA and historian platforms will remain core data infrastructure for most manufacturing facilities for the foreseeable future. They are mature, reliable, and embedded in plant operations. We are not saying SCADA is limited. We are saying the missing interpretation layer should make its data accessible to everyone who needs to act on it.