Editing Virtual finite-state machine

{{inline citations|date=October 2024}}
A '''virtual finite-state machine''' ('''VFSM''') is a [[finite-state machine]] (FSM) defined in a [[#Virtual environment|virtual environment]]. The VFSM concept provides a software [[formal specification|specification]] method to describe the behaviour of a control system using assigned names of [[Input/output|input control properties and output actions]].

The VFSM method introduces an [[execution model]] and facilitates the idea of an executable specification. This technology is mainly used in complex [[machine control]], [[instrumentation (computer programming)|instrumentation]], and [[telecommunication]] applications.

== Why ==
Implementing a state machine necessitates the generation of logical conditions (state transition conditions and action conditions). In the hardware environment, where state machines found their original use, this is trivial: all signals are [[Boolean data type|Boolean]]. In contrast state machines specified and implemented in software require logical conditions that are per se [[Many-valued_logic|multivalued]]:
* Temperature could be Low, OK, High
* Commands may have several values: Init, Start, Stop, Break, Continue
* In a [[hierarchical control system]] the subordinate state machines can have many states that are used as conditions of the superior state machine

In addition input signals can be unknown due to errors or malfunctions, meaning even digital input signals (considered as classical Boolean values) are in fact 3 values: Low, High, Unknown.

A Positive Logical Algebra solves this problem via [[virtualization]], by creating a Virtual Environment which allows specification of state machines for software using multivalued variables.

== Control properties ==
A [[state variable]] in the VFSM environment may have one or more values which are relevant for the [[Control (optimal control theory)|Control]]—in such a case it is an input variable. Those values are the control properties of this variable. Control properties are not necessarily specific data values but are rather certain [[state (computer science)|states]] of the variable. For instance, a digital variable could provide three control properties: TRUE, FALSE and UNKNOWN according to its possible boolean values. A numerical (analog) input variable has control properties such as: LOW, HIGH, OK, BAD, UNKNOWN according to its range of desired values. A timer can have its OVER state (time-out occurred) as its most significant control value; other values could be STOPPED or RUNNING.

== Actions ==
Other [[state variable]]s in the VFSM environment may be activated by actions—in such a case it is an output variable. For instance, a digital output has two actions: True and False. A numerical (analog) output variable has an action: Set. A timer which is both: an input and output variable can be  triggered by actions like: Start, Stop or Reset.

== Virtual environment ==
[[Image:Virtual finite state machine executor in the virtual environment.gif|thumbnail|Figure 1: VFSM in the Virtual Environment]]
The virtual environment characterises the [[runtime environment]] in which a [[virtual machine]] operates. It is defined by three sets of names:
*'''input names''' represent the control properties of all available variables
*'''output names''' represent the available actions on the variables
*'''state names''', as defined for each of the states of the FSM.
The input names build virtual conditions to perform [[state transition]]s or input actions. The virtual conditions are built using the '''[[Boolean algebra|positive logic algebra]]'''. The output names trigger actions; [[UML_state_machine#Entry_and_exit_actions|entry actions, exit actions]], input actions or transition actions.

== Positive logic algebra ==
The rules to build a virtual condition are as follows:

=== Input names and virtual input ===
A state of an input is described by Input Names which create a [[Set (abstract data type)|set]]:
* input A: <code>Anames = {''A1'', ''A2'', ''A3''}</code>
* input B: <code>Bnames = {''B1'', ''B2''}</code>
* input C: <code>Cnames = {''C1'', ''C2'', ''C3'', ''C4'', ''C5''}</code>
etc.

Virtual input <code>VI</code> is a set of [[mutually exclusive]] elements of input names. A <code>VI</code> always contains the element <code>''always''</code>:
 VI = {''always''}
 VI = {''always'', ''A1''}
 VI = {''always'', ''A1'', ''B2'', ''C4''}

=== Logical operations on input names ===
'''<code>&</code>''' (AND) operation is a set of input names:

''A1'' & ''B3'' & ''C2'' => <code>{''A1'', ''B3'', ''C2''}</code>


'''<code>|</code>''' (OR) operation is a table of sets of input names:

''A1'' | ''B3'' | ''C2'' => <math>\begin{bmatrix}
\{ & A1 & \} \\
\{ & B3 & \} \\
\{ & C2 & \} \\
\end{bmatrix}</math>

'''<code>~</code>''' (Complement) is a [[complement (set theory)|complement]] of a set of input names:

~''A2'' = <code>{''A1'', ''A3''}</code>

=== Logical expression ===
A logical expression is an OR-table of AND-sets (a [[disjunctive normal form]]):

''A1'' & ''B3'' | ''A1'' & ''B2'' & ''C4'' | ''C2''  => <math>\begin{bmatrix}
\{ & A1 & B3 & \} \\
\{ & A1 & B2 & C4 & \} \\
\{ & C2 & \} \\
\end{bmatrix}</math>

Logical expressions are used to express any logical function.

=== Evaluation of a logical expression ===
The logical value (true, false) of a logical expression is calculated by testing whether any of the AND-sets in the OR-table is a [[subset]] of <code>VI</code>.

=== Output names and virtual output ===
A state of an output is described by Output Names which create a set:
* output X: <code>Xnames = {''X1'', ''X2''}</code>
* output Y: <code>Ynames = {''Y1'', ''Y2'', ''Y3''}</code>
Virtual output <code>VO</code> is a set of mutually exclusive elements of output names.

=== Virtual environment===
The Virtual Name and Virtual Output completed by State Names create the Virtual Environment <code>VE</code> where the behaviour is specified.

== VFSM execution model ==
[[Image:Virtual finite state machine executor flow chart.gif|thumbnail|Figure 2: VFSM executor flow chart]]
A subset of all defined input names, which can exist only in a certain situation, is called virtual input or <code>VI</code>. For instance temperature can be either "too low", "good" or "too high". Although there are three input names defined, only one of them can exist in a real situation. This one builds the <code>VI</code>.

A subset of all defined output names, which can  exist only in a certain situation is called virtual output or <code>VO</code>. This is built by the current action(s) of the VFSM.

The behavior specification is built by a state table which describes all details of all states of the VFSM.

The VFSM executor is triggered by <code>VI</code> and the current state of the VFSM. In consideration of the behavior specification of the current state, the <code>VO</code> is set.

Figure 2 shows one possible implementation of a VFSM executor. Based on this implementation a typical behavior characteristics must be considered.

== State table ==<!-- This section is linked from [[Finite state machine]] -->
{{further|State-transition table}}
A ''state table'' defines all details of the behavior of a state of a VFSM. It consists of three columns; the first column names the state, the second lists virtual conditions built out of input names using the positive logic algebra, and the third column contains the output names:

{| class="wikitable"
|-
! State Name
! Condition(s)
! Actions(s)
|-
| rowspan=4 valign="top" | Current state || Entry action || Output name(s)
|-
| Exit action || Output name(s)
|-
| Virtual condition || Output name(s)
|-
| ... || ...
|-
| Next state name || Virtual condition || Output name(s)
|-
| Next state name || Virtual condition || Output name(s)
|-
| ... || ... || ...
|-
|}

Read the table as following: the first two lines define the entry and exit actions of the current state. The following lines which do not provide the next state represent the input actions. Finally the lines providing the next state represent the state transition conditions and transition actions. All fields are optional. A pure [[combinatorics|combinatorial]] VFSM is possible in cases only where input actions are used, but no state transitions are defined. The transition action can be replaced by the proper use of other actions.

== Tools ==
* [http://www.stateworks.com/ StateWORKS]: an implementation of the VFSM concept
* [http://www.hutonggames.com/index.html PlayMaker]: implements the VFSM concept as a method of "visual scripting" the [[Unity (game engine)|Unity game engine]]

== References ==
* Wagner, F., "The Virtual Finite State Machines: Executable Control Flow Specification", Rosa Fischer-Löw Verlag, 1994, {{ISBN|3-929465-04-3}}
* Wagner, F., "Modeling Software with Finite State Machines: A Practical Approach", Auerbach Publications, 2006, {{ISBN|0-8493-8086-3}}
* [https://stateworks.com/pdfs/software-engineering.pdf VFSM Executable Specification], CompEuro 1992 Proceedings
* [https://stateworks.com/pdfs/state-machine-misunderstandings.pdf State machine misunderstandings], IEE journal "Computing and Control Engineering", 1997
* [https://stateworks.com/pdfs/VFSM-design-implementation-paradigm.pdf The Virtual Finite State Machine Design and Implementation Paradigm], Bell Labs Technical Journal, 1997
* [https://stateworks.com/pdfs/real-time-software-design.pdf A Modern Real-Time Software Design Tool: Applying Lessons from Leo], IEE journal "Computing and Control Engineering", 2003
* [https://stateworks.com/pdfs/modeling-reliable-software.pdf Modelling and Building Reliable, Re-usable Software.], Engineering of Computer -Based Software 2003 (ECBS'03) Proceedings
* [https://stateworks.com/pdfs/software-modelling.pdf Closing the Gap Between Software Modelling and Code], Engineering of Computer -Based Software 2004 (ECBS'04) Proceedings
* [https://stateworks.com/docs/manuals/XML-VFSM-ML/], Wagner, T., "VFSMML - XML standard for VFSM", 2004

[[Category:Models of computation]]