Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.
login Register forgot password or username?

Welcome to 3SL Reference Section

State Transition Diagrams State Transition Diagram (STD)

State Transition Diagram (STD)

State Transition Diagrams (STDs) are used along with specifications to define the functional detail for a system.

Unlike data processes, control processes have a specialised role: enforcing sequencing over environmental control stimuli to the system, and the internal operation of the system. A control process is defined on an STD that represents the definition of the control process as a finite-state-machine. The number of the STD is the same as the number of the control process it defines.

The finite-state-machine enters an initial state when activated, either notionally at system startup or when the control process is activated by an enable or trigger prompt. In entering this initial state, it may perform some actions, defined below.

Once in a state, the finite-state-machine may only enter another state by making a transition to the new state. A transition is only possible when its condition is satisfied, and in moving to the new state the finite-state-machine may perform zero or more actions. Every state must be the destination of at least one transition. A transition may cause the finite-state-machine to return to the same state, i.e. the old and new states resulting from a transition may be the same.

Transition conditions consist of one or more expressions combined with any of the operators AND, OR and NOT. The transition only occurs when the condition is true, that is, when the input event flow(s) is/are present. The finite-state-machine makes transitions between states in response to some internal (to the system) or external (from the environment) event. Environmental control-related events are often modelled as input event flows to a control process, that in turn cause transitions (and consequential actions) in the control process’s STD.

A transition action can take one of three forms:

  • The activation of a named output event flow from the parent control process
  • The control of a named process that is connected to the STD’s parent control process by a prompt originating from the control process. These actions can take one of the following forms:
E transformation name - enable the named transformation
D transformation name - disable the named transformation
T transformation name - trigger the named transformation
  • The control of a named output event flow from the parent control process:
R flow name - raise the named continuous flow
L flow name - lower the named continuous flow
S flow name - signal the named discrete flow

You can put algebraic expressions in conditions and actions, e.g.:

I < 10

for a condition and


for an action.

Elements of algebraic expressions are not consistency checked, e.g. we do not look for a data definition called I or i in the above examples. The presence of < > + - * / triggers something being recognised as an algebraic expression.

Tip: Both conditions and actions are associated with transitions by the Cradle system, so the Cradle diagram requires that a transition must be selected before either of these types of object can be drawn. These are the only objects that have to be drawn in this manner.

STDs are not hierarchical. Their connectivity is:

Diagram of the connectivity of a State Transition Diagram

STDs are available in models in both in the Essential and Implementation Domains.

Logical Operators in Conditions

A condition is used on a transition to indicate that something is being acted on to move the system from one state to another.

While there should be one condition that causes this transition to take place, a number of conditions may be required, or be acted on, at the same time.

There are three logical operators that can be used in the condition to group conditions together. These are the logical operators:

  • AND
  • OR
  • NOT

These can be used to combine conditions together (AND and OR), or change the test that is made for the conditions (NOT).

In Cradle, the conditions using logical operators are still drawn as a separate condition. They are often positioned close to each other to give the appearance of a single condition using logical operators.

It is the use of logical operators in the name of the condition that distinguishes this condition from a normal condition. The positioning of the conditions relative to each other has no bearing on the way in which Cradle treats them.

Literal Expressions in Conditions and Actions

In certain cases it can be useful to use literal expressions within the condition used on a transition. For example, when testing an enumerated type for one of its values as the indication of the state which should be transitioned to. In the enumerated set, the literals do not have data definitions’ definitions, as they are alternative values for the data definition.

Assignments are made in literal expressions as follows:

output = “Blue”

The assignments must be used in an action on an STD, they cannot be used as a condition. The literal which is being assigned should be one of the components in the composition for the variable being assigned.

Tests are made in literal expressions as follows:

Output == “Blue”

This is used in the condition on a transition in an STD, not in an action. Again, the literal that is being tested for should be part of the composition of the item being tested.

When using literal expressions, the conditions and actions are drawn in the same way as for other conditions and actions, it is the names given to the conditions and actions that differentiate them.

Numbering of STDs

The numbering system for STDs is dot-decimal. STDs cannot exist in a hierarchy and so no STD symbol can be expanded into a lower-level diagram. It may, however, be the case that control processes in two DFDs in the DFD hierarchy expand into STDs whose numbers give the illusion of a hierarchy with a DFD-like numbering system. While the decomposition of control into a control hierarchy is a normal element of many systems, such hierarchical numbering of STDs will be purely coincidental and neither should, nor does, have any significance to Cradle.


An example STD is:

Screenshot of a State Transition Diagram

The symbols available in STDs are:

Symbol Name Description Definition Expansion


Comment Makes a note anywhere in the diagram. Are always surrounded by * characters. None None

Boundary Point

Boundary Point A connection point for the initial transition to enter the initial state. None None


State A state which does not need to be named, of the STD’s finite-state-machine. None None


Condition The condition which must be true for the associated transition to occur. An event flow name. One or more conditions can be associated with a transition. Keywords AND, OR and NOT can be used to convey a logical expression. The keywords are ignored during STD checks. Data definition None


Action An action performed by the finite-state-machine when making a transition between two states. Either an event flow name or to enable, disable or trigger a named transformation. Data definition (except actions that are the control of a named process) None

Initial Transition

Initial Transition The transition initially performed by the finite-state-machine when it, or the system, is activated. None None


Transition A transition between two states. None None


Picture Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. None None