Log In
Home
04/29/2019
Offline
Hello,
As per my understanding, if a server has various alarms, the server object in the address space is always subscribed by the client to get information on any of the alarms/events that occur. (UA expert: I monitor the server object, trigger some alarms manually on the server, I get the various alarms in the event view)
However, I just want to know, if it is a documented proof as to whether subscribing to the server object is better than subscribing to individual alarms? Could you direct me there?
I read through the specification Part 9, and no where it is mentioned that the server object needs to be monitored. All they say is client can subscribe to any attribute of the alarm. However i understand the benefit of subscribing to the server object on the whole. Is it implicitly understood that way?
Could you please guide me here?
Regards,
Rakshan
05/30/2017
Offline
1) You do not “subscribe to alarms”. You can only subscribe to notifiers which usually report multiple alarms.
2) There is no “better”. It depends on the server and the client. A subscribing to the server object can result in many events being sent that are not of interest to the client which wastes bandwidth and CPU. OTOH, for small servers the simplicity would make it worth dealing with a few unnecessary events.
Moderators-Specifications
Moderators-Companion
Moderators-Implementation
Moderators-Certification
Moderators-COM
02/24/2014
Offline
Alarms are part of an information model and have state associated with them, All transitions between these states generate an event. By definition a Server Object is a notifier and reports all events generated in the server. An subscription for events includes two parts, a select list of the fields that are to be included in the event that are reported and a filter that is used to restrict what events are to be reported in the subscription. So a client can filter on the various fields in the event and restrict what events are reported. The Event subscription filter is at times not enough, since it can only filter on field in events. Part 9 also describes how a server can create a notifier hierarchy, where some arbitrary object tree is created and the objects in the tree have notifier set, by definition an object would only report the events that are related to that object or to objects that are linked to it via the notifier tree (a number of references can be used to create this tree – see part 9). The client can then create a subscription on one of these objects, which by definition have a subset of events only being reported. So the notifier tree can be used as an additional filter.
An example would be a power plant where there are 3 identical units generating power (all units have the same structure and alarms/events), a notfier tree could be used to create a separate reporting scheme for each unit.
Paul Hunkar - DSInteroperability
1 Guest(s)
Usage Policy