1 Scope

Editors Note: This specification has limited implementation to validate the design. Subsequent implementations and interoperability testing may result in breaking changes in future versions of this Part.

This document provides an Information Model for a set of Objects and Events that can be used to collect diagnostic information in a system. The LogObject model and related Events, Methods and Datatypes are defined in this specification.

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

OPC 10000-1 – OPC Unified Architecture - Part 1: OPC Overview and Concepts

https://opcfoundation.org/documents/10000-1/

OPC 10000-3 – OPC Unified Architecture - Part 3: Address Space Model

https://opcfoundation.org/documents/10000-3/

OPC 10000-4 – OPC Unified Architecture - Part 4: Services

https://opcfoundation.org/documents/10000-4/

OPC 10000-5 – OPC Unified Architecture - Part 5: Information Model

https://opcfoundation.org/documents/10000-5/

3 Terms, definitions, abbreviated terms, and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7, OPC 10000-9, OPC 10000-22, as well as the following apply.

All used terms are italicized in the specification as described in OPC 10000-1.

3.1.1 LogRecord

An instance of a LogRecord Structure

4 OPC UA LogObject

4.1 Overview

This specification defines a standard Object that can be used to collect information, like diagnostic information, in a standard manner. This Object can collect information defined in base specifications, companion specifications or even generated by an application that is loaded into a device or Server. This allows a standard Client to access the information and provide a standard manner for user access to this information.

The LogObject returns LogRecords via the GetRecords Method.

The LogRecords when they are generated, can also be sent as Events (see 6).

The LogObject does not define how the information is stored, only how it can be collected and how it can be accessed. This allows a vendor to choose the most appropriate storage for the information.

The LogObject is illustrated in Figure 1.

Figure 1 illustrates both a predefined LogObject (ServerLog) and application defined LogObject (MyApplicationLog). The green boxes are defined in this specification, the blue boxes are defined in OPC 10000-5 or OPC 10000-22, the orange boxes are defined in the OPC UA FX specifications and the grey boxes are not defined in any specification.

Annex A and Annex B provide additional examples of LogObjects and possible Client uses and Server implementations.

This specification defines ObjectTypes, EventTypes, ConditionClass and instances (see Figure 2). Not all of the illustrated types/instances are required for an implementation and are covered by separate ConformanceUnits and Facets.

5 LogObjectType

5.1 Overview

The LogObjectType is an ObjectType that is used to define an instance that collects log messages and make them available to a Client. A LogObject can contain LogRecords that were generated internally. It can also contain LogRecords that result from Events that have a ConditionClassId or ConditionSubClassId of LogEntryConditionClassType that are reported by the Object on which the LogObject instance is declared (see 6). The LogObject can also generate Events for LogRecords that were generated internally.

The underlying storage of LogRecords is not defined. The LogRecords could be stored as part of an EventHistory or stored in SYSLOG or OpenTelemetry or in some application specific manner (see Annex A for illustrations).

Although this specification does not define how data is stored, a requirement to persist LogRecords (i.e. LogRecords will be retained following a restart) is defined in a ConformanceUnit and may be added to a Profile.

The LogObject exposes a Method that allows a Client to retrieve the LogRecords. This Method does not provide complex filtering, only a time range and Severity. It also provides a RequestMask that allows the Client to select which fields in a LogRecord to return and a maximum number of LogRecords to return. Some LogObjects may optionally expose HistoricalEvents which would allow a more complex Event retrieval filter (see HistoricalEvent retrieval in OPC 10000-11).

The LogObjectType is illustrated in Figure 3.

5.2 LogObjectType definition

The LogObjectType is formally defined in Table 1. The LogRecord Structure that is returned by the GetRecords Method is described in 5.5.

Optional MaxRecords defines the maximum number of LogRecords in a buffer associated with this LogObject. When this maximum is reached, a new LogRecord will trigger the deletion of the oldest LogRecord. If this Variable is not provided, then there is no Server published limit on the log buffer. Zero is an invalid value for MaxRecords.

