VFSM Specification

The base of StateWORKS is a VFSM (virtual finite state machine) concept, which defines a finite state machine in a virtual environment. The VFSM Editor in StateWORKS Studio allows specification of several VFSM covering the control of a complex application. The result of the specification is a set of files containing the entire control knowledge. The files are in:

• proprietary format used to build an RTDB-based application
• XML format that is the documentation of the specification

VFSM Concepts

Virtual Finite State Machine

The state machine defined and specified in StateWORKS Studio is defined in a virtual environment. Therefore, its name is virtual finite state machine. The terms virtual finite state machine, finite state machine, and simply state machine are used interchangeably and always mean the same thing: a virtual finite state machine.

The basic features of the finite state machine used are:

• The finite state machine model used is a combination of Mealy and Moore features. It allows three Action types (several Actions can be performed in one run):
  • Input Action performed in the current state if a corresponding condition is true.
  • Entry Action performed when entering a state.
  • Exit Action performed when leaving a state.
• The execution model is event-driven, i.e. an event triggers the execution of Input Actions, state transitions, and consequently Exit and Entry Actions.
• Events trigger execution, but the actual activities are determined by state transition conditions and Input Action conditions; these conditions are Boolean expressions.

Its execution model is described in the following flowchart:

If you intend to test the virtual finite state machine using SWLab and eventually implement it using the RTDB library with the VFSM Executor, you must follow the execution rules defined by this model while specifying the state machine.

The essential feature of this model is that it is an event-driven system, where an event means a change of the Virtual Input. If an event occurs:

• The Input Actions whose Input Action conditions are fulfilled are carried out.
• The Exit Actions are performed if any Transition Condition is fulfilled.
• The state is changed if at least one Transition Condition is fulfilled.
• The Entry Actions in the new state are carried out.
• The Transition Conditions in the new state are checked, and the sequence Exit Actions → New State → Entry Actions repeats until no transitions are due.

When designing a specification, you must take into account all consequences of this execution model, and in particular:

• An event is a change of the Virtual Input and not a change of object data. In addition, providing the same data value does not generate an event; an event is produced only by a data change.
• A single event can trigger a series of several state transitions. All Entry Actions in entered states (intermediate and final) are performed, but only Input Actions due in the starting state are carried out; Input Actions in intermediate states are ignored.
• The first state transition that is due is performed; therefore, the sequence of checking determines the priority (defined by the sequence in the state transition table).
• All Input Actions that are due in the current state are carried out, but their execution sequence is unpredictable. Therefore, no assumptions should be made about their order; a required sequence of Actions can only be achieved by arranging a sequence of states.
• The same rule applies to Entry and Exit Actions. If several of them are carried out in a given state, their execution sequence is unpredictable.

This basic execution model has been expanded by a break mechanism described in the following flow chart:

The execution path can be broken if the break query is true; that is, after the transition to the new state, execution ceases and the executor returns to the wait for VI change point. By specifying the state machine, we may force the break by using the break state.

Virtual Environment

The Virtual Environment is created by (Virtual) Input Names, (Virtual) Output Names, and State Names.

The virtual finite state machine is specified in the Virtual Environment, i.e. only names from the Virtual Environment can be used during specification. The VFSM Editor supports the designer during that specification.

Virtual Input

Virtual Input is a list of all VFSM Input Names used in a VFSM specification.

Input and Output Objects

A virtual finite state machine is specified in a world of objects. The objects create the specification environment. An object is also a kind of state machine with well-defined behavior. In general, an object is controlled by a command and is at any time in a well-defined state.

Note that the terms Input and Output are relative to the state machine that owns the objects; these objects exhibit their state as Control Values and accept commands as Actions. Therefore, the Control Value is an Input (of the state machine) and the Action is an Output (of the state machine). Some objects realize interfaces to the controlled application; such objects accept or generate real values that we call Raw Data. These objects perform the conversion between the real data and the Control Value, or between the Action and the real data.

