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
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 practice | explanation | details |
---|---|---|
evaluate need for state machines | The 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:
Not recommended for the following problems:
|
lower number of states | Rather 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 engineering | It 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
Cluster of choice pseudostates
Wait points for event sequencing
|
The following more concrete design rules are recommended to be taken into account for state machines.
recommended design rule | |
---|---|
general |
|
states |
|
transitions |
|
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.