AuditEventsare Eventsof AuditEventTypethat are generated as a result of an action taken on the Serverby a Clientof the Server. For example, in response to a Clientissuing a write to a Variable, the Serverwould generate an AuditEventdescribing the Variableas the source and the user and Clientsession as the initiators of the Event.

Figure 39illustrates the defined behaviour of an OPC UA Serverin response to an auditable action request. If the action is accepted, then an action AuditEventis generated and processed by the Server. If the action is not accepted due to security reasons, a security AuditEventis generated and processed by the Server. The Servermay involve the underlying device or system in the process but it is the Server’s responsibility to provide the Eventto any interested Clients. Clientsare free to subscribe to Eventsfrom the Serverand will receive the AuditEventsin response to normal Publish requests.

All action requests include a human readable AuditEntryId. The AuditEntryIdis included in the AuditEventto allow human readers to correlate an Eventwith the initiating action. The AuditEntryId typically contains who initiated the action and from where it was initiated.

The Servermay elect to optionally persist the AuditEventsin addition to the mandatory Event Subscriptiondelivery to Clients.


Figure 39– Audit Behaviour of a Server

Figure 40illustrates the expected behaviour of an aggregating Serverin response to an auditable action request. This use case involves the aggregating Serverpassing on the action to one of its aggregated Servers. The general behaviour described above is extended by this behaviour and not replaced. That is, the request could fail and generate a security AuditEventwithin the aggregating Server. The normal process is to pass the action down to an aggregated Serverfor processing. The aggregated Serverwill, in turn, follow this behaviour or the general behaviour and generate the appropriate AuditEvents. The aggregating Serverperiodically issues publish requests to the aggregated Servers. These collected Eventsare merged with self-generated Eventsand made available to subscribing Clients. If the aggregating Serversupports the optional persisting of AuditEvent, thenthe collected Eventsare persisted along with locally-generated Events.

The aggregating Servermay map the authenticated user account making the request to one of its own accounts when passing on the request to an aggregated Server. It shall, however, preserve the AuditEntryIdby passing it on as received. The aggregating Servermay also generate its own AuditEventfor the request prior to passing it on to the aggregated Server, in particular, if the aggregating Serverneeds to break a request into multiple requests that are each directed to separate aggregated Serversor if part of a request is denied due to security on the aggregating Server.


Figure 40– Audit Behaviour of an Aggregating Server