Objects may function as Input or Output objects. The objects that realize the interface to the controlled application are either Input or Output objects. The objects that are used internally for processing control information can possess both the Input and Output features.

Below are examples of objects illustrating the concept.

Input Object

                ┌────┐
   Raw Data ───►│ DI ├──► Control Value
(real input)    └────┘

Output Object

                ┌────┐
     Action ───►│ DO ├──► Raw Data
                └────┘   (real output)

Input/Output Object

                ┌────┐
     Action ───►│ TI ├──► Control Value
                └────┘

Control Value and Action

A control system operates only on discrete signals to cause it to change state. A VFSM Executor processes Input Names and produces Output Names.

The Input Names invented during VFSM specification are derived from input values that are Control Values of I/O objects. In fact, all Control Values are numbers. To make these numbers more comprehensible, the Control Values of all I/O objects except XDA, OFUN, and CMD are hidden under appropriate descriptive names. For instance, the Control Values of a timer (TI Object) are: RESET, STOP, RUN, OVER, OVERSTOP. Only input objects have Control Values. Any Control Value may be used as a true or Complement Value.

The Output Names invented during VFSM specification are derived from output values that represent Actions of I/O objects. In fact, all Actions are numbers. To make these numbers more comprehensible, the Actions of all I/O objects except XDA and OFUN are hidden under appropriate descriptive names. For instance, the Actions of a timer (TI Object) are: Reset, Stop, Start, ResetStart. Only output objects have Actions.

Objects may be:

• Input (VFSM, DI, NI, DAT, PAR)
• Output (AL, DO, NO, TAB)
• Input/Output (CMD, CNT, TI, ECNT, SWIP, STR, XDA¹, UDC, OFUN)

I/O Object	Control Value	Action
VFSM	States of a slave VFSM	-
CMD	Unsigned integer > 0	Commands of a slave VFSM
AL	-	Coming, Going, Staying
TI	RESET, STOP, RUN, OVER, OVERSTOP	Reset, Stop, Start, ResetStart
CNT	RESET, STOP, RUN, OVER, OVERSTOP	Reset, Stop, Start, ResetStart, Inc, Dec
ECNT	RESET, STOP, RUN, OVER, OVERSTOP	Reset, Stop, Start, ResetStart, Inc, Dec
DI	LOW, HIGH, UNKNOWN	-
DO	-	Low, High
NI	INIT, DEF, CHANGED2	-
NO	-3	Off, On, Set
SWIP	OFF, LOW, IN, HIGH, UNDEF	Off, On
STR	OFF, INIT, MATCH, NOMATCH, DEF, ERROR	Off, On, Set
XDA	Unsigned integer	Unsigned integer
DAT	INIT, DEF, CHANGED	-
PAR	INIT, UNDEF, DEF, CHANGED	-
UDC	INIT, DEF, CHANGED4	Clear, Up, Down
TAB	-	[Unsigned integer5]
OFUN	Unsigned integer	Unsigned integer

Note

The table shows only Control Values and Actions used by the VFSM specification. Some objects have additional Control Values or Actions that are used internally in RTDB and are described in the Reference for the RTDB Class Library.

Raw Data

We specify the behavior of application control in StateWORKS Studio. This specification is done in a virtual environment determined by Input Names, Output Names, and State Names. The Input Names are created on Control Values, and the Output Names on Actions. Eventually, some objects must reflect the output signals: real inputs and outputs. These real input and output signals are called Raw Data.

The concept of Raw Data makes sense only for objects that represent real signals coming from and delivered to the controlled application. For other objects, whose inputs and outputs are used to control internal resources such as timers, serve supervision purposes, or provide interfaces, the concept of Raw Data is irrelevant.

Typical input signals are stored in DI and NI objects, but CMD, XDA, PAR, and DAT are also used to store data coming from the application.

Typical output signals are generated by DO and NO objects, although XDA is also used for that purpose.

