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
NodeVersion property for AddressSpace Changes
December 3, 2014
15:44, EET
Avatar
hbrackel
Member
Members
Forum Posts: 74
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Hello all,
I’m triggering BaseModelChangeEvents on the “Server” node to signal not further detailed changes in the entire addressSpace for my server. According to the specification, modelChangeEvents need to go along with updating the nodeVersion property. This creates 2 questions:

1) The addressSpace changes happen underneath the Objects folder, while the ModelChangeEvent is triggered from the Server object. Which of the 2 objects’ node version property should be updated?
2) Would I create the nodeVersion property for either of the aforementioned nodes in namespace “0” or in namespace”1″? Neither object comes with an existing nodeVersion object (Prosys SDK 2.03).

Many thanks for your advice,
Hans-Uwe

December 4, 2014
15:13, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 801
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

The NodeVersion must be in the node that has the changes that you want to report. The standard UaNode implementations contain the NodeVersion already, but it seems that it’s not “directly” available, so you need to cast the ObjectsFolder, like this, to initialise the NodeVersion property:

FolderTypeNode of = (FolderTypeNode)server.getNodeManagerRoot().getObjectsFolder();
of.initNodeVersion();

Now you can just add nodes to the folder, for example, with

FolderTypeNode newNode = mySandboxNodeManager.createInstance(
FolderTypeNode.class, "NewFolder");
of.addComponent(newNode);

And the NodeVersion and model change events are triggered automatically.

Or if you want to makes several changes at once, you can use the begin/endModelChange-methods:

server.getNodeManagerRoot().beginModelChange();
try {
FolderTypeNode newNode = mySandboxNodeManager.createInstance(
FolderTypeNode.class, "NewFolder");
of.addComponent(newNode);
…add more nodes…
} finally {
server.getNodeManagerRoot().endModelChange();
}
December 4, 2014
20:23, EET
Avatar
hbrackel
Member
Members
Forum Posts: 74
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

The automatic trigger of ModelChangeEvents is wonderful! Superb! Many thanks for the code snippets, too.

Will ModelChangeEvents also be fired on Views (other than the standard view #0), if a modified node is part of such view hierarchy?

December 5, 2014
9:49, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 801
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Well, in general the support for Views is not very good. The big question to myself is still, what is the proper way to define to which views the different nodes belong to.

So the answer to this one is also “no”.

October 1, 2017
2:50, EET
Avatar
hbrackel
Member
Members
Forum Posts: 74
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Hi,

I have a follow-up problem with the latest version of the SDK:

the mere call of addComponent(…) or deleteNode() does not automatically trigger a ModelChangeEvent as described above. The calls currently have to be surrounded by beginModelChange and endModelChange.
Also, despite calling add/delete nodes, the event only reports added or removed references. And as a consequence, it reports the parent object as the effected node and not the deleted/added nodes themselves. This is not what one would expect, in particular as the OPC UA client would want to learn about the deleted nodeId.

The context for the changes should be the parent object and not the server object (according per OPC UA standard).

Alongside my evaluation, I found the the getEventNotifier() incorrectly checks for the presence of HasEventSource references or otherwise removes the subscribesToEvent bit. According to the OPC UA standard, the ability of reporting of events (“subscribeToEvents”) does not require having an HasEventSource reference. In my case I would need to add an HasEventSource reference from a Folder to somewhere in order to trigger modelchangeevents for added/removed organised nodes.

Best regards, Hans-Uwe

October 2, 2017
10:32, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 230
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

Seems the mention of automatic events without the begin/end was incorrect. Maybe we could implement that in the future, however it would need to be somehow configurable as it might not make sense to make separate event for each change..

There are some quirks on how the ModelChanges are specified and might not be that intuitive. Based on my interpretation of the spec:

1. The events should come from the server object, as per spec (v1.03) Part 3 9.32.3 (ModelChangeEvents) Views:
“…Therefore the only Notifiers which report the
ModelChangeEvents are View Nodes and the Server Object representing the default View.”
The “context” is defined by the affected field of the event. At least I would understand that this means the events are only given by the server object. Also as the event might contain changes from multiple nodes, therefore it would make sense that it is only notified from a central location (while I would argue it would also make sense that it would come from the object itself, if is an object for which references are added/deleted, but it would seem it is not specified so).

2. The affected node can be either the target or the source of the reference. Therefore clients should not assume it is the target. See spec Part 5 12.16 Table 157 for the ‘verb’
ReferenceAdded: “Indicates a Reference has been added. The affected Node may be either a SourceNode or TargetNode.”

For the NodeAdded, NodeDeleted verbs, the spec says 9.32.2:
“There is a correlation between ModelChangeEvents and the NodeVersion Property of Nodes.
Every time a ModelChangeEvent is issued for a Node, its NodeVersion shall be changed, and
every time the NodeVersion is changed, a ModelChangeEvent shall be generated. A Server
shall support both the ModelChangeEvent and the NodeVersion Property or neither, but never
only one of the two mechanisms”

Therefore in order to trigger the NodeAdded, the node must have the property. The nodes created with NodeManagerUaNode.createInstance and NodeBuilder are added to the manager as they are constructed. This also means that unless created by an InstantiationStrategy the node does not contain the property at the time of adding. This should be fixed or e.g. an option added to NodeBuilder which would make the NodeVersion before adding it to the manager. You could workaround this my adding the change manually via NodeManagerTable.getNodeManagerRoot().getModelChangeEvent().addChange(UaNode affectedNode, ModelChangeType… changeTypes) and adding the change manually.

The NodeDeleted should work as expected as it is done before deleting references.

You are correct about the SubscribeToEvents bit. That needs to be fixed. However as per above, you can still only observe ModelChanges from the Server object (which I would argue is anyway the best option as you only need to monitor one node to see all changes).

– Bjarne

October 2, 2017
21:23, EET
Avatar
hbrackel
Member
Members
Forum Posts: 74
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Hi,
I do read the spec a little different indeed. While the server object reports any events, the object holding the NodeVersion property shall trigger the ModelChangeEvent

9.32.2: … “This relation also implies that only those Nodes of the AddressSpace having a NodeVersion shall trigger a ModelChangeEvent. Other Nodes shall not trigger a ModelChangeEvent.”.
As in my application the nodes with the expected changes are known, I’d like to subscribe the changes directly from there to reduce the “clutter” of other events
The spec elaborate, that if multiple node are affected (e.g. through EventCompression) or there are no details about the affected nodes, then the server can trigger the event on the server object.

Anyhow – the specs leave room for interpretation.

As for the automatic trigger of events, I personally do prefer manual control. This allows me to well define and document the behaviour of my server in a toolkit independent way.

Thanks a lot for your interpretation and feedback. As always this is very insightful.

Regards,
Hans-Uwe

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 78

Currently Online:
9 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

pramanj: 86

hbrackel: 74

ibrahim: 65

kapsl: 57

gjevremovic: 49

TimK: 41

fred: 36

Fransua33: 35

Rainer Versteeg: 32

peterrob45: 25

Member Stats:

Guest Posters: 0

Members: 652

Moderators: 10

Admins: 1

Forum Stats:

Groups: 3

Forums: 14

Topics: 685

Posts: 2953

Newest Members:

Ravish Roshan, Max Braun, Predixer, LorraineXu, FF, Jonas, HA198273465, RaeHoffman, susandaigle23, m.scaglioni

Moderators: Jouni Aro: 801, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 230, Heikki Tahvanainen: 270, Jukka Asikainen: 1

Administrators: admin: 0