You can use the enumerated data types facility to apply names to state values. This can be useful as it allows state values to have names that are more descriptive of the value. For example, you can use an enumerated data type to define the state values of a valve as Open and Closed rather than 0 and 1.
Enumerated data types make it easier to understand a program. The more descriptive state values mean it is easy to work out what states the program uses. It also means you can obtain the correct state numbers without referring to the ClearSCADA Database Schema, as you can use any state name to reference a state number. For more information on the ClearSCADA Database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.
Another advantage of enumerated data types is that they reduce the amount of alterations you need to make if you decide to change the states. For example, a valve could have Open to represent state 0 and Closed to represent state 1. If you changed the states so that state 0 meant the valve was closed and state 1 meant the vale was open, you would only need to change the enumerated data types in TYPE sections of your Logic programs. If you did not use enumerated data types, you would need to change the states of every instance of the valve's values.
Enumerated data types have to be defined within the TYPE and END_TYPE keywords. The format for an enumerated data type is:
- <Enumerated data type name>:(<state name>, <state name>);
For example:
- PUMP_STATES:(STOPPED, RUNNING, FAILED, INVALID);
The STOPPED state name corresponds to State 0, RUNNING corresponds to State 1, FAILED corresponds to State 2, and INVALID corresponds to State 3. As you have used state names to reference the various states, you cannot reference the states by number. For example, you cannot reference the RUNNING state as 1.
The number of <state name> entries varies according to the number of states for the item. In each case, the first state name corresponds to State 0, the second state name corresponds to State 1, the third state name corresponds to State 2 and so on.
You can use any names for the states; there is no need to match the state names to the names used in the ClearSCADA Database Schema. However, if you are defining multiple enumerated data types, you need to use different names (an enumeration cannot contain the same name as another enumeration).
Example:
There are enumerations for a valve and a pump. The valve has 4 states that are defined in an enumeration (OPEN, CLOSED, FAILED, and INVALID).
The pump also has 4 states (STOPPED, RUNNING, FAILED, and INVALID). In the pump enumeration, the STOPPED and RUNNING states are acceptable, but the FAILED and INVALID state names cannot be used as the same names are used for the valve enumeration.
To avoid this situation, we suggest that you use item specific state names. So, for the valve and the pump, you would use enumeration states such as these:
- Valve (VALVE_OPEN, VALVE_CLOSED, VALVE_FAILED, VALVE_INVALID);
- Pump (PUMP_STOPPED, PUMP_RUNNING, PUMP_FAILED, PUMP_INVALID);
You can use the same enumeration state names for items of the same type. So if there were two different pumps, you could use PUMP_STOPPED, PUMP_RUNNING, PUMP_FAILED, and PUMP_INVALID as long as both pumps have the same states.