Raw Data does not play any role in behavior specification. It is mentioned here only to present the complete input/output channels involved in the processing of control data. The concept of Raw Data is a topic of I/O Handler implementation and Monitors (see SWQuickPro).

Specifying VFSM

The VFSM specification is completely independent of the RTDB-based or any other implementation. It may simply be a virtual presentation of a control system. On the other hand, if it is to be the basis of a real implementation, a designer should define and use objects that correspond to real signals in the controlled application.

The VFSM specification requires the following steps:

• definition of I/O Objects
• definition of Input Names
• definition of Output Names
• definition of State Names
• creation of an ST (state transition) diagram
• specification of state details (transition conditions, Input Actions and their conditions, Entry Actions, Exit Actions) in ST (state transition) tables

The basis of these definitions are Names, which can be changed, deleted, and added at any time in the I/O Objects list and the Input / Output / State Name lists. The changes are automatically propagated to all tables and diagrams where they are used.

I/O Objects

The I/O object Types define inputs (Control Values) and outputs (Actions). The Control Values and Actions are object-specific inputs (actually states) and outputs, in contrast to virtual Input and Output Names that are used to specify the behavior of the finite state machine. The Control Values may represent some values of real signals (for instance, digital inputs) or states of some objects (for instance, timers or switchpoints). Similarly, Actions may represent some values of real signals to be set (for instance, digital outputs) or commands to objects (for instance, timers or switchpoints).

The I/O object Types can be grouped into the following categories:

Category	I/O Object
Virtual finite state machine	VFSM
Command	CMD
Alarm	AL
Internal counting devices	timer TI counter CNT event counter ECNT up-down counter UDC
Digital signals	external binary input DI external binary output DO
Supervision	switchpoint SWIP string STR
Integer data	input/output number XDA
Formatted data	data DAT parameter PAR external input number NI external output number NO
Output table	TAB
User-defined output function	OFUN

The Control Values of I/O objects are used to define (Virtual) Input Names. The Actions of I/O objects are used to define (Virtual) Output Names. The Input and Output Names plus State Names are the only names that can be used in the specification table. Some I/O objects are pure inputs (e.g. digital input DI), some I/O objects are pure outputs (e.g. digital output DO), and some I/O objects are both inputs and outputs (e.g. timer TI).

VFSM Object

A VFSM Object represents a state machine. Its properties are determined by specifying the application and consist of a list of all objects owned by the state machine, beginning with MyCmd.

The VFSM Object can be an Input Object for another state machine (Master). The state machine is then a Slave, and its state is the Control Value in the Master state machine:

State Machine	Description
Slave1_StateName1	The name of the first state of Slave 1
Slave1_StateName2	The name of the second state of Slave 1
…	…
Slave1_StateNameN	The name of the last state of Slave 1
Slave2_StateName1	The name of the first state of Slave 2
Slave2_StateName2	The name of the second state of Slave 2
…	…
Slave2_StateNameK	The name of the last state of Slave 2
etc.	…

The VFSM Object can be an Output Object for another state machine (Slave). The state machine is then a Master and sends commands to its Slaves. These commands are Master Actions:

Command	Description
Slave1_Cmd1	The name of the first command of Slave 1
Slave1_Cmd2	The name of the second command of Slave 1
…	…
Slave1_CmdI	The name of the last command of Slave 1
Slave2_Cmd1	The name of the first command of Slave 2
Slave2_Cmd2	The name of the second command of Slave 2
…	…
Slave2_CmdJ	The name of the last command of Slave 2
etc.	…

Note

While the term “Description” indicates optional data, which is true for most objects, this is not the case for the VFSM object — it’s a required field.

CMD Object

A CMD object has two faces: either it is an Input/Output Object (CMD-IN) or an Output Object (CMD-OUT). This specific feature stems from its use as an interface element between two state machines, storing numbers representing commands. It has one property, Type, determined by specifying the application.

