Skip to content

Commit

Permalink
Updated documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
krichardsson committed May 15, 2023
1 parent c506a01 commit 2db918e
Show file tree
Hide file tree
Showing 3 changed files with 34 additions and 2 deletions.
2 changes: 2 additions & 0 deletions docs/functional-areas/supervisor/conditions.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,3 +10,5 @@ All conditions are collected in a bit field that expresses the full state of the
that are relevant to the supervisor.

All conditions can be found in the `src/modules/interface/supervisor_state_machine.h` file.

The condition bit field is used to trigger [state transitions](transitions.md).
4 changes: 2 additions & 2 deletions docs/functional-areas/supervisor/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,8 +14,8 @@ situations or for protection.

The update sequence is separated into a few steps:
1. Collect data from sensors and the system. We call these [conditions](conditions.md).
2. Based on the conditions, check if the state machine should transition into a new [state](states.md)
3. If there is a state transition, possibly execute one ore more actions
2. Based on the conditions, check if the state machine should [transition](transitions.md) into a new [state](states.md)
3. If there is a state [transition](transitions.md), possibly execute one ore more actions
4. Set the new state

## Modifying behavior
Expand Down
30 changes: 30 additions & 0 deletions docs/functional-areas/supervisor/transitions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
---
title: Supervisor transitions
page_id: supervisor_transitions
---

A state transition takes the state machine from one state to another. The [conditions bit field](conditions.md) is used to identify
which, if any transition to trigger. Transitions are defined as a list per state and are evaluated in order. If a
transition is triggered, the evaluation is terminated and no further transitions will be checked. That means
that the order of a transition list sets the priority, two transitions might have settings that makes both valid, but
the first one will "win".

A state transition is defined with a bit field of triggers. The bits in the trigger bit field are compared to the bits
in the current [conditions bit field](conditions.md) to see if they are set. There is also a bit field with negated triggers where the
bits in the condition bit field should be zero to trigger. To tie it together there is a trigger combiner that describes
the logical operation to use to decide whether the state transition should be triggered or not
* `supervisorAll` = all `trigger` bits must be set and all `negated trigger` bits must be zero in the condition bit field.
* `supervisorAny` = at least one `trigger` bit must be set or at least one `negated trigger` bits must be zero
* `supervisorAlways` = ignore the condition bit field and treat the condition as true
* `supervisorNever` = ignore the condition bit field and treat the condition as false

The second part of a state transition definition is a blocking functionality that works the same way as a trigger, but
is negated. It contains a bit field called blockers, a second bit field called negated blocker and a blocker combiner.
If the blocker evaluates to true, the trigger will not happen.

The final data of a state transition definition is the new state that the state machine will enter, if the trigger
condition is met and the blocking condition is not met.

The system of state transition definitions with triggers, negated triggers, blockers and negated blockers, match with
combiners provides a high degree of freedom. Note that it is possible to express a set of state transitions with trigger
conditions in multiple ways.

0 comments on commit 2db918e

Please sign in to comment.