Conditionsare used to represent the state of a system or one of its components. Some common examples are:

  • a temperature exceeding a configured limit
  • a device needing maintenance
  • a batch process that requires a user to confirm some step in the process before proceeding

Each Conditioninstance is of a specific ConditionType. The ConditionTypeand derived types are sub-types of the BaseEventType(see OPC 10000-3and OPC 10000-5). This part defines types that are common across many industries. It is expected that vendors or other standardisation groups will define additional ConditionTypesderiving from the common base types defined in this part. The ConditionTypessupported by a Serverare exposed in the AddressSpaceof the Server.

Conditioninstances are specific implementations of a ConditionType. It is up to the Serverwhether such instances are also exposed in the Server’s AddressSpace. Clause 4.10provides additional background about Conditioninstances. Conditioninstances shall have a unique identifier to differentiate them from other instances. This is independent of whether they are exposed in the AddressSpace.

As mentioned above, Conditionsrepresent the state of a system or one of its components. In certain cases, however, previous states that still need attention also have to be maintained. ConditionBranchesare introduced to deal with this requirement and distinguish current state and previous states. Each ConditionBranchhas a BranchId that differentiates it from other branches of the same Conditioninstance. The ConditionBranchwhich represents the current state of the Condition(the trunk) has a NULL BranchId. Servers can generate separate Event Notifications for each branch. When the state represented by a ConditionBranchdoes not need further attention, a final Event Notificationfor this branch will have the Retain Propertyset to False. Clause 4.4provides more information and use cases. Maintaining previous states and therefore the support of multiple branches is optional for Servers.

Conceptually, the lifetime of the Conditioninstance is independent of its state. However, Serversmay provide access to Conditioninstances only while ConditionBranchesexist.

The base Conditionstate model is illustrated in Figure 1. It is extended by the various Conditionsubtypes defined in this standard and may be further extended by vendors or other standardisation groups. The primary states of a Conditionare disabled and enabled. The Disabledstate is intended to allow Conditionsto be turned off at the Serveror below the Server(in a device or some underlying system). The Enabledstate is normally extended with the addition of sub-states.


Figure 1– Base Condition state model

A transition into the Disabled state results in a Condition Event however no subsequent Event Notificationsare generated until the Conditionreturns to the Enabled state.

When a Conditionenters the Enabled state, that transition and all subsequent transitions result in Condition Eventsbeing generated by the Server.

If Auditingis supported by a Server, the following Auditingrelated action shall be performed. The Serverwill generate AuditEventsfor Enableand Disableoperations (either through a Methodcall or some Server/ vendor – specific means), rather than generating an AuditEvent Notificationfor each Conditioninstance being enabled or disabled. For more information, see the definition of AuditConditionEnableEventTypein 5.10.2. AuditEventsare also generated for any other Operatoraction that results in changes to the Conditions.