Each state machine owns a CMD object with a default name MyCmd. MyCmd is used to affect state machine behavior. In this role, we denote it as a CMD-IN (see Input Object), emphasizing it as a source of a Control Value. Actually, at this moment it is an Input/Output Object, as it also has an Action with a single Clear function.

            ┌────────┐
 Action ───►│ CMD-IN ├──► Control Value
(Clear)     └────────┘    (1,2,3 ... n)

The CMD object, used as a CMD-IN, accepts only one command (Action):

Action	Description
Clear	Sets the command value to 0, which is treated as “no command” (therefore, it is impossible to define a command with the value 0)

The CMD object, used as a CMD-IN, has the following Control Values (any integer number):

Control Value	Description
1	The command that will get a meaningful name
2	Another command
…	…
n	Last command

There are no restrictions on the sequence or the values of the integers except that they must be larger than 0. For instance: {5,6,9,99} will do.

The same object, when used in another (Master) state machine, is used to send a command to the owner (Slave) state machine. In this role, we denote it as a CMD-OUT (see Output Object), emphasizing the fact that it accepts Actions. Of course, a Master can send only commands defined by a Slave state machine. That means that a CMD object must first be defined by its owner (Slave) before it can be used by a Master.

            ┌─────────┐
 Action ───►│ CMD-OUT │
(Cmd Names) └─────────┘

The CMD object used as a CMD-OUT can define any Action (containing any command defined in the Slave):

Action	Description
Cmd Name 1	A name of the first command
Cmd Name 2	A name of the second command
…	…
Cmd Name n	A name of the last command

Normally, a state machine has only one CMD-IN object, but it is not forbidden to have more CMD-IN objects in a state machine. The names for the additional CMD-IN objects are stored in separate H- and IOD-files that get the names:

• StateMachineNameCommandName.h
• StateMachineNameCommandName.iod

Therefore, the name StateMachineNameCommandName must be used as a Type property of the CMD object when specifying the application.

AL Object

Alarm AL is a message. The message has Text and Category properties defined by specifying the application. In addition, it gets a timestamp.

Alarm is an Output Object and accepts the following Actions:

Action	Description
Coming	Signaling an occurrence of a removable failure in the controlled system
Going	Signaling that the failure in the system has been removed
Staying	Signaling an occurrence of a failure that cannot be removed

TI Object

Timer TI is a counting device that is triggered by an internal clock signal; in other words, the timer counts clock signals. It may count min, sec, and 100 msec intervals. On reaching a defined Const value, the timer generates a timeout signal that can be used as a control input. The Const value is a property of the TI object defined by specifying the application.

As the timer is an Input/Output Object, it is used to define input names as well as output names.

On its output, the timer accepts the following Actions:

Action	Description
Reset	Resets the timer; it is then prepared to start counting from 0
Stop	Stops the timer while counting
Start	Continues counting when it was stopped, or starts counting from 0 if it was reset
ResetStart	Starts counting from 0

As an input device, the timer may be in any one of the following states defining its Control Value:

State	Description
RESET	The timer has been reset and waits to be started
STOP	The timer has been stopped; upon receiving a Start command, it will continue counting
RUN	The timer counts the clock signal
OVER	The timer has reached the defined value (timeout has occurred) and continues counting
OVERSTOP	The timer has been stopped while counting after timeout

CNT Object

CNT Object is a counter triggered (counting) by output commands: Increment and Decrement.

In addition, it has all features of a TI Object. Its Const value is a property of the CNT object defined by specifying the application.

As the counter is an Input/Output Object, the CNT Object type is used to define input names as well as output names.

The counter accepts the following Actions:

Action	Description
Reset	Resets the counter; it is then prepared to start counting from 0
Stop	Stops the counter while counting
Start	Continues counting when it was stopped, or starts counting from 0 if it was reset
ResetStart	Starts counting from 0
Inc	Increments (+1) the counter
Dec	Decrements (-1) the counter

