Because Conditions always have a state (Enabled or Disabled) and possibly many sub-states it makes sense to have instances of Conditions present in the AddressSpace. If the Server exposes Condition instances they usually will appear in the AddressSpace as components of the Objects that “own” them. For example, a temperature transmitter that has a built-in high temperature Alarm would appear in the AddressSpace as an instance of some temperature transmitter Object with a HasComponent Reference to an instance of a LimitAlarmType.

The availability of instances allows Data Access Clients to monitor the current Condition state by subscribing to the Attribute values of Variable Nodes. The values of the nodes may not always correspond with the value that appear in Events, they may be more recent than what was in the Event.

While exposing Condition instances in the AddressSpace is not always possible, doing so allows for direct interaction (read, write and Method invocation) with a specific Condition instance. For example, if a Condition instance is not exposed, there is no way to invoke the Enable or Disable Method for the specific Condition instance.