Hello everyone, I'm currently working on a project central monitoring system for multi sites, initially we will integrate around 50 sites in one country divided into 3 zones, each site will have 3-7 controllers, on long-term that may scale to 5 different countries with many zones and 500+ sites. The communication between the controllers and Ignition is OPC UA, where each controller has a dedicated OPC UA server and Ignition is the client.
I would appreciate your suggestions and recommendations for the OPC UA best practice for building a well structured unifed name space based on OPC UA namespace standards.
I tried to do my homework and research and understood a little about NamespaceName and Index in OPC UA, and a little bit about NodeIds. However, I'm still not sure is it a good practice to include my hierarchy into the namespace like: Enterprise/Country/Zone/Site/Controller
That means creating a namespace for each controller, or Am I getting it all wrong?
Excuse my ignorance. Thanks in advance.
2 Likes
While hierarchical naming can be very convenient, there always seems to be something down the road that breaks the mold & causes the original convention to fall short.
As such, I would entertain a very simple unique identifier for each site, especially one from an existing ERP system.
I understand that the traditional hierarchical convention has its limitations, I faced that before. However, I'm bound to the client mind set. I have no connection to the ERP, and as mentioned I have multiple controllers (aka OPC server) in each site, which I need to group them by site, region, country.
I have a preliminary design, but I wanted to know others recommendations and experience, to not fall into mistakes and it gets ugly when scale.
Thanks for your insights.
Hi @Ali_Ali,
we are currently working on a similar topic, also regarding the integration of multiple controller via OPC-UA to Ignition. I don't have a perfect solution, we are still in the research/concept phase.
But I would not recommend to use the OPC-UA namespace name for a hierachy naming of your enterprise. If you want to model the hierarchy in OPC-UA, use the OPC-UA address space and folders or objects with a organization reference.
But maybe you don't have to model this in OPC-UA at all and just use the Ignition Tag Browser or UDTs
There's always more than one hierarchy or one way to divide up tags. One great way to bridge this gap is to use custom properties with a defined meaningful key, and a tagPath value. This allows you to break out of a single hierarchy and create meaningful relationships between tagPaths. And tagPath here could be a UDT instance, a folder, or anything with custom properties. We use this to represent relationships in terms of communications architecture, controls architecture, power flow, representations of physical locations, etc. We keep like things together, and we relate them with custom properties containing string tagPaths.
2 Likes
Hi @Andre_Hennecke,
Thank you for your recommendation. However, I'm still not sure why you don't recommend using namespace as an organization hierarchy (high-level hierarchy above controller). To clear my purpose here, I don't want to solely depend on Ignition for organizing my structure, using clear OPC connection names for each controller and a well structure folders/objects for the lower hierarchy below controller, is pretty enough in case I'm sure that Ignition gateway will always there and will always be the only gateway for my site assets in the enterprise. However, this is hardly the case here, I'm dealing with a big enterprise that exists in different countries with multiple divisions, different systems, etc.
So, my Beckhoff controllers may at some point talk to other systems than Ignition, talk to each others or even publish data to a broker (never used OPC Pub/Sub before but I'm aiming to dig in soon). That's why I'm trying to build and standardize everything from bottom up while we got the chance, before everything gets ugly and messy 
Thank you @msteele for your great suggestion, this is really insightful. Of course, I will contextualize my UDTs, Folders and tags, however, as cleared things to Andre, I need to structure things from bottom up not just in Ignition env, I need Ignition to consume contextualized data from the controller then add some extra context (eg. functional, informative) in Ignition for other purposes. I need to ensure my edge data are unique, unified and can be consumed by any system any where in the enterprise UNS.
Note: I also don't want to be bound to this specific default opc server namespace from this manufacturer, that's why I need to create my own namespace with structured and clear hierarchy.
This is where you problem starts. To be using a UNS, you need all the devices to exist in one namespace, what you have right there is an individual namespace inside each controller.
In Ignition, each of these controllers will appear as a separate tag provider, with a completely flat hierarchy. To bring these together, you could use reference tags to move them all into the Ignition OPCUA server, but then you have the same issue where you have multiple Ignition gateways.
You would then have translation layer after translation layer.
This is where MQTT becomes powerful, bring the tags locally in each site to an edge Ignition gateway, then pass the needed data from the controllers upwards via MQTT to a cloud/enterprise broker and enforce the UNS on the broker. All your Ignition gateways can then subscribe to any of the data on the broker as per the UNS and consume as needed.
Hi @David_Stone,
Thank you for your suggestion. First, I would like to stat that I'm a huge fan of using MQTT to build my UNS (would have pick it over OPC if I got the choice of course), I'm more familiar with MQTT than OPC, and I know it makes life easier. However, I don't really believe that MQTT is the only answer for building UNS. I believe with well designed structure and clear understanding of the project data and requirement are what you really need.
Second, I didn't get why you stated that each controller will have a separate 'tag provider'. Every controller will have a different OPC connection, however, this does not mean each one's tags will be in a different tag provider.
Simply, you can create one tag provider, create bunch of UDTs, in the UDT paramater just add opcServer parameter, create UDT instance and give it the opcServer (controller connection name) that it belongs to. Even without UDTs, you still can create or browse tags from multiple OPC connections in the same tag provider in Ignition.
1 Like
You can definitely have a UNS on OPCUA.
The issue is that as you scale upward, you have to make choices on what structure you use for sharing data.
- Level 1 OPCUA - Controllers: You subscribe to these on your site Ignition server and add them into your UDTs in the way you described, you now have /Controller namespace covered, but it's in 50-500 gateways across 5 countries.
- Level 2 OPCUA - Sites: You have two choices here, GAN and OPCUA to choose from to make this level of the stack. Are you now subscribing to the entire OPCUA server of every site? Are you simply using remote tag providers over GAN to get the namespace from below? Is there a Co-Lo server somewhere in each zone that will connect down to each site? Are you copying the UDTs into the zone level OPC server (Ignition?) as well? What sort of network link are you relying on here?
- Level 3 OPCUA - Enterprise: Is this where you are gathering all the sites into one namespace? Is this where your historian is going to live? Is all the data needed at this level? Is this where the Visualisation comes from or is that further down the stack?