Optional MaxStorageDuration defines the maximum time period that the LogObject will buffer LogRecords associated with this LogObject . LogRecords that are older than the maximum duration may be deleted. If this Variable is not provided, then no maximum duration is configured. Zero is an invalid duration. In the case of persistent storage, on startup a number of LogRecords may be deleted, depending on the duration of the downtime for the application.

The two maximum settings are used to limit the storage requirements for a Server. MaxRecords is typically a hard limit while MaxStorageDuration is more a soft limit in that LogRecords may be retained past the MaxStorageDuration if space allows. If MaxRecords is exceeded before MaxStorageDuration, the system should generate a LogOverflowEventType Event indicating an overflow of LogRecords (see 6.4).

The MinimumSeverity describes the minimum Severity of LogRecords associated with this LogObject. LogRecords with a Severity that is less than this number will not be available from this LogObject. If omitted, there is no restriction on the Severity associated with LogRecords associated with this LogObject. This number shall be between 1 and 1000, any other number is Invalid. Servers may allow this value to be written. The Severity is only checked when a LogRecord is being generated, a change to the value shall not affect the LogRecords that are already associated with this LogObject.

5.3 GetRecords Method

This Method allows a Client to retrieve LogRecords associated with this LogObject.

The signature of the Method is described below, and the arguments are described in Table 2.

Signature

	GetRecords (
	  [in] 0:DateTime			StartTime,
	  [in] 0:DateTime			EndTime,
	  [in] 0:UInt32			MaxReturnRecords,
	  [in] 0:UInt16			MinimumSeverity,
	  [in] 0:LogRecordMask		RequestMask,
	  [in] 0:ByteString			ContinuationPointIn,
	
	  [out] LogRecordsDataType	Results,
	  [out] 0:ByteString		ContinuationPointOut
	);

StartTime and EndTime together form the range in which LogRecords are returned. If StartTime equals EndTime, then only LogRecord(s) that have the provided time are returned. If EndTime is earlier than StartTime, then the error Bad_InvalidArgument shall be returned.

MinimumSeverity is a number between 1 and 1000 inclusive, a number outside of this range shall result in the error Bad_InvalidArgument (see Table 9 for additional details).

A ContinuationPointOut shall be generated if the number of LogRecords to return between StartTime and EndTime is larger than what can be returned in a single Method call. It can also be returned due to an internal error or any issue in the Server.

Method result codes in Table 3 (defined in Call Service).

The GetRecords Method representation in the AddressSpace is formally defined in Table 4.

5.4 ReleaseContinuationPoint Method

This Method allows a Client to release a LogObject ContinuationPoint that was returned to it.

The signature of the Method is described below, and the arguments are described in Table 5.

Signature

	ReleaseContinuationPoint (
	  [in] 0:ByteString			ContinuationPointIn
	);

Method result codes in Table 6

The ReleaseContinuationPoint Method representation in the AddressSpace is formally defined in Table 7.

5.5 LogRecord structure

This structured DataType describes the required information in a LogRecord. An array of this structure type is returned as a field in a structure in the LogObject GetRecords Method call.

The structure is formally defined in Table 8.

Severity ranges for Alarms and alerts are discussed further in OPC 10000-9. Table 9 provides the Severity ranges that shall be used for LogRecords. Other specifications, vendors or end users may further subset these ranges or generate thier own names for the ranges. For example, the Emergency range described in SYSLOG is commonly used for process alarms and would have multiple sub ranges defined by end users. In the manufacturing industry, typically the SYSLOG Alert range would be considered as Warnings and the Emergency range would have been renamed Error and have multiple sub ranges (i.e. CriticalError, MiniorError...).

The LogRecord representation in the AddressSpace is formally defined in Table 10

5.6 LogContext Structures

5.6.1 Overview

The LogContext contains information required to trace distributed transactions or requests made to a distributed system. Such a trace may produce multiple log messages in one OPC UA Application and/or multiple log messages across multiple OPC UA Applications.

