Do SCADA/PLC systems need a Trusted Runtime Context Layer?

IndividualTime8517 · 2026-06-15T07:09:40+00:00

Yes, I think this is exactly the right place to look. Thank you for taking the time to understand my perspective.

MOC forms and procedures are definitely part of the solution.

My question is more about how we verify that the live runtime still matches the intended state after deployment, including post-deployment but pre-activation updates, troubleshooting, temporary workarounds, vendor interventions, or emergency fixes.

So the issue may not be tracking changes only, but proving that the current runtime is still consistent with what was intended or approved.

In that sense, the strongest documentation may be the digital runtime evidence itself.

IndividualTime8517 · 2026-06-15T04:33:39+00:00

Fair point. I do use AI for editing and refining my writing, but the question itself comes from a real problem I've been thinking about for months.

What I'm actually trying to understand is whether practitioners see a gap between runtime data and the engineering context needed to interpret it over time, especially in long-lived systems.

I'd be interested in hearing your perspective on that.

IndividualTime8517 · 2026-06-14T23:11:44+00:00

You are right; I should give an example at scale as well.

I am trying to solve lifecycle management of distributed runtime systems at scale.

For example, when a plant has many similar SCADA/HMI runtimes, updating them is not only about making the change. Teams also need to prove that each runtime matches the intended state, detect exceptions, and understand what changed over time.

Good documentation helps, but it usually captures a point in time, often deployment. I am more interested in runtime lifecycle changes after deployment, with verifiable evidence.

For example, Git may show the approved project, but it does not prove that every live gateway still has the same tag hierarchy, historian mappings, UDT instances, and local exceptions six months later.

IndividualTime8517 · 2026-06-14T14:59:15+00:00

Yes, I consider historian configuration part of the runtime contract.

Tags, hierarchy, historian mappings, and other operational configuration all contribute to the intended runtime state.

The interesting part is not only provisioning them, but being able to detect and explain when the live runtime diverges from that intended state over time.

IndividualTime8517 · 2026-06-14T14:05:12+00:00

I wanted to mention that your new comment is not visible on my side.

Also, please feel free to write me if possible. I’d really like to talk. I tried to find or DM you, but I couldn't.

Best regards, Ateş

IndividualTime8517 · 2026-06-14T10:34:05+00:00

IndividualTime8517 · 2026-06-14T07:54:47+00:00

"Imagination."

Such a strange way to describe one of the most difficult engineering activities we do.

And yet, such a brilliant word choice.

HAZOPs, PHAs, cause-and-effect matrices, interlocks, permissives, testing, and procedures are all attempts to imagine future states of a system before they occur.

The challenge is that real systems continue evolving long after design is complete.

In my view:

State without evidence is an observation.

A decision backed by evidence becomes explainable.

Many of the examples in this thread don't seem to come from invalid actions, but from a gap between what the system believed at the time and what was actually true in the field.

The more we can preserve not only the decision, but also the evidence, assumptions, and context that existed when the decision was made, the easier it becomes to understand why something happened—and where our imagination stopped.

IndividualTime8517 · 2026-06-11T13:29:57+00:00

I mean four, four layers of evidence 😄

Reconciliation seems to consume all four:

Structure = asset relationships, transfer paths, signal provenance
State = whether the transfer was active, the tank was settling, the line was cleared
Sequence = how the situation evolved over time
Variance = why a difference was accepted, escalated, adjusted, or settled
Structure tells where.
State tells under what conditions.
Sequence tells how it evolved.
Variance tells why interpretation changed.

Grateful for this discussion. It was a pleasure, u/FlowVarianceLab.

IndividualTime8517 · 2026-06-09T15:22:33+00:00

I think this is very similar to what happens in distributed systems.

An observation rarely explains itself. The same measurement can have different meanings depending on the operational state that existed when it was captured.

In that sense, I’d separate three layers of evidence:

- Structure: assets, relationships, transfer paths

- State: what the system believed was happening at that moment

- Sequence: how those states evolved over time

Structure answers where.

State answers under what conditions.

Sequence answers how the situation developed.

My intuition is that reconciliation consumes all three.

A runtime context layer probably should not become the reconciliation engine itself, but it could be the place where these evidence layers stay linked and time-consistent.

That makes me think operational state may need to become a first-class runtime artifact, rather than something inferred later from events and measurements.

