Annex A – LogObject Server Examples (Informative)

A.1 LogObject Server examples overview

The LogObject might be added to a specific Object that is part of a device model and stores records in a vendor specific manner (see A.5). Another example is a Server that also support EventHistory and stores the LogRecords as part of a standard EventHistory (see A.2). Other examples include a system in which the LogRecords are buffered locally in a single store for several LogObject (see A.5) or in multiple stores one for each LogObjects (see A.5). There is an example in which LogRecords are forwarded by the device to an OpenTelemetry system (see A.4) and there is also an example for Syslog server (see A.3).

A.2 Event History Illustration

A Server that supports EventHistory, might just pull LogRecords from the EventHistory storage (i.e. no storage of LogRecords in any LogObject). The Event history storage would include the ConditionClassId (SubConditionClassId) field in an event and a GetRecords call could just be a retrieval from the Event history for fields they are interested in and a filter for records where the ConditionClassId/SubConditionClassId is LogEntryConditionClassType. The filter might also include restriction for records that are from the appropriate Area.

Figure A.1 – Event History Illustration

A.3 Syslog storage illustration

This example illustrates a possible implementation in which the devices generating LogObject information are sending the information to a central SYSLOG server. In this illustration, the local LogObject would only contain a minimum buffer of LogRecords.

Figure A.2 – SYSLOG illustration

This specification provides no mapping to SYSLOG record, but the required fields for SYSLOG entries can be found in a LogRecord.

A.4 Open telemetry Illustration

This example illustrates a possible implementation in which the device generate LogObject information are deployed in a system which uses OpenTelemetry to collect log or trace information. For more detail on how LogRecords can be imported in OpenTelemetry see Annex C.

Figure A.3 – OpenTelemetry Illustration

A.5 Vendor Specific Storage

The storage can be per LogObject (see Figure A.4). Each LogObject stores its own its own copy of the LogRecord, even if the LogRecords are the result of an event stream. Each LogObject would have its own limits for storage. This storage would result in some LogRecords being stored multiple time, in separate LogObjects. Also the list of LogRecords in the ServerLog might not include all of the LogRecords that would be available from Area1 LogObject or the Area2 LogObject.

Figure A.4 – Vendor Specific LogObject individual Storage

The store could also just be a central store, which stores all LogRecords from all LogObjects (see Figure A.5. The GetRecords call on each object could be redirected to the central store (along with the LogObject Identifier) and then the appropriate LogRecords (corresponding to LogObject on which the Method was invoked) would be pulled from the central store.

It would be important for this type of architecture that the MaxDuration / MaxRecords / MinimumSeverity be only set on the parent LogObject since it would be difficult to manage all of the individual LogObjects.