BS EN 62541-3-2010 pdf download.OPC unified architecture Part 3 : Address Space Model.
Events represent specific transient occurrences. System configuration changes and system errors are examples of Events. Event Notifications report the occurrence of an Event. Events defined in this document are not directly visible In the OPC UA AddressSpace. Objects and Views can be used to subscribe to Events, The EventNotifier Attribute of those Nodes identifies if the Node allows subscribing to Events. Clients subscribe to such Nodes to receive Notifications of Event occurrences.
Event Subscriptions use the Monitoring and Subscription Services defined in IEC 62541-4 to subscribe to Event Notifications of a Node.
Any OPC UA server that supports eventing shall expose at least one Node as EventNotifier. The Server Object defined in IEC 62541-5 is used for this purpose. Events generated by the server are available via this Server Object. A server is not expected to produce Events if the connection to the event source is down for some reason (I.e. the system is offline).
Events may also be exposed through other Nodes anywhere in the AddressSpace. These Nodes (identified via the EventNotifier Attribute) provide some subset of the Events generated by the server. The position In the AddressSpace dictates what this subset will be. For example, a process area Object representing a functional area of the process would provide Events originating from that area of the process only. It should be noted that this is only an example and it is fully up to the server to determine what Events should be provided by which Node.
4.6.2 EventTypes
Each Event is of a specific EventType. A server may support many types. This part defines the BaseEventType that all other EventTypes derive from, It Is expected that other companion specifications will define additional EventTypes deriving from the base types defined in this part.
The EventTypes supported by a server are exposed in the AddressSpace of a server.
EventTypes are represented as Object Types in the AddressSpace and do not have a special
NodeClass associated to them. IEC 62541-5 defines how a server exposes the EventTypes in
detail.
EventTypes defined in this document are specified as abstract and therefore never instantiated in the AddressSpace. Event occurrences of those EventTypes are only exposed via a Subscription. EvoniTypes exist In the AddressSpace to allow clients to discover the EvenlType. This information is used by a client when establishing and working with Event Subscriptions. EventTypes defined by other parts of this standard or companion specifications as well as server specific Event Types may be defined as not abstract and therefore instances of those EventTypes may be visible in the AddressSpace although Events of those EventTypes are also accessible via the Event Notification mechanisms.
4.6.3 Event Categorization
Events can be categorised by creating new Event Types which are subtypes of existing EventTypes but do not extend an existing type. They are used only to identify an event as being of the new EventType. For example, the EventType DeviceFailureEventType could be subtyped into TransmitterFailureEventType and ComputerFailureEventType. These new subtypes would not add new Properties or change the semantic inherited from the DeviceFailureEventType other than purely for categorization of the Events.
Event sources can also be organised into groups by using the Event ReferenceTypes described in 7.18 and 7.20. For example, a server may define Objects in the AddressSpace representing Events related to physical devices, or Event areas of a plant or functionality contained in the server. Event References would be used to indicate which Event sources represent physical devices and which ones represent some server-based functionality. In addition, References can be used to group the physical devices or server-based functionality into hierarchical Event areas. In some cases, an Event source may be categorised as being both a device and a server function. In this case, two relationships would be established. Refer to the description of the Event ReferenceTypes for additional examples.
Clients can select a category or categories of Events by defining content filters that include terms specifying the EventType of the Event or a grouping of Event sources. The two mechanisms allow for a single Event to be categorised in multiple manners. A client could obtain all Events related to a physical device or all failures of a particular device.
4.7 Methods
Methods are lightweight” functions, whose scope is bounded by an owning (see Note) Object. similar to the methods of a class in object-oriented programming or an owning ObjectType. similar to static methods of a class. Methods are invoked by a client, proceed to completion on the server and return the result to the client. The lifetime of the Method’s invocation instance begins when the client calls the Method and ends when the result is returned,
NOTE The owning Object or Object Type is specified In the service call when invoking the Method.
While Methods may affect the state of the owning Object, they have no explicit state of their own. In this sense, they are stateless. Methods can have a varying number of input arguments and return resultant arguments. Each Method is described by a Node of the Method NodeClass. This Node contains the metadata that identifies the Method’s arguments and describes its behaviour.
Methods are invoked by using the Call Service defined in IEC 62541-4. Each Method is invoked within the context of an existing session. If the session is terminated during Method execution, the results of the Method’s execution cannot be returned to the client and are discarded. In that case, the Method execution is undefined, that is, the Method may be executed until it is finished or it may be aborted.BS EN 62541-3-2010 pdf download.