FSM Tool 1.1 :: FSM Tool User Guide :: About FSM and the FSM Tool

OpenCloud’s FSM Tool is a lightweight service-creation tool designed to simplify service creation for the Rhino SLEE.

It powers the design, specification, implementation, testing, and documentation of JAIN SLEE Service Building Blocks (SBBs). From the developer’s perspective, the tool ensures that the specification and implementation artifacts remain completely accurate and synchronized throughout the development and maintenance life cycle of each component.

The following overview describes:

What is an FSM? — the abstract concept behind the FSM tool, linking states, transitions, and actions
What is an FSM Tool FSM? — how the FSM concept is applied to the processes involved in software engineering
What’s in an FSM Tool FSM specification? — how FSM Tool FSM-based specification can be used to automate creating executables
How does an FSM Tool FSM work? — a flowchart and explanation of how an FSM Tool FSM works
How the OpenCloud FSM Tool implements a FSM — how OpenCloud’s FSM Tool implements an FSM for the Rhino SLEE.

What is an FSM?

A finite state machine (FSM) is a behavioural model that consists of:

a set of states
a set of transitions between those states
actions in response to events or transitions.

Example: opening and closing a door

The Wikipedia FSM entry gives the following example of an elevator door opening and closing:

Finite State Machine

Finite State Machine
	The states are `Opened` and `Closed`. The transitions are `close_door` and `open_door`. The actions are `open door` and `close door`.

The states are Opened and Closed.
The transitions are close_door and open_door.
The actions are open door and close door.

Moore and Mealy FSMs

FSMs are classified as Moore or Mealy machines. Moore machines use only entry actions, and their output depends only on states. Mealy machines use only input actions, and their output depends on input and states. The illustration at left is an example of a Moore FSM. The same Wikipedia article (referenced at left) gives a related example of a Mealy machine:

Mealy Machine
	While Moore machines are often simpler, Mealy machines often have fewer states.

Mealy Machine

While Moore machines are often simpler, Mealy machines often have fewer states.

What is an FSM Tool FSM?

An FSM Tool finite state machine (FSM) is an FSM that implements only the behavioural aspects of a JSLEE component.

Moore meets Mealy

An FSM Tool FSM is also a hybrid state machine model, in that it incorporates features of both Moore and Mealy FSMs. FSM Tool FSMs use three types of actions:

input (like a Mealy machine)
entry (like a Moore machine)
exit (an additional feature, useful for application requirements such as canceling timers).

FSM Tool FSM and communications development

OpenCloud has proven FSM Tool FSM’s effectiveness for large communications systems development. Our software developers have found it to be a flexible and easy-to-use model, with a well-defined language. FSM Tool FSM bridges the gap between the design/requirements/specification and implementation, like this:

Developers write an FSM Tool FSM specification that fully describes the behaviour of a software component.
They directly extend the specified behavioural model, adding implementations of the actions defined in the spec.
The FSM Tool FSM then automatically creates a software executable.

Inputs and actions

FSM Tool FSM inputs and actions define the interface between the behavioural model and the implementation:

Inputs are flags — they can be either 'set' or 'unset'.
Actions are unparameterized names or references (which are later mapped to specific Java method names in the implementation).

Using inputs and actions, the FSM Tool FSM provides a clean separation between the specification of behaviour and its implementation. This means that software and design evolve together, always in sync.

Endpoints

FSM Tool FSMs can communicate with each other through endpoints. These are named hubs through which an FSM can send or receive inputs. An input sent from an FSM on one of its endpoints, turns into an input received on one of the endpoints of the target FSM.

What’s in an FSM Tool FSM specification?

An FSM Tool FSM Specification consists of the following elements:

Element Description Explanation

