Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

Method for definition of state machines

  Draft

RCAMT-469 - Create first version of subsystem lifecycle definition Finished

General

During engineering work, there might be the need to model state machines in order to specify a concrete state-based behaviour of a structural entity (e.g. component, system, subsystem or object) or in other cases for the behaviour of a function (if required). They are an abstract and formal machine model to describe discrete states and the transitions between those states typically visualised by a state machine diagram. Most common they are also combined with event-based mechanisms which means they consume events to trigger transitions. A state machine works sequential which this means it consumes one input at a time and cannot consume another one during consuming. After it finished the consumption and changed its state due to a transition triggered by that input, it can take the next input. It is good to have this in mind when designing these and also to imagine how the state machine will work step by step. In the context of this method, finite and determinstic state machines are considered. These have finite set of states and state transitions are deterministic, simply spoken a state does not have two equal outgoing transitions (equal means here that the event and guard condition are the same).

In context of a state machine a state is a generalisation of property values and/or history of events. Therefore sets of values and occurences of events are grouped into a such states according to properties that affect the overall behaviour of the entity. Keep also in mind that a state of a state machine must not be same as a discrete state as an input or output of a function (see [DRAFT] Method for definition of states for comparison). However they can correspond, but this must not be the case.

Guidance

The following best practices are recommended to be taken into account when designing state machines.

recommended best practiceexplanationdetails
evaluate need for state machinesThe definition of a state machine can be an overkill (superfluous or useless) for e.g. a simple problem or a behaviour which only does data transformation. This means there might no need to capture the current state as kind of "memory" modelled by a state.

Suitable applications:

  • abstract concept
  • (sub)system lifecycle with operational states
  • functions (only for the cases in which it is an added value or required)

Not recommended for the following problems:

  • functions which takes many input values
  • algorithms, calculations, processes
  • heavy sequencing of events
  • (atomic) statements for evaluation of data and decision making based on elements of that data
  • checking and only conditions and combinations of conditions
lower number of statesRather than defining hundreds of specific states for a state machine, define broad states that together cover the full range of possible states and inputs. Where the entity considers and covers a range of states that all amount to the same behaviour with respect to it define more broadly-defined "super" states (also called complex or composite state) rather than a faithfully-rendered model of many distinct states. When closing a gap (e.g. a state is missing), adjust the definition to make it broader, in preference to creating more states.

State machines tend to get or have a extensive number of states very fast based on the set of inputs it can accept. This can be for the cases that for a number of multiple inputs separate states are needed (e.g. 5 different inputs require at least 5 or more states) which means the number of states can grow very fast depending on the input and the combination of different inputs. Even more if there are different input sources with different input elements for which more states are needed to cover interleaving combination of inputs. 

spend time during engineeringIt is a time/effort-saving measure to focus engineering work on states and transitions that are important to the considered entity.It is important to think about the design of a state machine carefully. Therefore take care especially for the definition of states, where it might be challenging to find good generalisations of property values and give a corresponding useful state name.
keep it simple

Always try to reduce complexity, size and amount of state and transitions. If a state machine gets too difficult to read, check the scope of considered structural entity. Estimate whether the inputs are consistent and not too extensive (amount of data elements etc.). 

State machines tend to get complex, especially with hierarchical (composite and nested) states.
avoid anti-patterns

The following state machine diagram fragments visualise three selected anti-patterns. These kinds of state machines should be avoided since they indicate a wrong usage or a usage which is not suitable for the given behaviour to be expressed.

No actual state changes

  • Only one or two states exist but with lots of transitions which go back to the same state.
  • The state machine has no valuable state changes.
  • Recommendation: Evaluate what actually shall be expressed via the behaviour and choose another kind of behaviour definition.

Cluster of choice pseudostates

  • A cluster of choice pseudocodes is existing without any or only one simple state for the purpose of describing purely conditional outcomes (e.g. for condition checking).
  • Recommendation: Try to describe this set of conditions without state machines.

Wait points for event sequencing

  • Avoid "waiting" states (as wait points) just to catch multiple events in a row where the actually the overall state of the system does not change (especially combinations of events leading to same target state). In the example a set of states which serves only as wait points for a seqeunce of incoming messages. Only for the purpose of building up the condition of having received Message1 to Message4 in state Waiting6. States are used there ina  superflouous manner just to describe that there has to be waited for several events in a specified order to achieve a conditions (e.g. next state) to continue.
  • Recommendation: Try to express the behaviour without a state machine. Use instead another behaviour kind to express that a sequence of events in any order have to be happend before another action can be performed. This kind of synchronsation problem (wait for a set of events where all events have to occur) can be also expressed for example via textual requirements pattern using a precondition including a list of events to be occured.

The following more concrete design rules are recommended to be taken into account for state machines.

recommended design rule
general
  • State machines need initialisation, this means concretely the definition of an initial state directly going into the first atomic (simple) default state.
  • There exists at least one navigable path along transitions from the initial state to the final state, if a final state is defined.
states
  • There exists only one initial state.
  • There exists at least one simple state or at least one composite state.
  • An comparison to simple states, composite states are nesting other simple states or composite states in sequential or parallel/concurrent manner. They can be used handle to complexity of hierarchical state structures.
  • Pass events and delivered data to functions.
  • The might be cases in which the state machine has to read current data object values of the exchange items immediatetly after it left the initial state and is on the transition to the first simple or composite state. This can be achieved by using guard conditions only without an event using a choice state evaluating different outgoing transitions with corresponding guard conditions.
transitions
  • There exists at least one transition outgoing from each state (except for the final state).
  • There exists at least one transition incoming to each state (except for the initial state).

Types

Below is a list of state machine types that a system engineer / architect could model.

Lifecycle

In context of a lifecycle a state machine describes the through its states the constraints or situations an entity can go through.

Subsystem lifecycle

The main behaviour of a subsystem can be described through a definition of its lifecycle. This is achieved through definition of operational states (sometimes also called operational modes) which model the stages of the lifecycle. Since the subsystems are defined on physical level there will be technical constraints taken into account of how it shall be realised (e.g. through hardware or software). Dependent on that most probably there will be the need to define states like "idle", "initialising", and "operating" and the transitions between them. Note that the definition of the states and the lifecycle provides a view on the subsystem's main behaviour from an outside and more abstract perspective, which means the subsystem might not be aware itself of its current state (technically speaking). An example is a state like "Off" which cannot be known by the subsystem itself because it is off (e.g. for a piece of hardware which has no power and is not able to operate at all). In addition, this global bird's eye perpective of the lifecycle emphasises and supports understanding how the subsystem should basically work.

Note about concrete usage

It is currently not finally clarified whether a subsystem lifecycle shall be defined at all for all situations. When it comes to generate a requirements specification for a particular subsystem, such a state machine clearly describes then internal workings and white-box behaviour of it. This can be left to the supplier for the purpose of not constraining the solution (e.g. the product based on the requirement specification). More reasonable is then to describe the functionality of the subsystem through black-box behaviour like scenarios or textual requirements. In that sense a subsystem lifecycle state machine can be seen already as an implementation of functional requirements which represent the subsystem's behaviour visible from the outside.

However it can be beneficial to create such a state machine but only for internal purposes like increase understanding of the subsystem, content-wise evaluation and engineering as well as simulation. Regarding the relationship between the system model and the simulation environment it is also not clarfied yet in details where state machines are maintained (e.g. in the model, simulation or both).


The following state machine diagram shows an example of a possible lifecycle for a fictional simple subsystem. Main concepts visualised here are the reaction to external events (e.g. via the subsystem's interfaces) through state changes as well as reactions to internal events caused by for example finished functions.