The TraceId is a unique identifier for a trace. Once assigned it never changes for that trace. If log messages for a given trace are across applications, they have the same TraceId.

A span represents a unit of work or operation. Spans are the building blocks of traces. A span is local to an OPC UA Application. The SpanId is a unique identifier assigned by an OPC UA Application for a local span in a trace. Spans can be nested. The ParentSpanId provides the reference to the parent span. The ParentSpanId is used to build a tree of spans inside a trace. If a nested span is created, the SpanId of the parent is used as ParentSpanId in the new child span.

At the very start (the root span) there is no ParentSpanId, only a new SpanId. This would be the base of a tree. See C.1 for additional discussion on SpanId and ParentSpanId.

5.6.2 SpanContext Structure

The SpanContextDataType Structure is defined in Table 11. It defines a TraceId and SpanId. This Structure can be passed between Clients and Servers (see 5.6.4).

The SpanContextDataType representation in the AddressSpace is formally defined in Table 12

5.6.3 TraceContextDataType Structure

The TraceContextDataType Structure is defined in Table 13. This structure is a subtype of the SpanContextDataType and is used in the LogRecord. It extends the SpanContextDataType Structure adding two additional fields. The ParentSpanId (together with the SpanId) allows for the creation of a tree of related LogRecords. The ParentIdentifier can be used to provide context information related to the parent.

The TraceContextDataType representation in the AddressSpace is formally defined in Table 14.

5.6.4 Passing SpanStructure from a Client

If the Server is to be part of a Client trace, the Client passes the SpanContextDataType structure to a Server.

The SpanContextDataType Structure, defined in Table 11, is passed in the RequestHeader of any OPC UA Service call. The SpanContextDataType is transported with the AdditionalParametersType in the AdditionalHeader field of the RequestHeader (see OPC 10000-4). The Key for the parameter is “SpanContext” and the Value is the SpanContextDataType Structure.

If a Server receives the optional AdditionalHeader, it uses the provided SpanConextDataType Structure when generating any LogRecords that are generated related to the Service invocation that provided the AdditionalHeader. It is possible that lower level functionality that is invoked as part of the Service call, may not have access to the provided AdditionalHeader, in which case it maybe omitted.

Inside the Server, the SpanId from the RequestHeader is used as ParentId for the LogContext structure defined in Table 13.

5.7 NameValuePair Structure

The NameValuePair structure is formally defined in Table 15. This structure has a Name field that is a name that is associated with the value that is reported in the second field. The Value may be of any DataType. Specifications may define standard names that are used to transport specific values that are to be included in the LogRecord as AdditionalData.

The NameValuePair Structure representation in the AddressSpace is formally defined in Table 16

5.8 LogRecordMask DataType

The LogRecordMask is formally defined in Table 17. It indicates which of the optional fields that may be available in a LogRecord are to be returned by GetRecords.

The LogRecordMask representation in the AddressSpace is formally defined in Table 18

5.9 Relationships between LogRecords – A LogRecord Hierarchy

When generating LogRecords it is important that a context be associated with each LogRecord. This context information can be used to show a relationship between various LogRecords in a Server as well as relationships between LogRecords that are in different Servers. This context information is stored in the TraceContext field in the LogRecord (see definition in 5.6.2). If a hierarchy of related LogRecords is to be created, SpanId and ParentSpanId fields shall be used. When a function in a Server invokes another function in the same Server or in another Server as part of the same TraceId, the lower level function shall promote the SpanId of the higher level to be the ParentSpanId in the called function and a new SpanId shall be generated in the called function. This daisy chain of SpanId to ParentSpanId will allow a tree to be created for the LogRecords.

Figure 4 provides an illustration of the LogRecords that could result from calls between two Applications that include TraceContext information. The first line is each table is a list of the fields in the comma-separated-value records. These field names correspond to the names used in the LogRecord structure.

