Hi,

Assuming “Category” means the element defined at https://reference.opcfoundation.org/v104/Core/docs/Part6/F.3/.

Can be categorized as our bug. As long as your issue is only that it wont load it is an easy fix. If you would need to obtain that data at runtime it is harder, since that is modelling-only data that wont translate to anything visible in the address space and thus it would be discarded during loading.

The current loading implementation requires us to know all valid tag names assuming they are not part of a value. Seems the “Category” is not yet part of that, which means we have never loaded such model, thus no model we have tested have had that. Therefore, if possible, is there a public model that uses it that we could use for testing? (we can obiviously define one ourselves if needed if nothing exists).

Loading the model should now work with the release 4.5.4 that we just did today, https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-5-4. The data is discarded though.

The way model loading currently works is that it is can only load data which is something that would be visible in the address space. This is because we load it to a set of AddNodes and AddReferences data. Those service calls could be used by a client to load the model from the client side. The parsing logic is currently same for both. Since the Category is pure modelling data, it basically must be discarded. We might be able to do some tricks if the model is loaded in the server side, but it would be purely for the server side internal use. That is to say, no UA Client can ever see that data.

Thus if possible, could you explain your use-case in more details? Like I cannot exactly promise that it would happen soon. Also it has not been used by _any other model_ thus far, and we have seen quite a lot of those. Maybe there is an alternative way to solve that issue? We can try to account this in e.g. some “SDK 5” design etc.

I think I sort of get it, though sorry, maybe not fully (i.e. why the Category would be needed here, “normal” OPC UA modelling with types and references should be enough here, though, as a note I obiviously wont see the “whole world” from here so to say). A diagram might help though (if you decide to make one, send it to uajava-support@prosysopc.com and mention this forum thread).

Not sure if you can answer these, but here goes anyway: Are you the one making the model or do you have influence over those that make it? Is this a “companion specification” e.g. as in https://reference.opcfoundation.org/v104/ below (or like ones at https://github.com/OPCFoundation/UA-Nodeset)? Or it is just “some model” internal to the place where you work? That is to ask, is it intended to be used by others as well (and thus meaning other SDKs as well?)?
The rest of the post is written assuming you have some influence over the model. If not, any option to show this to the people that do?

As said, as far as I’m aware, this is the first time (since the start of OPC UA, so like 10-15 years or so depending on how you count) anyone would be tring to use the Category element. Thus, since “no-one else” had the need to use at this point, maybe this is a https://en.wikipedia.org/wiki/XY_problem and instead this would be solveable via some other way?

Thus, is there any reason, why this information cannot be e.g. in a Property of that node instead? Or have some e.g. (maybe non-hierarchical) Reference point to e.g. a “Unit Category” node. Like, the type nodes’ InstanceDeclarations do point with a HasModellingRule Reference is it Optional or Mandatory ModellingRule node, could you just instead use this type of mechanism? Or maybe you could just use a different ObjectType instead to differentiate this? Or something from (https://reference.opcfoundation.org/v104/Core/docs/Amendment7/, though, note that we do not have any special support for these, but normal references and nodes operations should allow you to do these even now).

IF for some reason that Category is intentionally such info, that no OPC UA Client connecting to the server should see it, I could maybe see the need for the Category, but if it “matters in this case” that much, shouldn’t it instead be something the client sees?

Alternatively, I could see the need to support it better, if instead of a UA Server the intention would be to make some modelling tool with the SDK. Though, in general that area has not been explored that much.

How much of this made sense to you? Do you agree or disagree? Any opinions? Since I just wonder could the “root problem” of using the Category in the first place be eliminated and the info be represented in a way that it would also be visible in the address space of the server?

At least based on some short thinking, I do not think there is a suitable one in the standard base model: https://reference.opcfoundation.org/v104/Core/docs/Part5/ (see the Standard ReferenceTypes). Though, that is not all, since e.g. the https://reference.opcfoundation.org/v104/Core/docs/Amendment7/ added HasInterface/HasAddIn Reference Types (I believe those 1.04 Amendments will be merged to the base spec text in OPC UA 1.05).

Not always, but typically models build on top of models (or well, all do depend implicitly on the base standard information model anyway), see https://reference.opcfoundation.org/v104/ and scroll down. A model that is quite often used is the “DI” model. Though, for just this case not sure it offers anything. But there is in general a lot of those models, if one happens to be close to your domain, you might be able to use that. Though, you might want to check https://www.prosysopc.com/blog/nodeset-file-importing/ as well, since not all of them work as is (or at all) with our SDK, but most do.

Anyway, if there was no suitable companion models to use, then you would probably create it in your model. Though, since interop is a quite big thing in OPC UA, it does mean, that any 3rd part app connecting to your server (though, this may or may not make sense for your case) cannot directly infer what that reference means (like UI’s typically just show hierarchical references in a tree-like view, non-hierachical might not show up there, though our Browser app has a toggle should those be seen). Though, well, the use of any companion spec defined reference types would also mean the client would need some logic to that (but like, it would be more common logic if we take all OPC UA apps of the world into account). But this matters less if is a completely internal solution.

Hopefully that made sense. I guess in general this is something the model’s makers should agree upon, i.e. what purpose does the info give to clients or servers using/knowing the model. I would assume it has a companying spec text defining the types defined in your model. Thus those explanations of these reference types should be written there. This is assuming it is not from a companion spec model that would would then depend upon and it would have been written already there instead.