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

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:

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.

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.