At any given time, objects in system:inmation exist in a state that is dependent on its situation regarding connectivity and functionality. The state of an object changes when it is enabled/disabled, connected/disconnected or some other action happens.
The current state of an object in system:inmation is stored as a flag group (or bitmask) containing different elements corresponding to different aspects of the state of the object. This is non-configurable by the user but is visible in DataStudio (through the Faceplate or the Object Properties panel header) and read-accessible through the SCI and Lua Script.
The first element of the state bitmask describes the communication state of the object, the second element describes the actual state of the object (good, warning or error: indicated in DataStudio by green, yellow and red lights). Other elements in the bitmask can optionally contain other information about the object (for instance, is the object is enabled; does it have object references).
The object state bitmask can be populated by the following state flags:
|State Flag||State Type||Description|
|COMM_EMPTY||Communication||This flag is present for objects that don’t have direct communication capability. This is the case for most objects except for the Core, Connector and DataSource objects.|
|COMM_NEUTRAL||Communication||Communication state is neutral. For example, when a Connector or Datasource object is disabled.|
|COMM_GOOD||Communication||Communication state is good. For example, when the Connector is enabled and communicating with the Core.|
|COMM_WARNING||Communication||Communication state is Warning. There is partial communication however the protocol is incomplete. For example, security credentials for part of the protocol.|
|COMM_ERROR||Communication||Communication State Bad. For example, when a Connector is unable to connect to the Core.|
|STATE_EMPTY||Actual State||Object State Empty. Applies only to Relay Objects.|
|STATE_NEUTRAL||Actual State||Object State is neutral, for example when an item is disabled.|
|STATE_GOOD||Actual State||Object State is good, for example when an I/O item is subscribed and producing real-time updates.|
|STATE_WARNING||Actual State||Object State is Warning. For example, when an object is not properly configured.|
|STATE_ERROR||Actual State||Object State is Error. For example, when a dynamic I/O item is not updating.|
|OBJ_ENABLED||Additional||Object is enabled.|
|OBJ_DYNAMIC||Additional||Object is dynamic, for example an I/O that produces real-time values.|
|OBJ_SECURITY_REF||Additional||Object has a security reference.|
|OBJ_OBJECT_REF||Additional||Object has a reference to another object.|
|OBJ_EXPLORING||Additional||Object is exploring, for example when a Datasource is being browsed.|
|OBJ_REGISTERING||Additional||Object is Registering. For example, when an OPC Datasource registers in the system.|
COMM_GOOD | STATE_GOOD | OBJ_ENABLED
COMM_EMPTY | STATE_GOOD | OBJ_ENABLED | OBJ_DYNAMIC
COMM_EMPTY | STATE_ERROR | OBJ_ENABLED | OBJ_DYNAMIC
Objects in system:inmation can also have auxiliary states. These are not covered by the state flag group described above and are indicated by the Auxiliary State Management when changes to objects happen in certain situations.
An example of one of these situations is an I/O item in an OPC server namespace at system startup: when the Connector starts, it connects to the OPC server and starts to receive data. Before the connection is fully established though, the I/O items are in a certain state while the system waits for data, this is recognized by the system and classified as an auxiliary state. This is also the case when an item is disabled and enabled again, the I/O item exists in an auxiliary state after being disabled.
Auxiliary states are important for the user to know as they indicate when a service has gone down or was restarted. If an item remains in an auxiliary state for a continuing period of time, it can be indicative of other problems present in the system and help with diagnosing the root cause of the problem.
Auxiliary state indications are also visible if using the SCI Events to subscribe to data items.
For example, the returned VQT for an I/O object just after startup or enabling is:
2017-01-22T12:00:00Z <No Value> BadWaitingForInitialData
2017-01-22T12:00:00Z <No Value> BadOutOfService
If viewing a History Trend display, the incidents of objects being in an auxiliary state will be shown by breaks in the trendline and red, bad quality indicators.
The management of auxiliary states can be configured by the user. The options allow the user to turn off or Inhibit the auxiliary state indications. This can be useful when making history calls as breaks in service or disconnections are often expected as a regular part of normal operations and are not always problematic. Inhibiting the auxiliary state management (ASM) prevents the states from being recognized and persisted to the archive. Therefore, History Trend displays will show uninterrupted trendlines, even if there were breaks in service or disconnections.
In the default ASM mode, objects Inherit ASM settings from the parent object. If all objects in the tree inherit the ASM settings up to the Root object then the ASM mode is Persist (see table below). In this mode, individual objects can be electively set to Inhibit the auxiliary states.
The full list of Auxiliary state management modes is shown in the table below:
|Auxiliary State Management Mode||Auxiliary State Persisted||Description|
|Inherit||Depends on parent object||The auxiliary state management (ASM) mode is inherited from its parent object or an object higher up the tree (if the parent ASM is also set to Inherit). This is the default setting for all objects in the system. If the inheritance chain reaches the root object then the mode is Persist.|
|Inhibit||No||The ASM is turned off completely. Objects do not enter auxiliary states in the situations described above. Therefore, auxiliary states are not indicated or persisted to the archive.|
|Persist||Yes||All object auxiliary states are indicated and persisted to the archive.|
|Volatile||No||ASM changes are indicated but not historized.|