As an Input Object, the counter may be in any one of the following states defining its Control Value:

State	Description
RESET	The counter has been reset and waits to be started
STOP	The counter has been stopped; upon receiving a Start command, it will continue counting
RUN	The counter reacts to Actions by incrementing/decrementing
OVER	The counter has reached the expiration value (timeout has occurred) and continues counting
OVERSTOP	The counter has been stopped while counting after reaching the expiration value

ECNT Object

ECNT Object is a counter triggered by external events; for instance, it counts changes of a digital input. The Const value, Input, and its Up Value to be counted are properties defined by specifying the application.

As the event counter is an Input/Output Object, the ECNT Object type is used to define input names as well as output names.

ECNT Object has all features of a CNT Object, i.e. it accepts the Actions: Reset, Start, Stop, ResetStart, Inc, and Dec.

The event counter may be in one of the states defining its Control Values: RESET, STOP, RUN, OVER, and OVERSTOP.

DI Object

DI is a digital input. It is the basic object for storing a digital (boolean) input value, i.e. a 2-valued signal, for instance a switch: open/closed, or a voltage: high/low.

DI Object is a data type that contains the property Invert determined by specifying the application.

The DI object is an Input Object and it may be in one of the following states defining its Control Value:

State	Description
LOW	The input equals 0 (false)
HIGH	The input equals 1 (true)
UNKNOWN	The input value is not known (represented by 2)

Due to the Invert property, the Control Value of the DI Object is not necessarily equal to the Raw Data supplied by the I/O Handler. The UNKNOWN value should be generated if the I/O Handler is cut off from the external device and cannot deliver the actual value of the input signal.

DO Object

DO Object is a digital output. It supplies a digital (boolean) output value, i.e. a 2-valued signal, for instance to a switch: open/closed, or by setting a voltage: high/low.

DO Object is a data type that contains the property Invert determined by specifying the application.

The DO object is an Output Object and it accepts the following Actions:

Action	Description
Low	Sets the content to the value 0 (false)
High	Sets the content to the value 1 (true)

Due to the Invert property, the Raw Data supplied to the I/O Handler is not necessarily equal to the Action. If Inverted is set to true, the Raw Data will be an inversion of the Action.

NI Object

NI Object is an input for numbers. For instance, an analog input appears to a control system as a number (normally the output from an A-D converter). The number itself is of no use for the control logic of a system. Therefore, as a rule, NI Objects are not used in the VFSM Editor. The data (number) of the NI objects is determined by specifying the application with the following properties: Format, Unit, Scale Mode, Scale Factor, and Threshold.

Anyway, as an input device, the NI object may be in the same states (UNDEF, DEF, CHANGED) as a DAT object. Although the states represent the Control Value, they are not used by a VFSM specification. Instead, its data values (input numbers) can be translated into Control Values by use of switchpoints. The links between NI Objects and SWIP Objects are made by specifying the application.

NO Object

NO Object is an Output Object. For instance, an analog output of a control system is a number (typically the input to a D-A converter). The actual output number is a value of another object that is the source of output data. The link between the NO Object and the data source object (Out Data) is made by specifying the application, where other object properties are also set, such as: Format, Unit, Scale Mode, Scale Factor, and Offset.

There are three Actions defined for the NO Objects:

Action	Description
Off	Disables the output
On	Enables the output
Set	Sets the output

Actually, the NO object is a switch passing values of other objects to the output; these objects can be of type: DAT, PAR, NI, UDC, and TAB. Preferably, the PAR and TAB objects are used as sources of the output data.

When the output is disabled, it has the value 0. When the output is enabled, its value is the source object value, i.e. if the source value changes, the NO output changes too. When the output is set, it is set to the value of the actual source value only once, at the moment the output Action has been performed.

Note

The NO object also has states (Control Values): INIT, OFF, CHANGED, and SET, but they are of no use as Control Values in a VFSM specification.

