State Monitor program
Status
Current version 1.47.791.204 , September 2024
From version 1.47.791.204:
* Export and import to text file now includes header information and version check.
* Fixed Log window scrolling problems - was really bad when many logs ~10000 in the error list.
* Show different number of loggings in logView: 100 at startup, 1000 (reduced) after first scroll,10000 if not reduced pressed.
* New fast way to overview the main logging options in the state tree by symbols before name in state tree.
* Improved state informations, added more/all options to the state views.
* Fixed: ConSysState: CStateCompareFloat Export to file/Import from file missing attributes
* Property sheets 'Apply' never active - removed
* REMOVED CLASSES CStateFloatCompare and CPropPageStateFloatCompare from ConSys code.
From ConSys version 1.47.605 the device state/StateMonitor serialization format is 7. The serialization version must be the same for the state device and the StateMonitor - and must be set in the State Server table in the ConSys database.
Compare methods: 'Compare G64 (old)' should be replaced by the new common compare method 'Compare Float' 'Compare G64 (old)' is still used in a lot of state controllers. For this reason, the code for 'Compare G64 (old)' will be keept in the code, but all new compares defined should only use the 'Compare Float' method.
- Concepts
- State level (bitmaps)
- Controller list
- State Tree Apperance
- Editing the controller state tree
- State types
- Configuration import/export
- Command line options
Bit
Floating point
Word
AND
OR
XOR
Floating point compare 
ControllerReferences:
Overview:
The state system is able to monitor and log status and alarms in the ConSys control system. It consist of to major parts - the state device server managing the state structures and maintaining the data - and the State monitor program for display and user interaction. The StateMonitor/State device system is implemented as a client/server system with configurational and run time data stored in the state device server.
Concepts:
State
The state is the base concept in the state system. The status of a state is represented by a status level given by the 5 levels listed below. There are many different state types each with their own specific purpose. They all share a common set of features. The simplest specific state types are the states for the standard ConSys data types like bits, floating point and word. Each specific state type defines how the status level and other type specific features are handled/calculated.
0: 
Invalid state - typical because no connection to the control system or a stopped controller.
1: 
Error
2: 
Old error - an error has occurred but is no longer present.
2: 
Warning
3: 
Attention
4: 
Ok
For bit, word and floating point states: Special state level bitmaps for 'Error' when 'SE:' is present in the beginning of of the state name. The error state is shown in dark red instead of red in these cases. Example for bit state:
The meaning of SE: at the beginning of State Name is "Suppress Error". It is a technique that with an OR-state one can suppress an error if the error is not "real". An example could be one wants to suppress a missing power supply on-status if the power supply intensional is turned off. For further examples and use come see a ConSys expert.
State tree
Some state types include other states as sub states. These state types are in general categorised as 'state trees'. Typical state trees are the binary state operators - all having a set of sub states from which the resulting status value is calculated according to the particular operation. It is important to design the state trees with care to obtain an efficient error and state control display. In general, one should aim for logically related parameters appear in related groups in the three structure. Try to avoid identical or almost identical sub trees. If a common structure should be used in several sub trees, this structure must be defined as separate state controllers as described below.
Controller
A controller is basically a collection of states. It is the responsibility of the controller to store and maintain the states and manage the operation of the states. On the client side, the controllers take care of user interaction (display, editing of the state structure, activation/deactivation etc.). On the server side, the controllers are responsible for the connection to the control system and the maintenance of the current status of the states. When a controller is activated, the server side of the controller informs all connected client controllers of all changes in the status of the states.
The controller stores the states in a tree like structure. States defined without a owner state are called root states. If a state can own other states it is called a state tree - and the states it own its sub states. A State tree can be a sub tree of another state tree thereby building complex state structures. The controller evaluates the state tree status from the 'tree leaves' and upwards. The leaves will typically be simple state types that directly relate to ConSys parameters. The state tree types typically are logical operations between sub states.
Statemonitor program overview
As mentioned above the ConSys alarm and status system is client/server based. The client, the StateMonitor program, is used to display the current states as well as maintaining the configuration of the state devices. The StateMonitor can connect to several starte servers. When a state server is selected during start up or by the select state server command, the state server sends a list with a description of the controllers it services. The StateMonitor program presents the controllers in a list view window, the controller window. Double clicking on a controller will open a new window, the state view, showing the state trees defined in the controller. The state view has tree sub views: To the left, the state tree view for display and editing of the state tree, in the upper right corner a view with detailed information on the selected item in the state tree, and finally in the lower right view a log view with a list of messages generated by the states in the controller state trees.
The Controller list
The controller list view is used to overall control and overview of the controllers running at a state device. Each controller is identified by a unique name ‘Controller’. The controller’s name cannot be changed after it is defined because it is used as addressing in ConSys – and internal files associated with the device. (From version 1.47.614.230) The sort order of the controllers can be changed by clicking at the column header. The default sort order is given by the ‘Position’ set in the ‘Position/Order’ field in the controller configuration.
State Tree Appearance
The state tree represents the configuration of the controller as well as the current state of the states in the tree. Each state is represented with a state type icon State types, followed by a state bulp indicating the actual state level. After the state level follows log option indicaters (see just below) and finaly the state name.
When the controller is in edit mode, the entire state tree will show as invalid states.
The log option symbols are meant as an fast way to overview the main logging options in the state tree. The logging symbols are added before the state name in the state tree if the corresponding option is fullfilled. The meaning of the symbols are:
‼ Double Exclamation Sign: If present, logging is enabled for the state.
♪ Music note: If present, logging is enabled and at least one SMS notification (O1,O2,O3,...) is checked.
† Dagger: Used for tree type states. If present, it is possible for child at messages propagate through the tree state (still depending on actual options, tree state and message state.). Ie. for the dagger to be present 'Accept Log|Enable logging' must be enabled, at least one type of log state must be accepted and at least one tree state must also accept the logging.
Editing the controller state tree
Editing of the State monitor controller trees is done from the StateMonitor program. Remark that editing works directly on the state device controller – so before major changes it is recommended to make a backup copy of the controller configuration (.sds) in the ConSysExe share on the ConSys frontend that services the state device. States can be created and edited directly in the control tree by right clicking on the tree item to edit and choose the edit action. Some settings can be changed while the State Tree is active, others require the State controller to be stopped before editing. Another way of editing is by exporting the full or part of the state tree to a text file, edit the text file and importing the changes into to the same or another controller again. Again, it is highly recommended to backup the state (.sds) file before importing into to a state tree.
State types
When edited/configured from the StateMonitor, the settings for each state in the tree will be setup from a number of property pages in a setup dialog. Some of these property pages are common for all state types. These pages are:
General State and Settings: Name and description of the state.
The activation mode of the state. When 'Mode' is active, the state level depends on the actual state of the state. The mode can also be set Inactive with the state level set as selected. If 'Mode' is set to one of the inactive states, the state can be set to automatically activate again at given time. Inactive states appear as strikethrough states in the state tree.
Enable Logging: If checked, log messages will be generated for the checked 'Log Levels'.
Require active: If checked, the state must be active before accepting messages.
Log levels check boxes: The checked state levels will generate a message to the log view when set. The text will either be generated from the name, type and description or set as specfied in the corresponding 'Custom Text' field.
Play Audio: If >0, the selected audio will be played when the state is trigged.
SMS notification: Whenever a message is generated for this state it will be send to all checked SMS notification slots.
The bit state connects to a ConSys bit type, and can be set to have any state for each of the two bit values. The bit state will return invalid state when the specified parameter is disconnected from the control system.
Parameter: Must specify a full qualified ConSys bit in the format <parameterName>.<surName>
Low bit: state return value when the selected bit value is low.
High bit: state return value when the selected bit value is high.
Remember error: If checked, an error will be remembered until it is manually or automatically cleared.
The state will return old error (when the current state result is >=warning) or error until the error memory is cleared.
The floating point state test the range for a ConSys floating point value. Four range limit values defines five ranges. The resulting state can be set for each of these ranges. The limit values must be given in increasing order. The value invalid state is returned when the specified parameter is disconnected from the control system.
Parameter: Must specify a full qualified ConSys floating point parameter in the format <parameterName>.<surName>
L1..L4: Range limits in increasing order.
'Result values': state return values for the specified ranges.
Remember error: If checked, an error will be remembered until it is manually or automatically cleared. The state will
return old error (when the current state result is >=warning) or error until the error memory is cleared.
'Hysterisis': When the parameter has crossed a Limit it must again get
under (Limit - Hysterisis) to go back in the lower range.
Like the floating point state - must specify a ConSys word parameter.
Return a constant state value.
State: constant return value.
Tree states are states that take a list of sub states and combine them using the binary operators AND, OR or XOR. The relavant operator page includes a list of sub states between which the binary operation takes place. Other settings depend on the binary operator type, see the individual descriptions below.
Accept log page for tree states: All tree states have 'Accept Log' settings that defines how messages from leaves/childs should propagate towards the root of the tree - and thereby ending up actually being logged/reported. If a message from leaves/childs are not accepted by the accept log settings, the message is discarded.
Accept log, Enable logging: Must be checked in the tree state item for any child state message to be accepted.
Accept log, Require active: If checked, the tree state item must be in an active state for any child message to be accepted.
Log State check states (Error,Warning,Attention,Ok): The child message will only be accepted if the child log message is of one seleted log types. I.e. in order for an error message from a child to be accepted the 'Log State|Error' checkbox must be checked.
Tree State check states (Error,Warning,Attention,Ok): These checks relates to the tree state (AND,OR,XOR) state of itself. Child messages will only be accepted if the tree state is one of the checked tree states. I.e. in order to accept a child message if the tree state itself is in error, the 'Tree state|error' must be checked.
The logical AND operator returns the lowest status level among its sub states (i.e. the "most erroneous"). If any substate is invalid the result is always invalid.
Configuration settings:
"Error if not all 'ok'": If selected: Return error(1) unless all sub states is ok(4)
Examples - three sub states, no options set:
error, ok, attention => error
attention,warning,ok => warning
ok,ok,ok => ok
The logical OR operator return the highest status level among its sub states (i.e. the "least erroneous"). If any substate is invalid the result is always invalid.
Configuration settings:
"Ok if at least one state not in error": If selected: Return ok(4) if at least one state is >= warning(2).
Examples - three sub states, no options set:
ok, error, warning => ok
error, attention, warning => attention
The XOR operator checks for 'identical' status levels among its sub states. It works like a binary xor operator where warning, attention,ok are considered as TRUE and error,old error are considered as FALSE. If at least one sub state value is less than or equal to old error and at least one sub state is greater than or equal to warning the result is ok. If this is not the case, the result is error unless all sub state values are old error in which case the result is also old error. If any substate is invalid the result is always invalid.
Examples:
error, error => error
error,warning => ok
attention,old error => ok
ok,error,warning,attention => ok
ok,ok => error
ok,attention,warning => error
old error, error => error
old error, old error => old error
The floating point compare state is used to compare two floating point ConSys parameters against each other. The parameters to compare can be any floating point parameter - and the device will optimize the way to compare dependend on the location of the parameter. If the parameters to compare is located on the same computer and loader instance a floating point compare dataserver is used to make an efficient compare directly on the device service computer. In this case data is only send between the server and the ConSysState device when the compare result changes. If the parameters to compare are located on different ConSys loader instances, then each parameter is requested independenly by the state compare and the actual compare is done in the state device - in this case all source parameter values have to be send to the state device to be compared.
The result of the compare will come as a comparison between the difference of the two parameters and an absolute difference plus a relative difference based on parameter 1. If 'Absolute Compare' is checked, the compare method will use the absolute difference between parameter 1 and 2 in the compare method. And, if 'Absolute Compare' is unchecked, the difference used is directly 'Parameter 1' - 'Parameter 2'. In most compares 'Absolute Compare' should be checked.
The Controller State is used to connect to another controller. Before a controller can be used as sub controller in another controller tree, the sub controller state parameter must be defined in the ConSys SQL database - see the device setup for details. The state of a sub controller is calculated like the AND operator on the controller root states. If the selected controller is stopped or not existing, the controller state return value is invalid state.
Controller parameter: Full ConSys parameter name for the 'state' part of the controller, <parameterName>.<surName>
Remember error: If checked, an error will be remembered until it is manually or automatically cleared. The state will return old error
(when the current state result is >=warning) or error until the error memory is cleared.
Configuration import/export
The state tree structure of a controller or a selected sub tree of a controller can be exported to a text file. This feature is meant for
text-based editing of the state tree. Using a text editor (like NotePad++) it is very easy to copy structures and then do either manuel editing (of say parameter
names) or do "Search and Replace". Remember that right-click on a parameter in the Console allows to save the parameter name to the clip board.
The state text files should be regarded as temporary work
files, as the file format will change when new functionalities are added to the program. The import method should be used with
care - there is no error handling and in case of mistakes in manual edited files anything could happen - wrong settings in the imported states, partly read files etc.
It is wise to keep the original export file as a backup, so it can be read back into the controller in case the edited file is messed up
(but note it is only a valid backup during the editing process -
Do NOT rely on the export files as a longturn backup). For advanced users the StateDevice configuration files in the ConSys Persistent folder can alternatively be used as backups.
Exporting a full controller: In the state tree view: click on the right mouse key and select 'Export'. A text file with all states in the controller is now generated with the name specified in the dialog following the export command.
Exporting a sub tree: In the state tree view: Select the tree to export and right click with the mouse. Select 'Export selected tree'.
Import: In order to import state setups, the state view must be in edit mode.
Import into the root of the controller: Right click and select 'Import'. Choose the file you want to import. The states
defined in the selected file will be added to the root states.
Note also the easy "Delete all & Import" option, which does what it says (delete all states and import a setup from file). Goes neatly with the full "Export".
Import into selected state: It is possible to import state settings from a text file into a selected state if the selected state accepts sub states (and, or, xor). Right click and select 'Import into selected'. Choose the file you want to import. The states in the selected file will be added to the selected state sub state tree.
File format:
The import/export file in comma delimited text format. Each line is prefixed with a single character specifying the line content type.
If the format character is unknown, the line is ignored. Commas or '#' must separate all data values in a line. Tabs and spaces are ignored.
Text must be surrounded by ' '. Booleans must be 0 or 1. Each state in the state tree appears as a single line in the file. The order of
the states in the file must follow the tree structure: The first state in the file is the top root item in the tree. Sub states declarations
belonging to a given tree state must follow the tree state declaration.
Header:
From version 1.47.790.203 the export file includes a header section. The header section includes export file version, export time, controller name and more. The
export file version is checked when importing the setup. The initial version is set to 1. Existing export files without header info will be read in as version 0.
If version number of the imported file does not match the current version of the StateMonitor a warning is given before importing the states. If the user chooses to
import a nonmatching version care must be taken as fields may be wrong. If case of importing a file with a version number lower than the current version future
versions of StateMonitor should take care of the differences and set default values to new fields in the data format. The header also contains
a description of the export state formats. The export state is from this version split into sections, each section separated by
# instead of comma between the data values.
S: State format
A state item declaration is defined by a single line with a list of configuration settings in the import/export file. Parameters
common for all state types are placed from the beginning of the line. State type depended settings are following the common settings. From version
1.47.790.203 exported parameters are divided into sections that in some degree match the property pages for configuring the state.
Each section is separated by '#' instead of comma. The content of sections is from this version listed in the header of the exported file. In
the export file an indent consisting of two spaces is added for each tree level.
Common parameters, in the order they appear in the setup line:
|
Tree Level |
Integer |
Zero based tree level |
|
State type |
Integer |
0:Bit, 1:Floating point, 2:And, 3:Or, 4:Xor, 5:Word, 6:Constant, 7:Controller, 8:Compare |
|
State type name |
Text |
The state type in text format. |
|
Name |
Text |
State name |
|
Description |
Text |
State Description |
|
Enable Logging |
Boolean |
Enable/Disable the logging for the state |
|
Auto activate |
Boolean |
Auto activate enable/disable |
|
Active status |
Integer |
0: Active, >0: Inactive, constant state result: 1:Error, 2:Warning, 3:Attention, 4:Ok |
|
Activation time |
Text |
Currently 'notime' |
Bit state, additional settings:
|
parameter |
Text |
ConSys parameter in the format <name>.<surname>, must specify a ConSys bit |
/p or /pos (<x>.<y>,<width>,<height>)
Set initial position and size. Format /p [x] [y] [width] [height]
/i or /id <StateServer table id>
Startup with state server given by the <StateServer table id>. At ISA, values are
| Id | Name |
| 1 | State Test Server (D39094) |
| 2 | ASTRID State server (FEC14B) |
| 3 | ASTRID2 State server (FEC09B) |
| 4 | Windtunnel State server (presently not used) |
/c or /controller <Controller Name>
Startup with controller given by the <Controller name>. In order to use this option the state server option /i must also
be specified and the controller must be a controller name in the found at the state server specified by the /i command.
Last Modified 18 September 2024