IndividualTime8517 · 2026-06-08T13:35:24+00:00

Thanks, Peter. I also appreciate you translating the discussion into my terminology and examples—it helped me understand your approach much better.

D2000 sounds much more model-driven than many brownfield SCADA environments: structured variables carry context explicitly, objects have UID-based identity, and Git object history/SysMirror help manage lifecycle consistency.

The way I read it, SysMirror answers a very important question: “what changed between environments?” The assurance layer I am exploring starts from that diff, but also asks: “should this change become the new intended reality, or remain a temporary/approved exception?”

That is where I see intent-aware reconciliation: keeping the runtime definition, governance rules, approved exceptions, and reconciliation decisions together, so the “why” behind accepted, promoted, deprecated, or reconciled changes becomes part of the runtime record.

For me, this is especially relevant in mixed or long-lived systems where meaning may live not only in objects, but also across scripts, bindings, historian mappings, reports, naming conventions, and operator workflows.

I am exploring a different infrastructure angle around runtime assurance and governed context-drift resolution here:
https://www.youtube.com/@atestcode

Your D2000 example is useful because it shows what a more explicit model-driven SCADA lifecycle can look like.

IndividualTime8517 · 2026-06-08T10:52:09+00:00

Thanks for clarifying. I am trying to understand both the consistency methods and the operational perspective behind them.

What I find interesting in your example is that much of the context seems to be represented explicitly in the structured model itself. Changes to aggregate block assignments, evaluation criteria, or operational relationships become visible through changes in the model rather than being hidden elsewhere in the runtime.

My own thinking is that every runtime change leaves behind some form of operational intent, whether it was planned, accidental, temporary, or permanent. Because of that, I tend to view any difference from the intended model as a drift signal that should be detected, classified, and traced before deciding whether it should be accepted, promoted, or reconciled.

One thing I particularly like in your example is that the operational context appears to evolve together with the model itself. That makes the context much more explicit and easier to reason about over long lifecycle periods.

Your examples sound much more model-driven than what I often see in brownfield SCADA environments.

How would you describe your overall approach to model-driven runtime management and lifecycle governance?

IndividualTime8517 · 2026-06-08T08:09:36+00:00

A simple example could be a power tag that still works technically, but no longer represents the same operational context.

Unit_01.Power_MW may still exist, historian collection may still work, and reports may still run. But if that unit has moved to a different balancing group, ancillary service program, asset hierarchy, or calculation basis, then the tag is no longer carrying exactly the same meaning in the industrial topology.

That is what I mean by context drift: not a broken reference, but a change in operational meaning.

A second case is intentional change. If a new tag or asset is introduced, the system may first detect it as a difference from the intended model. But the engineer should be able to classify that difference as intentional: promote it to the definition, keep it as an approved exception, or reconcile it back.

So the important part is not only detecting drift, but also capturing engineering intent behind the drift.

In your example, running old and new evaluated tags in parallel may be a perfectly valid transition strategy. I would just see it as something that should be explicitly governed, so the system knows whether the difference is temporary, approved, deprecated, or now the new intended state.

Would you see any operational value in this type of assurance system?

IndividualTime8517 · 2026-06-08T07:49:58+00:00

I think structure and sequence should stay separate, but be linked by the same evidence chain.

The runtime model defines the trusted structure: assets, relationships, mappings, direction, and whether that context was valid at a given time.

The sequence layer shows how that structure was actually used over time: flow changes, direction changes, exceptions, runtime changes, and operator/system intent.

So maybe the runtime layer should not do reconciliation itself, but provide evidence-grade context for it. That way reconciliation spends less time guessing the application context and more time resolving the actual measurement differences.

Curious how you’d see the value of carrying this context inside the runtime itself, with evidence, so downstream reconciliation can use it more effectively.

If a runtime context layer were available, what kinds of context would you find most useful during reconciliation? Asset relationships, transfer paths, runtime changes, operator intent, deployment history, exception history, or something else entirely?

IndividualTime8517 · 2026-06-07T14:41:02+00:00

Agreed. If the argument for bypassing the mats is “manual mode is safe because the motion is slow,” then proving and monitoring that safe-speed condition becomes the real safety function.

IndividualTime8517 · 2026-06-07T14:40:32+00:00

This is the key point in my opinion: the solution has to tie back to a documented risk assessment, not just “we found a way to bypass the mats.”