SWIP Object

The SWIP (switchpoint) Object is a supervision object applied to numerical data as a pair of limit values. It is an Input/Output Object used to convert analog input values into discrete control signals. The limit values (Limit Low and Limit High) as well as the supervised Object (Input) are determined by specifying the application.

The SWIP Object accepts the following Actions:

Action	Description
Off	Deactivates the supervision function
On	Activates the supervision function

As an Input Object, the SWIP may be in one of the following states defining its Control Values:

State	Description
OFF	The supervision is deactivated.
LOW	The value of the supervised data is below the low limit.
IN	The value of the supervised data is within range, i.e. between the low and high limits.
HIGH	The value of the supervised data is above the high limit.
UNDEF	The supervised object is in the UNDEF state.

The supervision with a SWIP Object can be applied to a true numerical (analog) input object NI as well as to other numerical objects such as: DAT, PAR, and UDC.

STR Object

STR (string) Object is a supervision object (parser) applied to formatted data (DAT, PAR that have the string format) using regular expressions. It is an Input/Output Object used to convert string object values into discrete control signals. A side effect of the analysis is that substrings are stored as formatted data (DAT, PAR, and NI, which may have any format); the conversion to the object type is done automatically. The regular expressions are determined by specifying the application, where you define all properties of the STR Object: Input, Regular Expression, and List of Substrings.

The parser accepts the following Actions:

Action	Description
Off	Disables the string analysis
On	Enables the string analysis
Set	Acknowledges that the result has been used (consumed)

As an Input Object, the parser may be in one of the following states defining its Control Values:

State	Description
OFF	The analysis is disabled.
INIT	The analysis is enabled.
MATCH	The regular expression matches the string.
NOMATCH	The regular expression does not match the string.
DEF	The analysis is enabled (after acknowledgement).
ERROR	The regular expression is invalid.

Example

• Analyzed string (Input): **20
• Regular expression: (\*+)([0-9]+)
• Extracted two strings: ** and 20

Result:

• The first object in the list of substrings stores: ** (if the format is string)
• The second object in the list of substrings stores: 20 (string or number, depending on the format).

XDA Object

XDA object has two faces: either it is an Input Object or an Output Object.

Caution

It must not be used as an Input/Output Object in the same state machine.

It has one property, Size, determined by specifying the application.

The XDA object used as an Output Object can define any Action:

Action	Description
1	To do something
2	To do something else
…	…
n	To do the last action

The XDA object used as an Input Object can be in many states (contain any integer number), defining several Control Values:

State	Description
1	The control value that will get a meaningful name
2	Another control value
…	…
n	Last control value

The source of the Control Value must be either another state machine or an I/O Handler. In the first case, it would function similarly to a CMD Object but less comfortably (no explicit link supporting that interface with names). Use as an interface between a state machine and an I/O Handler is recommended.

DAT Object

DAT Object is a data type that contains the following properties: Format and Unit, determined by specifying the application. It is the basic object for storing data of any type.

The DAT Object state can be translated into Control Values by use of switchpoints. The links between DAT Objects and SWIP Objects are made by specifying the application.

The DAT object is an Input Object and it may be in one of the following states defining its Control Value:

State	Description
UNDEF	The initial state after start-up
DEF	The state was used by another object (for instance SWIP)
CHANGED	The state of the object was changed

PAR Object

PAR Object is a data type that contains the following properties: Category, Format, Unit, Initial Value, Low Limit Value, and High Limit Value, determined by specifying the application.

Although the PAR Object is typically used to define values for other objects, for instance a timer constant or switchpoint limits, you can also define Input Names on its values.

The PAR object is an Input Object and it may be in one of the following states defining its Control Value:

State	Description
INIT	The initial state after start-up for an EP parameter
UNDEF	The initial state after start-up for a PP parameter
DEF	The state was used by another object (for instance SWIP)
CHANGED	The state of the object was changed

