Industrial Data Governance Starts with the Information Model, Not the Access Matrix
When I wrote about why Industrial DataOps should be part of every modern factory, I defined the practice with five requirements: reliable, validated data; a meaningful information model; standard interfaces; properly secured OT sources; and governance over what changes and who can access what. Four of those got their own section, but the fifth was not really covered, and as my thinking has evolved over the past months, I felt it was time to write down my thoughts on it as well. Ultimately, governance is the key to keeping things alive in the long run.
In standard IT, data governance is always in place. Every decent data management project includes an access matrix defining who is allowed to access what, along with corresponding permission rules. In the OT world, this has seldom been the case, but it is becoming increasingly important due to the growing need to utilize OT data for overall business improvements. Although it is work that has to be done, it is the second problem rather than the first.
The first is to build common information models, naming conventions, and structure for the data that is meant to be governed. Otherwise you are just governing a mess. One plant can call a production run a batch, the next one can call the same thing a lot, and a third one can call it a charge, just as an example. In reality it is even more typical that several languages are mixed in the same plant. Setpoints, present values, and aggregates each follow the convention used by the automation programmer at the time of creation, and the same tag name may appear twice in the same group with different units.
Put a permission scheme, an analytics platform, and an AI agent on top of that, and what you have is a very well governed pile of data that nobody can use.
In this post, I’ll try to say out loud my thoughts on how governance should be done properly: what it actually has to cover in a factory, which parts of it an information model does for you, and which parts no standard or product is going to handle on your behalf.
What governance has to answer
Skipping the IT vocabulary, industrial data governance comes down to five questions about every value that leaves the plant floor.
- What does this mean, in what unit, and which asset does it belong to?
- Where did it come from, when was it actually measured, and did the source think it was valid?
- Who may read it, and separately, who may write it?
- How long does it live, and can we reproduce a number we reported last year?
- If we change platforms, can the meaning come with us?
Governance programs almost always answer question three. The other four are rarely written down anywhere, which is unfortunate, because question one is usually the reason the governance does not work in the first place, and question five is the reason it does not last.
The first question is the hard one
Agreeing on what the data means is unglamorous and hard work, largely a one-time effort with incremental maintenance as the plant changes, and it often surprises people without an OT background with its complexity. It frequently requires a process engineer, an automation engineer, and someone from IT to sit in the same room to define the common models and naming for all critical processes and operations.
When this is not done properly, the work gets deferred into the integration project, where it ends up being done implicitly by whoever writes the tag mapping. That person makes a few hundred small semantic decisions under pressure to meet a schedule, documents almost none of them, and moves on to another employer a few years later. It is the failure I described in the traditional automation stack post, where the knowledge inside a custom MES connector leaves with the developer who built it. Semantics that live in a mapping table are semantics nobody can govern, because nobody can see them.
An information model is what turns those decisions into something you can actually manage. Once the plant is described as assets with typed properties rather than as a list of tags, the semantic choices become visible, and those choices can be reviewed and versioned. You can hold a design review on an information model, but not on a flat list of eight thousand tag names.
This is also where the OPC UA Companion Specifications and the CESMII Smart Manufacturing Profiles earn their keep, as I discussed in more detail in the post on open standards and architecture. Where a standard model already exists for your domain, a working group has had most of the argument in public, and you inherit the result instead of having the same discussion again at every site.
Timestamps, status codes, and where the numbers came from
The second question is something that is typically not even considered until the reality of strange analytics starts to emerge. Analytics people ask for a value and a time, and what they usually get is a value and a time that can be anything from the actual change time to the timestamp when the data hit the cloud, seconds later. And can you trust that the value was actually read from the device rather than from one of the numerous caches in the connectivity layer?
OPC UA is unusually good here, and it is worth carrying what it gives you all the way to the consumer rather than flattening it on the first hop. Every value has a source timestamp and a server timestamp, and a StatusCode indicating whether the source considered the value good, uncertain, or bad.
When only the bare value is published in a JSON payload, which happens a lot with plain JSON over MQTT, that status information is simply gone, and let’s be honest, the data is then useless for many use cases. The extreme case is a KPI dashboard showing a totally stable value for days, because it cannot detect a data quality change to bad and just keeps showing the latest value it received.
Aggregates deserve some attention as well. If a report shows, let’s say, an hourly average, governance should know both the algorithm and where the samples were read. Frequently, aggregation is done in several layers, so an hourly average is computed from minute averages that were themselves calculated over a period containing a connection break. The result looks precise, and it is not.
Access control against a model instead of a tag list
The access matrix is a much easier problem once the first two questions have been answered, mostly because permissions expressed against a model remain valid, whereas permissions expressed against tag lists do not.
Typically only SCADA, MES, APC, and probably a few other application types require any write or call permissions; all reporting, analytics, and most AI would be fine with just read access. The write and call permissions can also be easily restricted to the necessary nodes: the setpoints, recipes, and methods needed by that specific application. A rule such as “the maintenance system may read all condition monitoring nodes, and may not write any setpoint” holds in a very general way even after new equipment is installed.
A list of six hundred node identifiers does not, and in practice it never gets updated, so either the new equipment is invisible to the people who need it or the exception that made it visible is still sitting there five years later. Reviewing that kind of list is nearly impossible, which is why it usually is not done. This is why, in typical OT, there is no access-level governance at all: if you are allowed to connect, you are frequently also allowed to write wherever you like.
A good practice for defining policies is to deny everything by default for everyone, and then create the allow rules in two layers. The first step is to define the basic access rules at the machine or process level for each application, and then, if necessary, define additional allow rules for identified users of those applications. A good practice for identifying users is to use LDAP or Active Directory, as then you do not need to keep track at the OT systems level of who is still in the company and who is not.
As a result, you will have a nice access matrix, where a machine vendor might see the diagnostics of their own machines and nothing else. A raw material vendor might monitor the tank level to optimize logistics for filling, but that is it. At the other end, a typical operator may use SCADA to control machine runtime, but only a production engineer has the right to use SCADA to edit recipes.
Much of this overlaps with the regulatory baseline I went through in the NIS2 post, and the overlap is no coincidence, since the boundary where data is harmonized is also the only place that sees all traffic and is therefore the natural place to enforce the rules.
Governance has to survive a rebuild
Plants change all the time. A line is rebuilt, a machine is replaced with a different vendor’s equivalent, and a new product can provide more precise quality and consumption measurements than before. Governance that relies on static plant documentation rather than active governance usually stops matching reality within the first year.
Two things follow from that. The information model needs versioning, with some record of what changed and why, so that a report from eighteen months ago can be read against the model as it was then rather than the model as it is now. And retention has to be an actual decision rather than a side effect of how much disk the Historian had left. Most non-regulated track-and-trace and quality use cases require retaining data for months to a few years, which is a very different discussion from the multi-decade archives that some regulated industries genuinely need.
One good test of successful governance is whether it is possible to reproduce a report from one year ago. If the answer involves anything complex, then governance exists only on paper.
Can you take the model with you?
The fifth question is the one I care most about, and it is almost never in the requirement specification.
Governance means control, and you do not control data whose meaning you cannot export. If the model that gives your OT data its meaning lives inside one vendor’s proprietary metamodel, then that vendor governs your data in practice, whatever the contract says about ownership. It is like renovating a leased apartment: when the lease ends, none of the work comes with you.
Since modeling is the most expensive part of the implementation, as I argued in the earlier DataOps post, it is also the most expensive thing to lose, and the cost of leaving grows every year you keep adding to it.
So ask yourself a question. Can you export the information model in a standardized format, hand it to another product, and have that product understand the assets, types, and relationships without a migration project? In the OPC UA world that form exists; it is called a NodeSet2 file, it is plain XML, and it is defined by the specification rather than by a supplier’s roadmap. Import them, use them, export them. If the answer to the export half of that sentence is a sales call, you have your answer about who is really governing the data.
What standards do not do for you
I do not want to give the impression that standard information models are governance-in-a-box, so it is fair to list what they do not solve.
OPC UA does not require the use of standard information models, so the naming convention can be a total mess if it is not handled properly. Eventually, the company-wide information models and naming conventions you use are still yours to decide on and to enforce.
In the best case you can use the OPC UA standard information models called Companion Specifications, and nowadays also the CESMII Smart Manufacturing Profiles, which leverage the same NodeSet2 markup. But even together they do not cover everything, and even when there is a good model for your use case, your company-specific needs might require extending it to fit perfectly. Company-specific models built on top of standard ones are perfectly normal, and the governance question there is simply which parts are standard and which are yours, clearly documented so the next engineer can tell the difference.
A couple of things to note so that things do not get messed up:
A model is not master data. Product codes, customer identities, and material masters live in the ERP and belong there. The information model refers to them, but it should not quietly become a second system of record for them, because the two will drift and then somebody has to reconcile them by hand.
The model still requires an owner. Somebody has to be accountable for the model, review the changes, and occasionally say no. That person owns the model rather than the data itself; the correctness of the data remains with the process owner who produces it.
To summarize, technology does not create company-wide agreements. Standards make the agreements expressible and portable, but the agreement itself requires design work, decisions, and enforcement. In other words, hard work. It does pay off many times over in the long run, when something unpredictable happens and can be solved without calling the retired former contractor, as I saw happen earlier this year.
Conclusions
Industrial data governance is neither a catalog nor a permission spreadsheet. It is an agreement about what the data means, written down in a form that outlives the tool that created it, with access, provenance, and retention rules attached to that agreement rather than to a list of tags.
My main advice for someone starting now: define the semantics before the permissions, keep the timestamps and status codes intact all the way to the consumer, and express access rules against the model rather than against tag lists. Involve OT and IT in the process early, because neither side has all of the required knowledge on its own. Version the model as the plant changes. And before signing anything, ask how the model gets exported, while you still have negotiating power.
More Information
At Prosys OPC we have built Prosys OPC UA Forge around this order deliberately. It harmonizes OT data into standard OPC UA information models, imports and exports them as NodeSets, enforces access at the OT/IT boundary against that same model with LDAP and Active Directory integration, and publishes the result over OPC UA, MQTT, REST, and i3X without requiring a separate model per interface. The part you invest the most in stays portable.
If you are working through governance for your own plant or group, or you would like a second opinion on an architecture that is already under way, feel free to contact me directly at pyry.gronholm@prosysopc.com or through our contact form.
Pyry Grönholm
CEO
Email: pyry.gronholm@prosysopc.com