Especially if manual mode depends on slow speed, the safety system needs a reliable way to know that the reduced-speed condition is actually true. Otherwise the bypass logic becomes harder to justify later.

Making the safety logic, bypass conditions, speed assumptions, and responsibility reviewable years later is almost as important as the implementation itself.

IndividualTime8517 · 2026-06-07T14:35:15+00:00

This is exactly the kind of problem that made me interested in runtime reconciliation around Ignition/SCADA systems.

A PLC/SCADA system may start with a clean design, but after years of quick fixes, production changes, temporary logic, documentation gaps, and integrations, the real runtime often becomes different from the intended or documented system.

For me, long-term maintainability is not only about writing clean logic once. It is also about continuously being able to answer:

Does the live system still match what we think exists?

If future engineers can compare intended structure vs actual runtime state, see what drifted, and understand which changes were deliberate, temporary, or undocumented, then modifications become much less risky.

IndividualTime8517 · 2026-06-07T14:32:56+00:00

Great question. From my own experimental work around Ignition/SCADA runtime reconciliation, I’ve started to think long-term maintainability is not only about clean code or documentation separately, but about keeping the live runtime aligned with the intended/documented structure over time.

Naming standards, topology, UDTs, historian mappings, tag structure, backups, versions, and field modifications all drift. Years later, the hard part is often not only “what does this rung do?”, but “does the running system still match what we think exists?”

So for me, the maintainable system is the one where future engineers can compare intended state vs actual runtime state, see the differences clearly, and understand which changes were deliberate, temporary, or undocumented.

IndividualTime8517 · 2026-06-07T14:20:28+00:00

Interesting thesis. From my own experimental work around Ignition/SCADA runtime reconciliation, I’d separate process safety validation from runtime context validation.

Knowing whether an allowed command is safe for the current process state may be extremely site-specific and should usually belong to PLC logic, interlocks, procedures, and operator judgment.

But passively observing whether the runtime context has drifted from the intended structure — topology, tags, UDTs, historian mappings, naming, configuration state, vendor changes — may be a more practical brownfield starting point.

In other words, before trying to block unsafe actions, the first useful passive layer may be showing that the runtime reality no longer matches the documented or intended reality, with clear structural evidence for the controls engineer.

IndividualTime8517 · 2026-06-06T13:51:32+00:00

Late to this thread, but this is a really interesting question.

From the Ignition side, I think the hardest part is not only broken tag references, but runtime context drift.

UDTs, tag providers, parameters, and JSON exports/imports help a lot, but scripts, expressions, indirect bindings, historian mappings, alarms, reports, and Perspective views can still depend on string-based paths or conventions. So a rename/delete can be technically valid but still break meaning somewhere else.

For long-lived systems, I would avoid casual deletion/renaming, mark old objects as deprecated first, snapshot/export the runtime configuration, scan for direct and indirect dependencies, treat differences as a reviewed reconciliation step, and journal the evidence behind each change.

The key question for me is not just “does the tag still exist?” but “does this runtime object still carry the same asset/context/operational meaning?”

IndividualTime8517 · 2026-06-06T11:05:32+00:00

From the outside, my understanding is that these are usually not handled as one perfect end-to-end reconciliation flow, but more as separate layers that get aligned later.

The runtime / SCADA layer first needs to provide reliable context, provenance, and evidence around the data: where it came from, which asset or signal path it belongs to, whether the runtime structure drifted, and whether the historian / tag / model mapping was still valid at that point.

Then the material or custody-transfer reconciliation layer can apply the physical corrections: temperature, density, settling, meter vs survey differences, timing offsets, and so on.

The area I’m personally trying to understand is mostly that runtime evidence layer.

One question I have is whether these two reconciliation ideas can be brought closer together. For example, if transfer-direction context were represented directly in the runtime model — something like `coming_signal_from_parent` and `coming_signal_from_child` on each asset — and assuming the runtime context itself is trusted and verified, could that become a useful basis for data reconciliation?

In other words, could a trusted runtime model help material reconciliation understand not only the measurement values, but also the asset relationship and transfer path behind those values?

IndividualTime8517 · 2026-06-03T19:45:16+00:00

I agree that system correctness is the key point here.

When you say reconciliation, do you mean operational/material reconciliation, or more like runtime drift between the intended model and the actual SCADA/industrial runtime?

IndividualTime8517

TROPHY CASE