UDC Object

UDC Object is an up-down counter that counts inputs (Control Values) of any input object. For instance, it may count values of a digital input or a certain state of a state machine. The details of counting (incrementing value Up Input and its Up Value, decrementing value Down Input and its Down Value, clearing value Clear Input and its Clear Value) are properties determined by specifying the application.

Formally, the up-down counter is an Input/Output Object, i.e. it may be used to define input names as well as output names.

On its output, the counter accepts the following Actions:

Action	Description
Clear	Resets the counter; it is then prepared to start counting from 0
Up	Increments the counter; the value is defined in the object properties
Down	Decrements the counter; the value is defined in the object properties

As an input device, the counter may be in any one of the following states that define its Control Values:

State	Description
INIT	The initial state after start-up
DEF	The state was used by another object (for instance SWIP)
CHANGED	The state of the counter was changed

Theoretically, we could use Control Values (states DEF, CHANGED, INIT) of a UDC Object to define Input Names, but normally there is no demand for that. We would rather put a switchpoint on its control values to detect LOW-IN-HIGH ranges.

TAB Object

TAB Object is a table used for multiplexing other data objects such as: DAT, PAR, and NI to an output signal. The output signal is then used as a data source by another object such as NO or TI.

TAB Object is a data type that requires specification of the demultiplexer inputs and the output. This is done in the property Table Rows, determined by specifying the application.

It is an Output Object whose Actions are numbers (unsigned integers) used as indexes in the table.

OFUN Object

OFUN Object stores a link to a user-written Output (C/C++) function. It is an Input/Output Object.

OFUN Object is characterized by two properties: Function Name and Unit Name, determined by specifying the application.

The Actions are numbers (unsigned integers) that are used as parameters of the Output Function.

The Output Function returns a value (unsigned integer), which is the Control Value of the OFUN Object. You can define Input Names on this Control Value.

Names

State Name

States of a virtual finite state machine are numbered, beginning with 1. To make them more understandable, the states are given names.

By specification, State Names are used to define Next States in the ST table. The State Names used can be:

• written by hand, or
• copied from the State Names tab, which displays all States

Only State Names may be used in a VFSM specification. Thus, if you make an error by writing a name by hand, the editor will force you (the Status Bar displays an error message (“Unknown name”), and the cursor cannot leave the field) either to correct or delete the name. Using the State Name tab guarantees that only correct names are copied.

A state machine has at least one state. This default state, with the name Init, is created when the state machine is created. This state can be renamed but not deleted.

_B_ at the beginning of the name defines a break state, which forces the VFSM Executor to break the execution path (only an event can cause a transition).

Input Name

(Virtual) Input Names are names invented by the designer to specify the conditions for state transitions and for Input Actions of a VFSM. Input Names are defined on object Control Values. Input Names represent possible states of objects and not the real, physical inputs.

A list of all Input Names is called a Virtual Input.

By specification, Input Names are used to formulate Transition Conditions and Input Action Conditions in the ST table. The Input Names used can be:

• written by hand, or
• copied from the Input Names tab, which displays the Virtual Input

Only Input Names may be used in a VFSM specification. Thus, if you make an error by writing a name by hand, the editor will force you (the Status Bar displays an error message (“Unknown name”), and the cursor cannot leave the field) either to correct or delete the name. Using the Input Names tab guarantees that only correct names are copied.

Output Name

(Virtual) Output Names are names invented by the designer to specify Actions carried out by a VFSM when entering a state (Entry Action), when leaving a state (Exit Action), or when the Virtual Input changes (Input Action). Output Names define Actions to be carried out and not the real, physical outputs.

An Action can be considered a kind of internal command that tells the object what to do.

By specification, Output Names can be:

• written by hand, or
• copied from the Output Names tab, which displays all Actions

Only Output Names may be used in a VFSM specification. Thus, if you make an error by writing a name by hand, the editor will force you (the Status Bar displays an error message, Unknown name, and the cursor cannot leave the field) either to correct or delete the name. Using the Output Names tab guarantees that only correct names are copied.

