Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Category in UAObject
March 12, 2021
12:46, EET
Avatar
MarcoDeT
Member
Members
Forum Posts: 4
Member Since:
March 12, 2021
sp_UserOfflineSmall Offline

Hello everybody,

I noticed that the UANodeSet xml parser doesn’t support Category in UAObject.
Is it possible for you to put it in a next release?
That would be nice.

March 12, 2021
13:20, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 633
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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).

March 19, 2021
13:30, EET
Avatar
MarcoDeT
Member
Members
Forum Posts: 4
Member Since:
March 12, 2021
sp_UserOfflineSmall Offline

Hi,

Yes, the “Category” definition is correct.
First it’s important that it will load. Retrieving the category at runtime would be a nice feature, but this comes second.
I haven’t found a public model containing the category.

March 19, 2021
14:21, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 633
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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.

March 29, 2021
15:47, EEST
Avatar
MarcoDeT
Member
Members
Forum Posts: 4
Member Since:
March 12, 2021
sp_UserOfflineSmall Offline

Thank you for the release.

A plant, like a tunnel, has a lighting system and there are different parts that make up the system. There is e.g. a certain electrical circuit which has the category of “Logical Unit” because the logical mechanism matters in this case. Then there is a lamp which is a “Physical Unit” because it’s a unit where the material matters. I hope if’s more clear to you how the category can be used. It’s more or less the same as assigning a tag to the object.

Yes, it’s ok if you tackle this new modelling aspect for a new SDK.

April 6, 2021
12:17, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 633
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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?

April 8, 2021
11:19, EEST
Avatar
MarcoDeT
Member
Members
Forum Posts: 4
Member Since:
March 12, 2021
sp_UserOfflineSmall Offline

I have some influence over the model but not that much. I am not hugely free to add new Properties but I don’t need to use the Category for my purpose. I think the mechanism implemented by HasModellingRule is something I could use. Is there already a non-hierarchical reference type I can use or do I need to model a new reference type?

April 9, 2021
9:36, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 633
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
19 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 109

pramanj: 86

ibrahim: 71

kapsl: 57

gjevremovic: 49

TimK: 41

fred: 41

Fransua33: 39

Xavier: 34

rocket science: 33

Member Stats:

Guest Posters: 0

Members: 1283

Moderators: 15

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1100

Posts: 4643

Newest Members:

henryking123, pcygraig5029, corejavatuts, jaynelumpkin4, nandant07, vnd18, arnetteleverett, autumnzzi6, vickiviera, dianames129491

Moderators: Jouni Aro: 869, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 633, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Teppo Uimonen: 21, Markus Johansson: 30, Matti Siponen: 100, Lusetti: 0

Administrators: admin: 1