The key points being illustrated for the hierarchy are the TraceId, SpandId, ParentSpanId and ParentIdentifier field, which are the last 4 items in each LogRecord entry. The TraceId is shown as the GUID and is constant for this illustration (it is one action from the Client/Server). Additional actions would result in separate TraceIds, but are not illustrated.

In the Client/Server there is no ParentIdentifier, since all action are internal to the Server. In the RemoteServer the ParentIdentifier indicates the Client/Server. The ParentIdentifier is the ApplicationUri of the Client that called into the Server. The ApplicationUri of the first Server is “Https:CM1…”( it has been truncated to allow it to fit in the example).

The SpanId and ParentSpanId shows where calls have been made. At the beginning of the first table, the ParentSpanId is zero, since this is the root SpanId (see Annex C for more explanation of SpanId). In the first table, when a sub function is called, the SpanId is promoted to the ParentSpanId and a new SpanId is generated (see the third LogRecord in the table).

The large arrow shows that the Client/Server calls into the RemoteServer twice. It passes in the TraceId and the SpanId on each call. The TraceId is the same, but the SpanId changes on each call.

The second table shows the LogRecords that are generated that resulted from the two innovations of the Method in the RemoteServer. The passed in SpanId becomes the ParentSpanId in the LogRecords and a new SpanId is generated. The RemoteServer also makes a call to a sub-function where the SpanId is promoted to the ParentSpanId.

5.10 LogRecordsDataType

This structured DataType is used as the return DataType in the LogObject GetRecords Method call.

The structure is formally defined in Table 19.

The LogRecordsDataType representation in the AddressSpace is formally defined in Table 20.

5.11 LogObject and Security

The LogObject can include information that maybe sensitive or include security related information. LogObjects that contain security related information should not be made accessible to all users, but only to authorised users.

A LogObject can restrict a Client’s access to the GetRecords Method using standard OPC UA security features. This all or nothing approach can work well if multiple LogObjects are defined in a Server and security related information is collected in a separate LogObject. It becomes more problematic if a single LogObject collects a mixture of security related information and non-security related information.

LogObjects should implement permissions similar to what Event systems implement. In Event systems each Event has permissions assigned to it, in a LogObject each LogRecord can have permissions assigned to it. These permissions can be used to determine if a LogRecord should be returned to the Client that is invoking the GetRecords Method.

6 LogObject and Events

6.1 Concepts

A LogObject that supports storing Events as LogRecords extends the behaviour of a LogObject by providing the capability to collect all Events that the parent Object receives that have a ConditionClassId or SubConditionClassId of LogEntryConditionClass.

For example, since Events / Conditions / Alarms instance can be defined by PLC programs and exposed in a Server, the LogObject can collect Diagnostics or other trace information from PLC user program, not just from Server code.

The LogObject can utilize some of the Event reporting hierarchy concepts defined in OPC 10000-3 and OPC 10000-5. Figure 5 illustrates a Server that includes an Event hierarchy. In the example, LogObjectArea2 would include all Events that would be available from the Area2 Object that have a ConditionClassId or ConditionSubClassId of LogEntryConditionClass. In addition the LogObject could store additional fields from Events in the AdditionalData NameValue pairs. What fields are be stored would be vendor / Server specific, but specifications that define LogObject instances may also define additional fields from defined Events that shall be stored in a LogRecord.

6.2 LogRecord EventType Mapping

This specification extends the standard EventType (see OPC 10000-3, OPC 10000-5 and OPC 10000-9 EventTypes) Figure 6 illustrates the event fields that are mapped to the LogRecordStructure. Any Object that has a Reference to one of these EventTypes shall generate LogRecords in the LogObject related to the defined BaseLogEventType.

Additional EventTypes can be defined as needed for specific log information. If desired, subtypes of ConditionType or any of the AlarmTypes might also be used. The only requirement for an Event to be recorded in the LogObject is for the Event to have a ConditionClassId or SubConditionClassId of LogEntryConditionClass. The following describes fields in BaseEventType that are mapped to a LogRecord:

