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
Cycle in type model
January 18, 2019
9:50, EEST
Avatar
Manfred Hausmann
Member
Members
Forum Posts: 4
Member Since:
September 21, 2018
sp_UserOfflineSmall Offline

Hallo

We are implementing a server using the Euromap 83 model.
A test client traversing the entire address space got stuck in node ObjectType/TopologyElementType/ConnectionPointType/NetworkIdentification.
UaExpert shows that Node NetworkIdentification has a reference “connectsTo” to itself: ConnectionPointType connectsTo NetworkIdentification connectsTo NetworkIdentification.

Is this a bug or a feature?

When using the SDK of Unified Automation the Node NetworkIdentification has no reference “connectsTo” to itself.

Regards,
Manfred

January 18, 2019
13:38, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 382
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

Thanks for the issue. It can be considered both a bug and a feature, depending on how you look at it.

OPC UA Address space in general/theory is allowed to contain (forever) loops (and can also be pretty large/infinite), a test client Browsing entire address space must expect that. In practice some Reference types might limit it and additionally View nodes (which pretty much no-one uses to my knowledge) have a ContainsNoLoops Attribute. In case of a grapchical application (like our graphical Prosys OPC UA Client) it is usually best to do the Browse incrementally per node when it is expanded in a Tree-like components.

I should point out that the given ConnectionPointType is in the DI model (https://opcfoundation.org/developer-tools/specifications-opc-ua-information-models/opc-unified-architecture-for-devices-di/, on which euromap83 has a dependency)

The ConnectsTo is a Symmetrical (which is pretty rare, most of References are not), hierarchical Reference (from the https://opcfoundation.org/UA/schemas/DI/1.1/Opc.Ua.Di.NodeSet2.xml):

<UAReferenceType NodeId="ns=1;i=6030" BrowseName="1:ConnectsTo" Symmetric="true">
<DisplayName>ConnectsTo</DisplayName>
<Description>Used to indicate that source and target Node have a topological connection.</Description>
<References>
<Reference ReferenceType="HasSubtype" IsForward="false">i=33</Reference>
</References>
</UAReferenceType>

The specification mentions on Symmetric References (1.04 Part 3 section 5.3.2):

If a ReferenceType is symmetric, the InverseName Attribute shall be omitted. Examples of
symmetric ReferenceTypes are “Connects To” and “Communicates With”. Both imply the same
semantic coming from the SourceNode or the TargetNode. Therefore both directions are
considered to be forward R eferences.

However the NetworkIdentifier (that has the OptionalPlaceHolder ModellingRule, i.e. it is not instantiated, just marks that the node could have that kind of construct below it) node is defined in the model as:

<UAObject NodeId="ns=1;i=6599" BrowseName="1:&lt;NetworkIdentifier&gt;" SymbolicName="NetworkIdentifier" ParentNodeId="ns=1;i=6308">
<DisplayName>&lt;NetworkIdentifier&gt;</DisplayName>
<References>
<Reference ReferenceType="HasTypeDefinition">ns=1;i=6247</Reference>
<Reference ReferenceType="HasModellingRule">i=11508</Reference>
<Reference ReferenceType="ns=1;i=6030" IsForward="false">ns=1;i=6308</Reference>
</References>
</UAObject>

Now, due to the specification part above, the SDK will treat every Symmetrical Reference as if it can never be Inverse. This means UaReference.getIsInverse(node) will return false for both the source and the target node.

However, the model defines the reference to be inverse. Which means our SDK will flip the source and the target for that reference when loading the model (since our current architecture uses both nodes and the reference type, i.e. we create one UaReference always, models might define it twice, one per direction). This then makes it so that the ConnectsTo reference for the NetworkIdentifier node is flipped, but due to it being also a Symmetrical Reference it never treated as inverse. So yes, it is a bug in that sense that probably that is not what should happen, however I could also argue that in modeling a Symmetric Reference should not be defined as inverse. We’ll try to fix this for SDK 4.0.0.

January 18, 2019
18:32, EEST
Avatar
Manfred Hausmann
Member
Members
Forum Posts: 4
Member Since:
September 21, 2018
sp_UserOfflineSmall Offline

Hi Bjarne,

thanks for the detailed answer!

Based on your explanation I would expect a connectsTo reference from NetworkIdentifier to ConnectionPointType and vice versa.
But not a self reference from NetworkIdentifier back to NetworkIdentifier.

Did I miss something?

Regards,
Manfred

January 21, 2019
12:48, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 382
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

The way it is written in the DI spec, yes, assuming you are Browsing in forward direction (i.e. the BrowseDirection parameter is FORWARD or BOTH in a Browse service call) from both of them, because the ConnectTo is defined as Symmetric ReferenceType.

However the NodeSet2 model for DI (quoted above), defines some ConnectTo reference as inverse (SDK and service call uses that term, i.e. IsForward=”false”), which looks odd given the reference should not be treated as inverse.

1.04 Part 4 Table 34 in section 5.8.2.2 for the BrowseDirection parameter:
“An enumeration that specifies the direction of References to follow. It has the
following values:
FORWARD_0 select only forward References.
INVERSE_1 select only inverse References.
BOTH_2 select forward and inverse References.
The returned References do indicate the direction the Server followed in the
isForward parameter of the ReferenceDescription.
Symmetric References are always considered to be in forward direction
therefore the isForward flag is always set to TRUE and symmetric References
are not returned if browseDirection is set to INVERSE_1.

Now I would like to say that as a workaround change those IsForward=”false” to IsForward=”true”, however the SDK additionally has a feature which always adds the reference to the other direction when adding references. If you apply the workaround you will get the ConnectTo Reference from NetworkIdentifier to ConnectionPointType, however this does not remove the existing “self-reference”, and additionally adds additional errorneus self-reference to ConnectionPointType as well.

In practice it would seem most likely every Symmetric ReferenceType does not work as expected. However I have seen them (now) so far only ever being used in the DI model. So in practice it is a bug, and the workaround is prevented by SDK feature.

January 25, 2019
9:43, EEST
Avatar
Manfred Hausmann
Member
Members
Forum Posts: 4
Member Since:
September 21, 2018
sp_UserOfflineSmall Offline

Hi Bjarne,

thanks for the explanation!

Best regards,
Manfred

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 78

Currently Online:
20 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 89

pramanj: 86

ibrahim: 68

kapsl: 57

gjevremovic: 49

TimK: 41

Fransua33: 39

fred: 36

Rainer Versteeg: 32

peterrob45: 25

Member Stats:

Guest Posters: 0

Members: 857

Moderators: 12

Admins: 1

Forum Stats:

Groups: 3

Forums: 14

Topics: 872

Posts: 3676

Newest Members:

virgie88y3407, bennetcole, timbo, malissa6674, Markus Johansson, jonathancamp, michell9665, bqpkelvin990391, Christopher, HuMa

Moderators: Jouni Aro: 827, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 382, Heikki Tahvanainen: 402, Jukka Asikainen: 1, Teppo Uimonen: 15, Markus Johansson: 1

Administrators: admin: 0