NodeSet2, Companion Specs & SM Profiles Explained
I keep running into the same confusion in both customer discussions and social media. People use the terms “Companion Specification”, “CESMII SM Profile,” and “OPC UA information model” as if they meant the same thing, and mix them up. And almost nobody realizes that NodeSet2 sits behind all of them.
This leads to awkward conversations. Two people think they agree, but they are talking about different things. It gets worse when someone asks for a Companion Specification but actually means a custom model of their own.
So I try to explain this as simple way as possible. Let’s hope this all makes more sense after this.
The concepts at a glance
| Concept | What it is | Who owns it | Format | Examples |
|---|---|---|---|---|
| NodeSet2 | The file format an OPC UA model is written in. A container, not content. | OPC Foundation, part of the OPC UA spec | XML | (a format, not a model) |
| OPC UA information model | The general term for any model written as NodeSet2 | Anyone can build one | NodeSet2 | Everything below is one of these |
| OPC UA Companion Specification | An industry standard model that went through a formal process | OPC Foundation with industry groups | NodeSet2 | Machinery, Robotics, PackML, Euromap |
| CESMII SM Profile | A reusable model aligned with OPC UA and ISA-95. Not a formal standard. | CESMII | NodeSet2 | The SM Profile library |
| Company-specific model | A model you build yourself, usually on top of a standard one | You | NodeSet2 | Your own process extensions |
Look down the Format column. It says NodeSet2 every time. Who made the model changes from row to row, but the format does not. That one fact is the key to everything, and the rest of this post just explains why it matters.
The format is not the content
NodeSet2 is not an alternative to a Companion Specification or an SM Profile. It is the file they are written in. NodeSet2 is the container. The model is what is inside it: the actual description of a pump, a robot, or a packaging line.
Think of PDF. A contract, a manual, and a novel can all be PDF files. Knowing something is a PDF tells you nothing about what it says. NodeSet2 is the same. It is just the file format.
The OPC UA spec defines this format and the basic building blocks every model uses. The spec is the rulebook. The NodeSet2 files are the content written by those rules. Keep those two apart in your head and most of the confusion is already gone.
The three kinds of model
Companion Specifications are the most formal. The OPC Foundation builds them together with industry groups, through a public process, for specific domains like machine tools, robotics or packaging. These are real, published standards. Someone already had the argument about what a pump looks like as data, in public, and you get to use the result. They are the most widely supported, so where one exists for your case, it is usually the best place to start.
CESMII SM Profiles come from CESMII, the US Smart Manufacturing Institute. They are also NodeSet2, and they line up with OPC UA and ISA-95. Here is the part that confuses people the most: not all SM Profiles are Companion Specifications, but they are all OPC UA information models. They have not gone through the OPC Foundation process, so they are not standards in the same strict sense. But they are open and public, and they are the same kind of thing in the same format. For a lot of manufacturing cases they are easier to get hold of, and they cover ground no Companion Specification does.
Company-specific models are the ones you build yourself. Most real plants need some, because even a good standard model will not cover everything specific to your process. That is normal. The healthy way to do it is to build on top of a standard model instead of replacing it, so the standard parts stay standard and only your own parts are custom. Just document which is which, so the next engineer can tell them apart.
All three are OPC UA information models. All three are NodeSet2. They differ in who made them and how formally, not in what they are.
Where the models come from, and how you use them
This is the part that gets lost behind the acronyms. These models are not abstract ideas. They are real files, in real places, that you download and use.
Where they come from. Companion Specifications are published by the OPC Foundation, on its website and its public GitHub, as NodeSet2 files you can download. SM Profiles come from CESMII’s profile library, also as NodeSet2. The basic OPC UA types, the building blocks every model needs, are published the same way, in the same official place. You can also make your own models in a modeling tool and save them as NodeSet2, usually built on one of the above.
How you use them. It works the same way no matter where the model came from. You take the NodeSet2 file and import it into a server or tool that reads NodeSet2. That creates the types. Then you build your actual equipment from those types: this pump, that line, from the model’s standard pump and line definitions. Finally, you map the raw values from the plant onto that structure. So instead of a flat tag called FT_101, you have a flow meter of a known type on a known line, with a unit and a meaning.
And because it is a standard file, the same NodeSet2 works in any system that supports it. Import a Companion Specification into two different vendors’ servers, and both understand it the same way. That is the whole promise, made real: build the model once, as a file, and take it wherever you need.
Why the shared format is the whole point
This is not just about words. Because everything is NodeSet2, choosing between them is not a lock-in decision. A system that reads NodeSet2 reads all of them, no matter who made them.
So you are not stuck in one world. You can start with a Companion Specification for equipment that has one, add a CESMII SM Profile for a domain that does not, extend both with your own model, and run it all in the same place. The format lets them work together and, just as importantly, lets them leave. You can export what you built and move it to another product without a migration project, because the format belongs to the spec, not to a vendor.
This is why I keep saying the real question is open versus proprietary, and nothing else. It is not about which body blessed the model. It is about whether the model is in a format you can import, use, and export freely.
This matters for i3X too, not just OPC UA
One thing worth saying out loud, because it is easy to miss. Information models are not only for OPC UA. They matter just as much for using i3X well.
i3X serves the same underlying model over a REST interface, and its value depends on that model being there. Without real types and relationships behind it, i3X turns into just a JSON API for tags, which does not solve the problem it exists for. With a real model behind it, from the same Companion Specifications and SM Profiles in the same NodeSet2 format, an i3X client can find the equipment, know what it is, and follow the links between assets. The interface changes, the model does not. So the modeling work pays off across every interface you serve it over, whether that is OPC UA, i3X, MQTT, or anything else.
How we do this in Forge
At Prosys, we built Forge to not care where a model comes from, exactly because they are all NodeSet2. Forge imports Companion Specifications, SM Profiles, and your own models, lets you extend them, maps your raw data onto them, and then serves the result over OPC UA, i3X, MQTT, and REST, with one model behind all of them. And because the format is standard, you can export what you built and take it with you. Import, use, export, in a format that belongs to the spec and not to us.
That last part is on purpose. The modeling is the most expensive part of any data project, so it should stay portable. We built Forge so the part you invest in the most stays yours.
The takeaway
Do not get lost in the terminology. NodeSet2 is the format. Companion Specifications, SM Profiles and your own models are all content in that format. They differ in who made them and how formal they are, not in what they are. They come from known places, you use them the same way, and because they share the format, they work together, and they travel.
So when you look at a platform or a model, the question is not which acronym it carries. It is whether the model is in NodeSet2, and whether you can take it with you. That is the question worth asking, and the one that decides whether your most expensive work lasts.
More Information
At Prosys, we have built Prosys Forge around exactly this idea. It harmonizes your OT data into standard OPC UA information models, imports and exports them as NodeSets, and serves the result over OPC UA, MQTT, REST, and i3X, all from one model. The part you invest the most in stays portable.
If you want to really understand how this fits together, including how the different Parts of the OPC UA specification relate to NodeSet2, Companion Specifications, and the rest, that is exactly what we cover on day one of our workshops. We start from the ground up, so you leave knowing not just the terms but how they connect.
And if you are working through modeling or governance for your own plant or group, or you would like a second opinion on an architecture already underway, 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