Time – the time associated with this event.

EventType – as defined in BaseEventType in OPC 10000-5

SourceNode – identifies the Node that the Event originated from, as defined in BaseEventType in OPC 10000-5. For LogObject Events, this node is the node that the LogRecord is related to.

SourceName - provides a description of the source of the Event, this might be a browse path to a variable under the SourceNode, if the LogRecord is related to the variable, or it might be as defined in BaseEventType in OPC 10000-5.

Message – shall describe the issue that is being represented in the LogRecord.

Severity – in the Event system is defined as a number between 1 and 1000 inclusive. Typically, the full range of numbers is mapped to sub ranges. See 5.3 for a description of LogRecord use of this field.

6.3 BaseLogEventType

This EventType can be used by an application to generate Events that provide log information.

Its representation in the AddressSpace is formally defined in Table 21.

Events of this type can be generated by Servers that support LogObjects. The Event may be generated for propagation of this Event to an external LogObject.

ErrorCode is associated with the status related to the Node generating the LogRecord. It may be set to Good or Bad with no subcode, if no specific error is being reported. This field may be null or empty.

ErrorCodeNode is the NodeId of the Node related to the problem. This Node may be unrelated to the SourceNode. It may be null if no specific Node is related to the LogRecord.

The ConditionClassId and ConditionClassName in BaseEventType are made mandatory in this EventType.

The ConditionClassId shall be set to LogEntryConditionClassType.

TraceContext is an instance of TraceContextDataType (see 5.6.3). Although it is optional, it is recommended to be provided if the event results from an external action.

6.4 LogOverflowEventType

This Event is generated when the storage in a LogObjectType instance overflows.

Events of this class are generated by Servers that support LogObjects. This Event indicates that the LogObject storage was exceeded before the MaxStorageDuration was reached.

The SourceNode Property for Events of this type shall be set to the NodeId of the LogObject. The SourceName for Events of this type shall be “LogObject/Overflow”.

6.5 LogEntryConditionClassType

The LogEntryConditionClassType is a ConditionClassType used to classify Events that are to be collected in a LogObject. The LogEntryConditionClassType is formally defined in Table 23.

7 Instances

7.1 Overview

The OPC UA LogObject model defines two well-known instances; ServerLog and Logs (see Table 24 and Table 25 and Figure 7). LogObjects may also exist in other locations in the AddressSpace. The ServerLog is a well-known instance that, if implemented, provides all LogRecords for the Server. The Logs object provides a central folder from which all LogObject instances can be found.

7.2 ServerLog

The following instance can exist in Servers if they support LogObjects. It is formally defined in Table 24.

The ServerLog is a LogObject that collects diagnostic information for a Server if it is provided. The ServerLog exposes all LogRecords available in the Server (this shall include all LogRecords in all other LogObjects in the Server).

7.3 Logs

This Object provides a folder that when Organize references are followed, will resolve to all LogObjects defined in the Server (i.e. they are either directly or indirectly referenced from this folder as part of the tree). This folder shall only contain references to instances of LogObjectType (or subtypes of LogObjectType) and references to instances of FolderType (or subtypes of FolderType).

The Logs Object is the target of an Organizes reference from the Resources Object defined in OPC 10000-22.

Its representation in the AddressSpace is formally defined in Table 25.

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.

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.

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.

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.

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.

Annex B LogObject Client Examples (Informative)

B.1 LogObject Client examples

This section provides some examples of clients that could be using the LogObject. The first example is a possible standard diagnostic Client, the second example is of a possible analytic engine.

B.2 Diagnostic client

The diagnostic Client may monitor the general health of a system through status summary information that is outside of the scope of a LogObject. This might be HealthStatus information defined in the DI specification, or diagnostic information define in the UAFX specifications.