Element	Description	Explanation
States	application states	A finite number of states, each representing a point the application has reached in its execution, and possible future execution steps.
Transitions	conditional expressions of inputs which result in a transition from one state to another	A change from one state to another, plus a guard condition, whereby the transition only happens if the condition is true.
Input actions	actions executed as a function of the current state and inputs	References to logic in the implementation, executed when the FSM is in a particular state, receives a particular input, and a condition evaluates to true.
Exit actions	actions executed on transitioning away from a state	A list of named references to logic in the implementation, executed in the source state at the beginning of a transition.
Entry actions	actions executed on transitioning to a state	A list of named references to logic in the implementation, executed when reaching the sink state at the end of a transition. (Actions executed on transition
Action dictionary	names of actions to be executed	A declared set of actions used in the FSM states' input, exit, and entry actions.
Endpoints	hubs for communication between FSMs	A declared name which can be used when referring to an input, thus indicating that the input is expected to be received through the endpoint from another FSM. Additionally, each endpoint can have an associated SLEE activity context or parent SBB local reference.
Input dictionary	flags raised to indicate the arrival of an event or other condition	A declared set of inputs used in conditional expressions of input actions or transitions. Additionally, inputs can have an associated data object.
Conditions	Boolean algebraic conditional expression	Constructed using AND and OR operators on inputs. In FSM Tool, there is currently no concept of a NOT operator for conditional expressions. A NOT can be simulated by creating and setting a diametrical input for the input you want to negate. For example, to negate `received\_msg`, construct input `not\_received\_msg`

States

application states

A finite number of states, each representing a point the application has reached in its execution, and possible future execution steps.

Transitions

conditional expressions of inputs which result in a transition from one state to another

A change from one state to another, plus a guard condition, whereby the transition only happens if the condition is true.

Input actions

actions executed as a function of the current state and inputs

References to logic in the implementation, executed when the FSM is in a particular state, receives a particular input, and a condition evaluates to true.

Exit actions

actions executed on transitioning away from a state

A list of named references to logic in the implementation, executed in the source state at the beginning of a transition.

Entry actions

actions executed on transitioning to a state

A list of named references to logic in the implementation, executed when reaching the sink state at the end of a transition. (Actions executed on transition

Action dictionary

names of actions to be executed

A declared set of actions used in the FSM states' input, exit, and entry actions.

Endpoints

hubs for communication between FSMs

A declared name which can be used when referring to an input, thus indicating that the input is expected to be received through the endpoint from another FSM. Additionally, each endpoint can have an associated SLEE activity context or parent SBB local reference.

Input dictionary

flags raised to indicate the arrival of an event or other condition

A declared set of inputs used in conditional expressions of input actions or transitions. Additionally, inputs can have an associated data object.

Conditions

Boolean algebraic conditional expression

Constructed using AND and OR operators on inputs.

In FSM Tool, there is currently no concept of a NOT operator for conditional expressions. A NOT can be simulated by creating and setting a diametrical input for the input you want to negate.

For example, to negate received\_msg, construct input not\_received\_msg

How does an FSM Tool FSM work?

The FSM Tool FSM execution model works like this:

Upon execution the FSM checks if it is already being executed by another caller. The FSM returns if the FSM is already executing. Any scheduled inputs will be handled by the current execution of the FSM.
The FSM checks if there are any input changes to the Input Register pending in the scheduler or if a transition has been performed if there was a previous cycle. If there are no new inputs in the scheduled view or transitions, the execution is terminated and the FSM logic awaits a new invocation of the execute() method.
The FSM evaluates possible input actions conditions for the current state and executes the input actions where the condition evaluates to true.
The FSM evaluates any possible transitions.
If there are no transitions possible, the FSM returns to the scheduler/transition checking.
Otherwise, the FSM selects the first transition for which the condition evaluates to true.
It executes exit actions for the source state.
The current state is changed to the transition’s sink state.
The FSM executes entry actions for the sink state.
The FSM then returns to the scheduler/transition checking stage.

During execution, the FSM uses an Input Register to store the currently set inputs (and their associated data objects). The FSM execution algorithm uses two "views" of the Input Register:

The execution view does not change during an FSM execution cycle (from the point "Changes scheduled in Input Register or transitioned?" until the FSM execution returns to this point or fails).
The scheduler view can change either before or during an execution cycle. If the FSM execution code detects a change to the scheduled view, it will perform another execution cycle by applying the scheduled changes and executing the FSM again.

An FSM cycle will only ever perform a single execution cycle before returning to check for changes to the scheduled view of the input register or if their was a transition.

How the OpenCloud FSM Tool implements a FSM

With OpenCloud’s FSM Tool, developers no longer need to hand code and maintain a complex hierarchy of state machines in Java. The tool formally defines a service’s state machines, in a domain-specific language — and automatically implements state machine behaviour — ready for use in Rhino.

Transient and durable inputs

The FSM Tool implements an FSM using transient and durable inputs:

The tool automatically unsets a transient input at the end of an execution cycle.
The tool does not automatically unset durable inputs.

Cutting out the interpreter

Traditional implementations of FSMs store the FSM specification in a table structure, and then execute it by using an FSM interpreter. By contrast, the FSM Tool generates Java code from the FSM specification — and compiles it directly. This approach reduces the overhead when compared with an the interpreter approach.

Using FSM Tool, generated code can be as efficient as handwritten.

Support for Moore and Mealy machines

Developers who have experience in Moore and Mealy machines can use FSM Tool to support both machine styles by limiting the use to specific features:

Moore machines can be defined using FSM Tool by limiting the specifications to states, transitions, and entry actions.
Mealy machines can be defined using FSM Tool by limiting the specifications to states, transitions, and input actions.

Previous page Next page