.. _state_engine_viewer:
State Engine Viewer
===================
The state engine viewer provides visible access to all SCXML based state-machines
that publish their state changes via rsb. You cannot alter any behavior but instead
observe state changes of said state-machines.
The engine-viewer's behavior is explained with the help of the following screenshot:
.. figure:: /images/software/taskvis.png
:scale: 100 %
:figclass: align-center
A screenshot of the engine viewer component.
The general direction of reading is **top-to-bottom** as indicated by the red arrow.
Every time a state-change occurs, a new row is being inserted into the table which
is then automatically highlighted. Furthermore, the very next row is being cleared
for readability. Please note that the visualization does not provide a scroll-back
history but wraps around like a ring buffer.
Each state-change (row) is thereby characterized by a time-stamp, the name and
unique identifier of state-machine that the change occurred in. The **prior state (a)**,
the **reason for changing (b)** if applicable, and the new **current state (c)**
are given in the next three columns. For example, the highlighted row in the
screenshot is caused by a change from the state *InvokeTask* to *Ready* because
the invoked sub state-machine with the name *task* completed. The state-machine
*Coordination* therefore currently is in the *Ready* state.
In the **bottom part of the window (d)**, a summary of all observed state-machines
by their name is given. The number in square brackets indicates how many different
state-machines (by identifier) with the same name have been observed. Because for
example every task consists of a newly invoked state-machine, one can see the total
number of executed tasks while the visualization has been running. The coordination
should in general only occur once except the component has been restarted.
The latest observed state is colored in blue. Error states are highlighted in orange,
success in green.
If you are not interested in certain events, a simple text filter can be applied
in the **filter text field (e)**. As a typical example, if you are only interested
in coordination and behavioral states, you can filter out all events of the
*Recording* process. Additionally, you can (re-)start the observing and alter the
default listening scope if really needed.
Related resources
-----------------
Currently, in the apartment there are at least two SCXML based
state-machine-components that can be investigated: :ref:`scenario_coordination`
and :ref:`auto_recording`. These three components also share the same repository.
Component repository:
- Browse component repository: `scenario-coordination-cfg `_.
- ``git clone https://projects.cit-ec.uni-bielefeld.de/git/lsp-csra.scenario-coordination-cfg.git/``
System startup:
- The ``engine-viewer`` component can be found in ``lsp-csra-supplementary.sh`` on the ``tools`` tab.
- The component script is called ``component_engine_viewer``
- Start via console: ``$ csra-engine-viewer``
Related projects:
- Browse repository `system-startup `_.
- Browse IDE project `rsb-dsl `_.