When a maintenance worker or engineer discover some problem, they can access a diagnostic Client to trouble shoot the issue. The diagnostic Client can call GetRecords from the Server(s) that are reporting an issue. The LogRecords should provide detailed information allowing the maintenance worker / engineer to diagnose and correct the issue. Typically, this Client would filter and/or sort the information provided by the GetRecords Calls. It might also combine information from multiple Servers. The Client might allow the maintenance worker / engineer to search for specific information.

The Client would only connect to a Server when there is something to troubleshoot.

If a system contains very small devices (with minimum storage), the diagnostic Client might periodically connect the small devices and collect the LogRecords. As an alternative the small device might just generate Events for the LogRecords and let some larger device or the diagnostic Client collect them. The diagnostic Client could store the collected records for a longer period, allowing the maintenance worker / engineer to review a longer history.

Note: Time Syncing functionality is required in OPC UA products, but end users might not enable it, in which case any dianostic Client or analytical engine should check the time on devices to which they are communicating and validate the time on that device.

B.3 Analytic engine

An analytic engine would periodically collect all LogRecords and store them for analytics.

The diagnostic information may be collected in a cloud environment, where it can be analysed. This may be for predictive maintenance or for process optimization. The LogRecord Structure provides fields that can help an analytics engine, by providing correlation information between various Servers (TraceContext), and also the support for the grouping of information inside of a Server (TraceContext).

Annex C OpenTelemetry Mapping (Normative)

C.1 Open Telemetry Overview

OpenTelemetry is described as “a vendor-neutral open source observability framework for instrumenting, generating, collecting, and exporting telemetry data such as traces, metrics, and logs.” This modern system includes an infrastructure for collecting trace / metrics / log data, but this infrastructure may be too resource intensive for constrained devices. In these cases, it would be useful to be able to collect log / trace information and import it into the OpenTelemetry system.

In OpenTelemetry, a client triggered action can be assigned a globally unique trace-id (a 16 byte identifier, excluding 0). This trace-id is maintained for all actions related to the client request. In addition, actions are grouped using a unique span-id (an 8 byte identifier, excluding 0). This span-id might be promoted to a parent-id, when a tree of related trace / log message needs to be generated. This process is illustrated in Figure C.1.

The TraceId in OPC UA is a GUID (16 byte unique identifier). The SpanId in OPC UA is an UInt64 (8 byte integer, excluding 0), and it should be unique inside of a TraceId inside of an application. An easy manner of achieving this is to just increment an UInt64 and persist the last value across the Application. If an Application receives a passed in TraceId and SpanId, the passed in SpanId becomes a ParentId and unique SpanIds are generated in the Application. If an application cannot generate a unique SpanId, then it may leave it as null (see C.2).

Figure C.1 also illustrates how an OpenTelemetry system could collect LogRecords from an LogObject C.2 describes part of the mapping an import tool would have to perform to convert LogObject LogRecords to OpenTelemetry records.

C.2 Open Telemetry System Import

If an OpenTelemetry system is importing LogObject LogRecords, the collector will need to pull information from the TraceContext field. This structure contains the TraceId and SpanId, it might also contain ParentSpanId (if one was provided). The SpanId field is used to group LogRecords together. If the SpanId field is null, then for each unique entry in the GroupingId field, the import tool shall generate a unique SpanId.

TraceId are always random, they are a generated GUID, so the FLAG_RANDOM Trace flag shall always be set.

Bibliography

Agreement of Use

COPYRIGHT RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

OPC Foundation members and non-members are prohibited from copying and redistributing this specification. All copies must be obtained on an individual basis, directly from the OPC Foundation Web site
http://www.opcfoundation.org.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUNDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830.

COMPLIANCE

The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

ISSUE REPORTING

The OPC Foundation strives to maintain the highest quality standards for its published specifications; hence they undergo constant review and refinement. Readers are encouraged to report any issues and view any existing errata here: http://OPCFoundation.org/errata

Revision 1.05.07 Highlights

The following table includes the Mantis issues resolved with this revision.