Command Name

Each state machine owns a CMD object with a default name MyCmd. The Control Values of that object are integers larger than 0. By defining Input Names on these numbers, we give them Command Names identifying their actual meaning (for instance: MyCmd_Start, MyCmd_Stop, etc.). The names of MyCmd are then defined on Build as an enumeration in the h-file and as text in the iod-file (section C).

Expressions and Logic

Transition Condition and Input Action Condition

A condition is a Boolean expression containing Input Names. When building the condition, you can use the operators AND (&) and OR (|). You may also use parentheses.

A condition with parentheses may be expanded to its full (disjunctive) form; this operation is irreversible.

The negation operator is not available. Instead, you may use a Complement Value.

Transition Expression

For some operations (insert, append, delete), the two fields in a row — Next State and Transition Condition — are treated as a unit. This pair of fields is called a Transition Expression.

Input Action Expression

For some operations (insert, append, delete), the two fields in a row — Input Action Condition and Input Action — are treated as a unit. This pair of fields is called an Input Action Expression.

Expand Expression

Transition conditions and input action conditions are switching (Boolean) expressions that can be written in an ST table in a simplified form using brackets. During Build, these expressions are converted into full expressions using only AND and OR operators. If you want to see the final form used during Build, you can convert the conditions into their full form using the Expand Expression command.

Note

Once converted, full expressions cannot be reconverted to the simplified form.

Control Value

A Control Value is a data property that can be used for control purposes. Control Values are used to define Input Names, which are used in the ST table in transition expressions and input action expressions. Expressions are displayed on the ST diagram (in an abbreviated form if they are too long). When the cursor is positioned over the expression for longer than one second, a tooltip displays the full expression.

Action

An Action defines an output, i.e. “what is to be done” by the state machine. Depending on the conditions and the moment they are performed, we have:

• Entry Action
• Exit Action
• Input Action

Actions are specified in the ST table as Output Names and shown on the ST diagram, if they exist, by the letters E:, X:, and I:. When the cursor is positioned over the letter for longer than one second, a tooltip displays the action.

Complement Value

Any Control Value may be used as a true or complement value. The complement value means any of the other Control Values and is denoted by a sign ~ in front of the value. For instance, a complement value ~RUN for a TI object means any of the values: RESET, STOP, OVER, OVERSTOP.

Building VFSM Specification

The VFSM specification results in the following files:

File	Description
VfsmName.h	C header file containing declarations of Input Names, Output Names, State Names, and Cmd Names. It is used when programming the I/O Handler and Output Functions.
VfsmName.iod	Information about Input Names, Output Names, State Names, and Cmd Names in text form. On start-up, it is read by an RTDB-based application and used to build the RTDB.
VfsmName.str	Information about state transition tables in text form. On start-up, it is read by an RTDB-based application and used to perform the control.

These files are accompanied by an XML file:

File	Description
VfsmName.xml	The entire specification information: name definitions, state transition diagram, and state transition table content. Primarily, it is used as documentation of the VFSM specification.

All these files can be generated at any time during specification, with errors being displayed in the Configuration Error Message window.

Each VFSM has its own set of files.

Footnotes

1. In a given state machine, the XDA object may be used either as an Input Object or as an Output Object, but not as an Input/Output Object. ↩

2. Control Values for NI objects are generally not used. Instead, the SWIP object is used to generate Control Values for these objects. From this point of view, the NI object is neither an Input nor an Output object; it is just a container for storing a data value. ↩

3. The NO object also has Control Values: INIT, OFF, CHANGED, and SET, but they are of no use as Control Values in a VFSM specification. ↩

4. Control Values for UDC objects are generally not used. Instead, the SWIP object is used to generate Control Values for these objects. The UDC is de facto an Output Object. ↩

5. The integer is a table index. ↩