Users Guide
StateWORKS Studio Development Tools
User’s Guide & Training Manual
Table of Contents
- 1. Introduction
- 1.1 System specification
- 1.2 Project Manager
- 1.3 State Machine Editor
- 1.4 System Configuration
- 1.5 System test
- 1.6 StateWORKS Lab
- 1.7 StateWORKS Monitors
- 1.7.1 SWMon
- 1.7.2 SWQuickPro
- 1.7.3 StateWORKS Terminal
- 1.8 Help Files and Other Documents
- 2. Getting started
- 2.1 What is the StateWORKS Studio for?
- 2.2 Opening VFSM document
- 2.2.1 Example
OnOff
- 2.2.1 Example
- 2.3 Defining States
- 2.4 Defining the Virtual Environment
- 2.5 Defining I/O Objects
- 2.6 Defining Input Names
- 2.7 Defining Output Names
- 2.7.1
DO
(Digital Output) Output Names - 2.7.2
TI
(Timer) Output Names - 2.7.3
AL
(Alarm) Output Names
- 2.7.1
- 2.8 Filling the state transition table
- 2.8.1 Conditions as logical expressions
- 2.8.2 Complement value
- 2.8.3 Actions as outputs
- 2.9 “Always” Table
- 2.10 Saving VFSM
- 2.11 Building a VFSM
- 2.11.1 Example
OnOff
- 2.11.1 Example
- 2.12 System Configuration
- 2.13 Opening the Project Manager
- 2.14 Defining the system of state machines
- 2.15 Configuring the system
- 2.16 Specifying Object Properties
- 2.16.1 VFSM (
OnOff
) Properties - 2.16.2
CMD
(Command) Properties - 2.16.3
DI
(Digital Input) Properties - 2.16.4
DO
(Digital Output) Properties - 2.16.5
TI
(Timer) Properties - 2.16.6
AL
(Alarm) Properties
- 2.16.1 VFSM (
- 2.17 Introducing I/O Units
- 2.18 Creating the system configuration
- 2.19 Testing the system
- 2.20 Starting the StateWORKS Lab (SWLab)
- 2.21 Monitoring RTDB
- 2.21.1 Monitoring
RTDB
objects - 2.21.2 Monitoring
AL
Object - 2.21.3 Monitoring
VFSM
Object - 2.21.4 Monitoring
CMD
Object - 2.21.5 Monitoring
TI
Object - 2.21.6 Monitoring
CNT
Object - 2.21.7 Monitoring
ECNT
Object - 2.21.8 Monitoring
DI
Object - 2.21.9 Monitoring
DO
Object - 2.21.10 Monitoring
SWIP
Object - 2.21.11 Monitoring
STR
Object - 2.21.12 Monitoring
PAR
Object - 2.21.13 Monitoring
DAT
Object - 2.21.14 Monitoring
UDC
Object - 2.21.15 Monitoring
NI
Object - 2.21.16 Monitoring
NO
Object - 2.21.17 Monitoring
XDA
Object - 2.21.18 Monitoring
TAB
Object - 2.21.19 Monitoring
OFUN
Object
- 2.21.1 Monitoring
- 2.22 Tracing
- 2.23 Monitoring RTDB using SWTerm
- 2.24 Monitoring RTDB using SWQuickPro
- 3. Specifying VFSM
- 4. Managing a System of VFSMs
- 5. Specifying Units
- 6. Printing and Publishing
- 7. Linking to other Applications
- 8. Other topics
- 8.1 Using tables
- 8.1.1 Generation of analog output values
- 8.1.2 Example:
SetAo
- 8.2 Output functions
- 8.2.1 Example:
Stepper
- 8.2.1 Example:
- 8.3 Implementing combinational systems
- 8.3.1 Example
Combi
- 8.3.1 Example
- 8.4 Multi-valued objects
- 8.4.1 Input values
- 8.4.2 Output objects
- 8.4.3 In-Out objects
- 8.5 Using VFSM-Templates
- 8.5.1 What is a Template?
- 8.5.2 Example: Template
- 8.5.3 Specifying a Template
- 8.5.4 Generating a Template from a VFSM
- 8.5.5 Changing a VFSM Template
- 8.5.6 Connecting VFSM to Template
- 8.5.7 Application Notes
- 8.1 Using tables
- 9. VFSMs documentation
- 9.1
OnOff
example
- 9.1
- 10. References
1. Introduction
The StateWORKS Studio [6] is a set of programs used to develop software for complex systems, such as control systems. That part of the software which controls the behavior of the software is isolated from the numerical computation, and is treated as a set of state machines. In some cases, you could specify and test a control system without writing a single line of code.
This document is completed by tutorials [11][12][13] which teach you the details of using menu commands while working with StateWORKS Studio.
1.1 System specification
You specify the system using the StateWORKS Studio (SWStudio) which is a IDE with two powerful editors: a State Machine Editor and a Project Manager. In addition, it contains SwLab and monitors (SWMon, SWQuickPro, SWQuick, SWTerm) to test the specified system. Note that no version contains all monitors. In the time of last updating the manual SWMon and SWQuickPro become standard monitors delivered in the installation package.
1.2 Project Manager
You organize your project with the Project Manager. The project contains files that describe state machines used by your system, IO-units, VFSM-templates and system configuration. All files are managed by the Project Manager that keeps track of all changes and assures the system consistency.
1.3 State Machine Editor
A control system is built of several state machines and I/O-units. The State Machine Editor is a graphical and text editor to specify the state machine behavior. In addition, the State Machine Editor is used to specify VFSM-templates and I/O-units. The results of the specification can be built producing data files that are used by StateWORKS run-time system to perform the control task. The specification can be printed or exported to a text editor for documentation purposes. The specification is also available as XML files to be displayed in web browsers.
1.4 System Configuration
A system of state machines specified by the State Machine Studio must be adapted to the real control environment, i.e. all objects used by state machines must be determined, for instance:
- state machine inputs are linked with appropriate input signals,
- timer values are determined,
- switch-points for numerical (e.g. analog) inputs are determined, etc.
- The system is configured in the Project Manager.
1.5 System test
You test the system using the StateWORKS Lab and the StateWORKS monitors.
1.6 StateWORKS Lab
The StateWORKS Lab (SWLab) is a Window program that runs under Windows 10/11. SWLab is based on a real-time-database (RTDB) with a state machine executor. The RTDB contains all object used in the control system. The SWLab simulates a small digital and analog input/output system.
SWLab is used to learn the VFSM concept. It can be used to test state machines and not too complex systems of state machines. It contains a fully functional VFSM execution environment: its limits result from the number and type of inputs and outputs. In a TCP/IP link the StateWORKS Lab is a Server.
1.7 StateWORKS Monitors
The StateWORKS Studio has different monitors to display and change RTDB objects, especially: SWMon, SWQuickPro. In older versions you find also SWQuick and SWTerm.
1.7.1 SWMon
The StateWORKS Monitor (SWMon) is a debugging tool that cooperates with a VFSM execution environment based on TCP/IP link. Hence, it cooperates well with the StateWORKS Lab and is used to learn the VFSM concept. It gives you the true understanding of objects used in the control system. It can be used to test a system of state machines of any size.
1.7.2 SWQuickPro
The StateWORKS QuickPro (SWQuickPro) is a monitor which allows access to a single object at a time. SWQuickPro creates automatically a log file that can be used as a command file. It has a quite elaborated test features that are described in [9]. Its simpler variant SWQuick does not have the testing facilities.
1.7.3 StateWORKS Terminal
The StateWORKS Terminal (SWTerm) is a debugging tool that cooperates with a VFSM execution environment using the TCP/IP link. It is a command line program. It allows the user to log all his activity (commands and system answers) and to use the log file as a command file. Hence, it is used to automate the tests.
1.8 Help Files and Other Documents
While reading this manual, or when working with StateWORKS Studio, remember to use the StateWORKS Studio Help files, which provide a great deal of extra information and advice on various topics. Many other informative documents may be seen at the StateWORKS website, and some are listed in the references.
2. Getting started
2.1 What is the StateWORKS Studio for
The StateWORKS Studio is used to specify virtual finite state machines (VFSM). The VFSM [1][2] is a state machine that describes a pure behavior of the control system. You achieve this by using names that describe states, input conditions and Actions. All names have a virtual character that are just names. You link these names to real signals by creating I/O objects that are later used to build a system configuration by the StateWORKS Project Manager.
2.2 Opening VFSM Document
Figure 1: Choosing a file
To begin specifying a new VFSM, you start by creating a new VFSM specification through the menu option:
File → New.
In the New dialog window, select VFSM file and click OK. This will open the Base template for this VFSM dialog.
Figure 2: Creating a new VFSM
Select Generic from the options and click OK.
You will now see the state transition diagram (ST diagram) for a new VFSM, which initially contains a default state labeled Init
. When you save or build the file, you will have the option to rename the VFSM. You can begin specifying the VFSM by using the active menus and buttons provided.
Before elaborating on the VFSM specification, you will need to define various names used throughout the specification.
Additionally, the initial state transition diagram includes an Always
table, which will be discussed later.
Both the Init
state and the Always
table are essential elements of any VFSM and cannot be deleted. However, you are allowed to rename the Init
state.
Figure 3: The initial state transition (ST) diagram
2.2.1 Example: OnOff
The descriptions are supported by examples. The first example is a state machine called OnOff
:
It is a simple state machine that can serve as the foundation for many complex state machines. It includes the following basic I/O objects:
- Input Command (
CMD-IN
) - Timer (
TI
) - Alarm (
AL
) - Digital Input (
DI
) - Digital Output (
DO
)
The behavior of the state machine can be described as follows: The state machine has two stable “done” states: Off
and On
. Normally, no actions are taken while in a done state. The state machine enters a done state if the inputs signal that the controlled device has reached the required state. Upon entering the done state, no actions are carried out. Thus, the state machine does not wait for a reaction from the controlled device to a defined stimulus. In other words, a done state means that everything is operating as expected.
In most cases, each done state is paired with a busy state. In this example, the state machine has two busy states: OffBusy
and OnBusy
. Upon entering a busy state, the state machine performs some actions and expects the controlled device to respond by issuing acknowledgments.
Usually, a busy state is guarded by a timer. If the acknowledgment does not arrive within a specified time, the state machine must react to the situation. The simplest reaction is to generate an alarm.
The principles described above are represented in the example. The state machine starts in the Off
state. Upon receiving the command CmdOn
, it transitions to the OnBusy
state. When entering the OnBusy
state, the state machine switches on the device and starts a timer. If the device acknowledges its ON
state by setting the DI
input high, the state machine transitions to the On
state. If the timer expires before the acknowledgment is received, the state machine generates an alarm. Upon leaving the OnBusy
state, the state machine stops the timer, as the timeout is only relevant while in OnBusy
.
The state machine remains in the On
state. Upon receiving the command CmdOff
, it transitions to the OffBusy
state. When entering the OffBusy
state, it switches off the device. If the device acknowledges its OFF state by setting the DI
input LOW, the state machine transitions to the Off
state. The OffBusy
state is not guarded by a timer. Thus, if the DI
input does not change to LOW, the state machine remains in this state and does not signal any issues, as per this example.
Additionally, two more transitions are possible:
- From
OnBusy
toOffBusy
with the commandCmdOff
. - From
OffBusy
toOnBusy
with the commandCmdOn
.
2.3 Defining States
You are free to invent state names. Try to use names that describe the meaning of the states. For example, the name MotorOn
carries more information than State_1
.
The description of the required control usually provides suggestions for state names. These names are generally convincing and meaningful, so we typically accept them as is.
As mentioned earlier, every state machine contains an initial state, Init
. The state Init
is created automatically and cannot be removed from the State Name list, but you can rename it. It is a convention that each state machine starts in the Init
state when the system is powered on. This allows you to specify the first transition immediately to a state you consider the real starting point. You can define entry actions in this initial state to perform tasks necessary for the safe startup of the system.
The easiest way to define a new state is by double-clicking on the ST diagram. This action opens the State Name Dictionary, where you can add a new state to the list.
Figure 4: State Name Dictionary
You can manipulate the list by adding or removing states, or changing the state sequence. The state symbol (a circle) on the ST diagram contains both the state name and the sequence number from the list. The list can be expanded or modified at any time, so there’s no need to worry if you are unsure about all the states initially. You can add multiple states to the dictionary, but when you close the dictionary, only the currently selected state is created on the diagram.
Alternatively, you can open the ST diagram using the menu command:
Dictionary → State
This allows you to add new states to the list. You can then “transfer” these states to the ST diagram by double-clicking on the diagram, selecting the state from the list, and closing the dictionary with OK.
You can change the sequence of states in the list at any time. The sequence has no influence on the VFSM specification or its behavior; it is just used to organize your preferences in the documentation.
When a state is created on the ST diagram, a State Transition (ST) Table for that state automatically opens (see Figure 5).
You can fill in the state transition table immediately or at any time you deem appropriate. Typically, you may ignore the state transition table at first, as you need to define the virtual environment required for specifying transitions and actions.
Figure 5: A state transition (ST) table opens when the state is created
2.4 Defining the Virtual Environment
The Virtual Environment is an input/output space created by names invented by a designer to describe the behavior of a system. The designer is free to choose names that are needed for system specification based on their perspective.
Objects (variables) used in control systems store various values. The type of object determines what kind of value it stores:
- A digital input stores a Boolean value (
true
,false
). - An analog input stores a number (e.g., a
float
). - A parameter can store values of various types, such as
integer
,float
, orstring
. - A timer is a counter, storing a number that changes as it runs.
In addition, objects have Control Values. A Control Value is a feature of an object that is used for control purposes:
- The Control Value of a digital input corresponds to its current value (
true
,false
). - The Control Value of an analog input is a set of value ranges (e.g.,
LOW
,OK
,HIGH
). - The Control Value of a parameter is its status (e.g.,
INIT
,DEF
,CHANGED
). - The Control Value of a timer represents its state (e.g.,
RUN
,STOP
,OVER
).
In general, Control Values must be defined separately for each object type.
The virtual input and output names are the only names that can be used to specify the control system. These virtual names are mapped to real-world control signals:
- Input Names are produced based on the Control Values of real input signals.
- Output Names are converted into values for real output control signals.
The conversion between real and virtual signals happens automatically, thanks to the real-time database (RTDB) in the VFSM Execution environment. In some cases, if necessary, the conversion process may involve a custom program (e.g., a C function).
Before defining the Input and Output Names, you must decide which I/O objects will be used by the state machine.
2.5 Defining I/O Objects
The I/O Object Types identify the sources (inputs) and targets (outputs) of control signals. These are the real inputs and outputs, unlike the virtual Input and Output Names, which are used to specify the behavior of the finite state machine. The I/O Object Types are grouped into the following categories:
- Other finite state machines:
VFSM
- Command:
CMD
(CMD-IN
,CMD-OUT
) - Alarms:
AL
- Internal counting devices:
- Timer:
TI
- Counter:
CNT
- Event counter:
ECNT
- Up-down counter:
UDC
- Timer:
- External digital signals:
DI
,DO
- External numerical (analog) signals:
NI
,NO
- Output demultiplexer:
TAB
- Supervision:
- Switch-point:
SWIP
- String:
STR
- Switch-point:
- Data:
DAT
,XDA
- Parameter:
PAR
- User-defined output function:
OFUN
- Programmer’s I/O handler or output function interface:
UNIT
The I/O Objects are used to define virtual Input and Output Names. These, along with the State Names, are the only names that can be used in the specification table. Some I/O Objects are pure inputs (e.g., DI
), some are pure outputs (e.g., DO
), and some function as both inputs and outputs (e.g., TI
). CMD
Objects can be either input or output, hence they appear as CMD-IN
and CMD-OUT
in the I/O Object list.
To open the I/O Object Dictionary (see Figure 6), go to:
Dictionary → I/O Object
In the Type menu, select the object type and assign a name to the object in the Id name column. The Description column is not used for the objects in this example.
The MyCmd
object is created automatically. This object includes the commands that the state machine will “understand.” By default, every state machine has a MyCmd
object, which cannot be removed, even if it’s not actively used.
You need to choose and name four other objects: Di
, Do
, Timer
, and Alarm
. While you can invent names, it’s recommended to use simple names that describe the object type. These object names will be used to create virtual names for the VFSM specification and physical object names for system configuration. Clear and concise naming is important for both specification and documentation. The following example uses these names: MyCmd
, Timer
, Alarm
, Di
, and Do
.
Figure 6: I/O Object Dictionary
The buttons Create names and Delete unused help manage objects:
- Create names generates a sequence of objects based on their type and a sequence number starting from 0. Each click creates a new set of objects. This feature is more useful for testing than for state machine design.
2.6 Defining Input Names
(Virtual) Input Names are names invented by the designer to specify the conditions for state transitions and Input Actions of a VFSM. Only Input Names can be used for these purposes in a VFSM Specification. A list of all Input Names is called a Virtual Input.
You have the freedom to invent Input Names, though we will offer some suggestions. The editor also assists by generating proposals for Input Names.
To open the Input Name Dictionary (see Figure 7), use the following menu:
Dictionary → Input
I/O Objects have various Control Values (i.e., they can be in different states): Di
can be LOW
, HIGH
, or UNKNOWN
; Timer
can be in one of these states: RESET
, RUN
, STOP
, OVER
, OVERSTOP
, etc. For each of these Control Values, you can define an input name that describes its control meaning.
- Choose the I/O Object ID and its Input Value.
- Click the Add key, and for most object types, the editor will automatically generate a name in the Input Name field.
The editor will not propose a name for object types whose Control Value is a number (e.g., CMD
, XDA
, OFUN
). If the proposed name is suitable, click the Add key again, and the name will be inserted into the list of Input Names. The editor generates the name by combining the Object name with its Control Value. For example, if you select the object Timer
and the value OVER
, the editor will suggest the name Timer_OVER
.
Figure 7: Input Name Dictionary
You should not accept the editor’s suggestions uncritically. While names like Timer_OVER
may be acceptable, others like Di_LOW
or Di_HIGH
may not be meaningful. In this example, we chose DeviceOn
and DeviceOff
as better alternatives to the neutral Di_LOW
or Di_HIGH
.
A default name always
is automatically added to the Input Name list. It is always present in the virtual input and cannot be removed. Although it is not shown explicitly in this dialog, it will be available for use in the state transition table specification.
The button ~
is used to define complement control values. See the discussion in the subsection “Conditions as Logical Expressions” later for more details.
The dialog window includes the Create names button, which automatically generates names for all objects based on their values. This automatic generation applies to all object types except CMD_IN
, XDA
, and OFUN
, whose values are integers. The Create names button creates names for all true values when the ~
button is inactive and for all complement values when the ~
button is active.
Another button, Delete unused, removes all names that are not used in any ST table specification.
2.6.1 Initializing the Virtual Input
By setting an Init
mark, you can decide whether a name is active when the state machine starts. This is important if a name is defined on a value that is not known at system start-up or on an initial object value.
For example, after initialization, names defined as digital values—FALSE
and TRUE
—are not present in the virtual input because they are unknown. The first change of the digital input will add one of them to the virtual input. If you know the value of a digital input at start-up, you can initialize the virtual input with the corresponding Control Value. If the value is unknown, it’s better to set it to UNKNOWN
.
Consider another example with a Timer
. Suppose a state machine resets a Timer
in the Entry Action of the first state after state Init
. At this moment, the virtual input will not contain a name based on the RESET
Control Value because the object’s Control Value has not changed. The virtual input is updated only when the Control Value changes. At system start-up, the Timer
is initialized to the RESET
state, so resetting it in the Entry Action won’t alter its state. Therefore, initializing the virtual input with the name based on the RESET
Control Value is the correct solution—if you need the RESET
Control Value for the specification.
2.6.2 DI
(Digital Input) Input Names
You can define names for three DI
object Control Values: HIGH
, LOW
, and UNKNOWN
.
In this example, we define two names for the Control Values HIGH
and LOW
:
DeviceOn
forHIGH
DeviceOff
forLOW
2.6.3 TI
(Timer) Input Names
The Timer
can have the following Control Values: RESET
, STOP
, RUN
, OVER
, and OVERSTOP
. For each Control Value, you can define a name.
In this example, we use only one timer Control Value: OVER
, which means the Timer
has elapsed. So, we define the name Timer_OVER
.
2.7 Defining Output Names
(Virtual) Output Names are names created by the designer to specify Actions carried out by a VFSM when:
- Entering a state (Entry Action)
- Leaving a state (Exit Action)
- Receiving a (virtual) input name (Input Action) without a state transition occurring
You are free to invent Output Names, and the same comments made for Input Names apply to Output Names as well.
Open the Output Name Dictionary (see Figure 8):
Dictionary → Output
In this case, we did not accept the names Do_Low
and Do_High
proposed by the editor. Instead, we specified the names SwitchOff
and SwitchOn
, which better explain the intended control. For example, if we have another device that is switched off by a High
signal and switched on by a Low
signal, we can simply change the output value definition without altering the VFSM specification. Another solution would be to change the value of the real digital output. This topic will be discussed later with the Project Manager.
The VFSM specification defines the behavior of the state machine. In this stage, we want to convey that the device is either switched on or off, without specifying further details. The specific signal used (whether Low
, High
, or another type) is not yet defined and should be avoided at this point.
The dialog window includes the Create names button, which automatically generates names for all objects based on their values. Another button, Delete unused, removes all names that are not used for specification in ST tables.
Figure 8: Output Name Dictionary
The automatic generation feature applies to all object types except those with integer values (XDA
, TAB
, and OFUN
).
2.7.1 DO
(Digital Output) Output Names
You can define names for the two DO
-object values: High
and Low
.
In the example, we use both values and define two names: SwitchOn
and SwitchOff
.
2.7.2 TI
(Timer) Output Names
The following Actions can be performed with a Timer: Reset
, Stop
, Start
, and ResetStart
. You can define a name for each Action.
In the example, we activate two timer Actions: we reset it and start it at the same time, and we stop it. So, we have defined two names: Timer_ResetStart
and Timer_Stop
.
2.7.3 AL
(Alarm) Output Names
You can define Alarm names for three Alarm Values: Coming
, Going
, and Staying
.
- Use the
Coming
andGoing
values if the erroneous situation can correct itself. For example, a low temperature could increase later and reach the correct value. - Use the
Staying
value if the erroneous situation is irreversible and cannot be corrected without operator intervention.
In the example, we have defined two names: Alarm_Coming
and Alarm_Going
.
2.8 Filling the State Transition Table
Filling out the State Transition Table requires a solid understanding of the state machine execution model used by VFSM.
Figure 9: The VFSM Execution Model
The VFSM (Virtual Finite State Machine) is a finite state machine that describes the behavior of a system using a virtual environment. The VFSM execution model is a combination of both Mealy and Moore types of automata, which allows for Entry Actions, Exit Actions, and Input Actions.
In Figure 9, you can see the VFSM execution model. When specifying VFSM behavior, consider the following features:
- Entry Actions are executed only once when entering a state.
- Exit Actions are executed only once when leaving a state.
- Input Actions are executed at any time the VFSM is triggered.
- VFSM execution continues until there are no further transition conditions, meaning that one input change could result in multiple state transitions.
The state machine specification consists of transition specifications and Action specifications. Transitions can be added to the State Transition (ST) Diagram by “drawing” a transition between two states. To do this, move the cursor over the starting state, right-click, and drag the cursor to the destination state. A transition arc will appear during the movement. When you release the mouse over the destination state, the transition will be added to the diagram, and the ST table for the start state will open. The destination state is already entered in the ST table—you just need to fill in the transition conditions.
If necessary, you can delete a transition from the ST diagram by selecting it (left-click on the transition arc) and pressing the Delete key.
You can specify a transition directly by opening an ST table (double-clicking a state in the ST diagram) and entering the transition there. To update the ST diagram with the new state transition, simply return to the diagram.
In summary, the ST diagram is not just a visual representation of the state machine; it can also be used to initiate the specification of transitions and Actions. The detailed specifications, however, are defined within the ST Table.
Figure 10: Input Name List
Figure 11: Output Name List
You can fill the transition table by either writing the State, Input, and Output Names directly or by copying them from the available lists. The latter method is recommended as it allows for quicker and more efficient modifications while reducing the risk of errors. The table fields are context-sensitive. By placing the cursor in a specific field, you can open the corresponding Name list by right-clicking.
All lists—Input Name, Output Name, and State Name — are available in tab windows (Figure 10, Figure 11, Figure 12), which switch based on the cursor’s position in the ST table fields.
Figure 12: State Name List
Figure 13 illustrates one state of the OnOff
state machine as specified in StateWORKS Studio. You can find the complete specification in the OnOff
project.
Figure 13: OnOff — The ST Table of the State OnOff
2.8.1 Conditions as Logical Expressions
In this example, Input Action conditions and Transition conditions are simple single names. However, in general, you can use logical expressions that resemble Boolean logic. These expressions can include two operators: AND
(&
) and OR
(|
), but there is no NOT
operator. The VFSM (Virtual Finite State Machine) approach avoids using the NOT
operator because the names do not represent Boolean values but instead refer to multiple Control Values of a given variable. For instance, a timer may have the following Control Values: RESET
, STOP
, RUN
, OVER
, and OVERSTOP
.
Instead of a NOT
operator, you can use complement control values, which are discussed in the next subsection.
To understand this better, let’s look at the DI
object (Digital Input). In the VFSM model, it has three Control Values: FALSE
, TRUE
, and UNKNOWN
. Using these Control Values, you can define three control names, such as DeviceOff
, DeviceOn
, and DeviceStatusUnknown
. This differs from Boolean algebra, where a variable always has one of two values: true
or false
. As a result, when specifying conditions, you can use three or more names, not just one Boolean value.
When working with logical expressions, you can also use brackets to improve readability. The expression can be expanded into a standard form. For example, consider this expression:
By using the menu command:
Options → Expand Expression,
this expression will be transformed into:
In the standard form, the AND
(&
) operator has higher priority than the OR
(|
) operator.
2.8.2 Complement Value
In the specification, you can use two forms of a control value: true and complement . A complemented control value (negated) is denoted by the prefix ~
and represents any other value for that object. For example, for the DI
object (Digital Input) discussed earlier, ~TRUE
means any value other than TRUE
, such as FALSE
or UNKNOWN
.
Using complements in a specification is straightforward. In the Input Name Dictionary dialog window, there is a button labelled ~
that toggles between the true value and its complement. If the button is not activated (as in Figure 7), the values used are the true (non-complemented) values.
When the button is pressed (as in Figure 14), the caption ~
appears, indicating that the complement values are being used. By default, input names generated from complement values will have the prefix NOT_
. Of course, you can rename the default value as needed.
You can use the ~
button when adding or modifying input names. When adding (via the Add button) or modifying (via the Modify button) an input name, the prefix NOT_
will be automatically added if the value is changed to its complement. If you switch back to a true value, the prefix NOT_
will be removed.
Figure 14: Input Name Dictionary with the complement button activated
2.8.3 Actions as Outputs
The same approach used for inputs applies to outputs. Let’s take the DO
object (Digital Output), which has two Actions: Low
and High
. You can define names for these Actions, such as SwitchOff
and SwitchOn
. When the SwitchOff
Action is defined, the real digital output corresponding to the DO
object will be set to Low
. Similarly, using the SwitchOn
Action means the real digital output will be set to High
. This approach differs from traditional Boolean logic, where the output is determined by the value of a Boolean variable. In the VFSM technique, you define specific Actions for different outputs.
As mentioned earlier, an input or output name doesn’t necessarily reflect its actual value. For example, the name SwitchOff
might be defined for either the Low
or High
object value of a DO
. The name should describe the effect (i.e., what happens to the output) rather than the value that causes the effect. Additionally, the Invert
option can be applied to any input/output when specifying object properties in the project, which should be considered during the configuration.
2.9 “Always” Table
The VFSM specification may include an Always table, which defines Input Actions that are executed in every state. You manage this table (Insert, Append, Delete) in the same way as for other state tables.
Note that the Always table has no connection to the “always” input name — it is simply a similar naming convention. The Always table allows you to define state-independent Input Actions, meaning actions that occur in all states.
2.10 Saving VFSM
When saving a VFSM for the first time, you will be prompted to enter a prefix. The editor will suggest a default prefix using the first three letters of the file name, which is usually the best choice.
The prefix is used in the generated *.h
and *.io
files, ensuring that all names are uniquely prefixed within the VFSM project.
2.11 Building a VFSM
To build the VFSM, use the menu command:
File → Build
This generates the files (*.str
, *.iod
, *.h
) required by the VFSM Executor.
During the build process, the Studio will verify if the specification is correctly formatted. If errors are detected in the specification table, the build process will stop. The first error encountered will be displayed in the status bar at the bottom of the Studio window, and the cursor will be positioned at the location of the error.
You can test your VFSM using StateWORKS Lab, which acts as a simulator, allowing you to debug your control logic without the need for the actual controlled device.
Before testing, you’ll need to create a project to configure the system, particularly the I/O devices.
Figure 15: OnOff - the ST diagram
2.11.1 Example: OnOff
Once the specification for the OnOff
example is completed, the ST diagram shown in Figure 15 will be displayed. This diagram provides an overview of the system, including states and transitions. Additionally, symbols such as E:
, X:
, and I:
indicate the types of Actions defined for each state. You can hover your mouse cursor over these symbols to view detailed information about the specific Actions.
2.12 System Configuration
Figure 16 illustrates the progress made so far with the OnOff
example. We have specified the behavior of the VFSM using symbolic names from three distinct lists: Input, Output, and State. Unlike states, which are internal system variables, inputs and outputs represent descriptions of conditions and Actions related to the controlled device or system resources. Since these names do not correspond to real signals but rather to control properties of real signals, we refer to them as virtual inputs and virtual outputs.
Figure 16: The elements of the virtual specification
The Input and Output Names describe the Control Values and Actions associated with commands (MyCmd
), digital inputs (Di
), digital outputs (Do
), timers (Timer
), and alarms (Alarm
). Here’s a breakdown of these elements:
- The command (
MyCmd
) may originate from another state machine or be generated by the system, an operator, or other sources as a number. - The digital input (
Di
) comes from the controlled device. - The digital output (
Do
) is sent to the controlled device. - The timer (
Timer
) is part of the system resources, typically implemented in software. - The alarm (
Alarm
) is also part of the system, often generating notifications, such as displaying text on a screen.
The system configuration is prepared by using the StateWORKS Project Manager. For the OnOff
example you have to configure the following I/O objects:
- Timer: Set the timeout value.
- Alarm: Define the alarm text to be displayed.
- Cmd: Specify the source of the command input.
Di
(Digital Input): Configure the origin of the digital input.Do
(Digital Output): Configure the origin of the digital output.
2.13 Opening the Project Manager
To configure the system, you need to create a new project. Use the following menu command:
File → New → Project
Figure 17: The Project window
The Project window has two panes:
- The Object Type pane displays a list of all object types available in the project. This is the same object type list that was used when creating the I/O Dictionary. The object types are organized in a directory structure. When you open the Project Manager, only the highest directory level is shown, displaying the basic groups like Input, Output, and others. To view a specific object type, click on the corresponding directory name.
- The Object Name pane starts off empty. As you configure the system, this pane will populate with the objects you add.
2.14 Defining the System of State Machines
To define the state machine types that will be used in the system configuration, you must add each state machine to the project. In this example, you only have one state machine: OnOff
. Add it to the project using the following command:
Project → Edit → Add
Once a state machine is added to the project, it appears at the end of the Object Type list, just before the Unit. In this sense, a state machine is treated like any other object in the system.
For configuring the system, you will need to include the following object types: CMD
(MyCmd
), TI
(Timer), AL
(Alarm), DI
(Di), DO
(Do), and the state machine VFSM (OnOff
).
2.15 Configuring the System
To create an object of a given type, use the New button in the Project Window (see Figure 18). The order of creating objects is not important — you can add or delete objects, or change their properties, at any time.
Figure 18: The Project and VFSM Properties windows
Start by creating the VFSM object for OnOff
. In the Object Name window, you will see the default name OnOff0
. Open the OnOff Properties window by clicking Properties or by double-clicking the object name. The OnOff Properties window contains a list of all I/O objects required by the VFSM OnOff
. Initially, the list starts with the Name and Description fields, and all other I/O objects used by the VFSM are shown in the left column. The right column will remain empty until the other objects are defined.
Since we don’t want to use the default name OnOff0
, change the name to OnOff
as there is only one state machine in the project, making a different name unnecessary.
Now, proceed to create the objects belonging to this state machine. Use the New button to create objects by selecting the desired type from the Object Type pane.
Click on the AllType directory in the Object Type window to display all objects defined so far in the Object Name window. Alternatively, you can filter objects by selecting a specific group or object type.
2.16 Specifying Object Properties
To specify the properties of any I/O object, select the object from the Object Name list. This will open the corresponding Properties window for that object.
2.16.1 VFSM (OnOff
) Properties
The properties for the OnOff
state machine are straightforward—they are the names of the I/O objects associated with the state machine. For the OnOff
example, we will use the following I/O names (you can choose any names you prefer):
OnOff_MyCmd
OnOff_Timer
OnOff_Alarm
OnOff_Di
OnOff_Do
2.16.2 CMD
(Command) Properties
When creating a CMD
object, a default name will appear in the Object Name window, which you can change if needed. By clicking on the CMD
object OnOff_MyCmd
in the Object Name window, you will open the CMD Properties window.
The only property you need to specify is the Type of the command (you can ignore the Description fields for now). Enter the name of the VFSM, which is OnOff
. The Project Manager will pass this information to the data file used by the VFSM Executor, which will use the symbolic command names defined (indirectly) during the VFSM specification.
Figure 19: CMD Properties window
If you don’t specify the command type, the VFSM Executor will not recognize the symbolic names and will react only to numerical command values from the Input Name Dictionary.
2.16.3 DI
(Digital Input) Properties
For DI
objects, there is an additional property: Invert. If the Invert checkbox is not selected, the digital value is passed as it is. Selecting the Invert checkbox will invert the digital input value.
Figure 20: DI Properties window
2.16.4 DO
(Digital Output) Properties
DO
objects are similar to DI
objects. If you don’t check the Invert property, the value will be passed as it is.
2.16.5 TI
(Timer) Properties
When specifying a TI
object, the default name will be Ti:01
. You can change this to something more descriptive, like OnOff_Timer
. Open the TI Properties window, and specify the timer’s features, such as the Const (constant) timeout value (for example, set it to 5) and the Clock (set it to sec
). If you want the Const to be a parameter, uncheck the By value
box. This can be tried later.
Figure 21: TI Properties window
2.16.6 AL
(Alarm) Properties
Create an AL
object and name it OnOff_Alarm
. In the AL Properties window, specify the alarm Text. You can ignore the Category for now and set it to a default value like 2 (this will be discussed later).
2.17 Introducing I/O Units
Certain objects like Cmd, Alarm, and Timer are internal system resources created and managed by the software.
Digital inputs and outputs are signals that belong to the controlled device, i.e. they are external, physical signals. Usually, they would be organized in groups that are managed by I/O drivers. StateWORKS software operates on the assumption that I/O signals received from and sent to controlled devices exist within units. For simulation purposes, the StateWORKS Lab software recognizes four predefined standard unit types: DI16
, DO16
, NI4
, and NO4
, which must be included in any project tested by the StateWORKS Lab.
In this example, you will add DI16
and DO16
unit types to the project:
Project → Edit → Add
Once the units are added to the project, create a digital input unit named DI16_Unit1
and a digital output unit named DO16_Unit3
.
Unit | Properties |
---|---|
DI16_Unit1 | Physical Addr = 1 Di0 = OnOff_Di |
DO16_Unit3 | Physical Addr = 3 Do0 = OnOff_Do |
2.18 Creating the System Configuration
Once all I/O units are defined and their properties specified, you can create the system configuration by selecting:
Project → Build configuration
Alternatively, you can create all system files (VFSM and configuration files) by choosing:
Project → Build All
The results of the build process will be displayed in the Configuration Error Messages window. These messages provide detailed information about the configuration’s completeness. There are three types of messages:
- Warnings: These might indicate, for example, that a digital input in the
DI
unit hasn’t been used in the system. - Other Notifications: These messages inform you that some properties are set to their default values. You must decide whether you accept these defaults intentionally or whether you forgot to set specific values.
- Significant Errors: These messages highlight critical issues, such as missing properties.
By clicking on a message, you can jump directly to the Properties window containing the missing or problematic property. Regardless of the messages, the system always generates the ProjectName.swd
file. We believe it’s important to allow testing with an incomplete system configuration, even if the results may be unpredictable at times.
The ProjectName.swd
file can be used by the StateWORKS Lab to test the system.
2.19 Testing the System
Once the system is built, it can be tested using SWStudio. SWStudio allows you to launch SWLab, a specialized RTDB (Real-Time DataBase) application that reads the system specifications and simulates the behavior of the system based on input triggers.
To monitor the system’s performance, you can use one of several tools:
- SWMon: A GUI-based program that displays all objects and allows you to modify their properties. It provides access to all attributes of a single object at a time.
- SWQuickPro, SWQuick, or SWTerm: Additional monitoring tools. SWTerm is a console client with a command-line interface, offering similar functionality as SWMon.
All these programs can be accessed via the Tools menu in SWStudio. Help documentation for these programs is available under the Help menu.
2.20 Starting the StateWORKS Lab (SWLab)
Figure 22: StateWORKS Lab
To start the StateWORKS Lab (SWLab), navigate to:
Tools → SWLab
Once SWLab is running, you can initiate the RTDB system by opening its SWD
file:
File → Open
If the system is already running and you want to restart it, use:
File → Restart
SWLab simulates the following I/O units:
- 8 digital inputs (represented by switches that you can toggle using the mouse)
- 8 digital outputs (represented by LEDs)
- 4 analog inputs (numerical)
- 4 analog outputs (numerical)
To manipulate the digital inputs, simply click on the switches to change their positions. The digital outputs will display results by activating the corresponding LEDs.
For analog inputs and outputs, the values are displayed on analog gauges. You can modify the analog inputs by either:
- Entering a numerical value (clicking on the number opens an entry window), or
- Using the arrow buttons to increase or decrease the value. The value can be adjusted:
- By 1 unit with a normal click
- By 8 units when holding the SHIFT key
- By 64 units when holding the CTRL key
This interactive interface allows you to fully test and simulate the system’s behavior, ensuring everything works as expected.
2.21 Monitoring RTDB
The StateWORKS Monitor (SWMon) is used to debug the VFSM system of state machines by monitoring the RTDB
(Real-Time DataBase).
To start SWMon, navigate to:
Tools → SWMon
Upon launching SWMon, a dialog window appears where you can enter the TCP/IP address and port.
Figure 23: Connecting to SWLab
By default, accept localhost
as the address and 59091
as the port number. Ignore the password field when working with SWLab, as it doesn’t require a password.
Once connected, you can display RTDB
objects by selecting:
Select → VFSM
This will open a window showing the list of state machines running in Lab.
Figure 24: Selecting the list of state machines
Alternatively, you can display RTDB
objects listed in a unit by selecting:
Select → UNIT
This displays a list of I/O units in Lab.
Figure 25: Selecting the list of I/O units
The most convenient way to display RTDB
objects is by using:
Select → User
This allows you to display all objects in the RTDB
and define a list of objects to monitor.
You can save this list to disk using Save, or load a previously saved list using Get.
Figure 26: Selecting the user-defined object list
Monitor Display
The monitor display (Figure 32) is divided into two parts by a horizontal line. The upper part contains two lines of controls:
- First line: Displays object type information based on your selection (VFSM, UNIT, or User).
- Second line: Handles commands.
If you’ve selected VFSM, the first line displays the VFSM name, type, and Virtual Input (VIN) conditions as numbers.
Figure 27: Displaying VFSM virtual input and state
If you’ve selected UNIT, this part displays the UNIT name and type.
Figure 28: Displaying UNIT name
If you’ve selected User, the display shows the name of the user-defined object list (or remains blank if no list is stored).
Figure 29: Displaying the name of user-defined object list
Selecting Commands
You can also select command objects through:
Select → CMD
This opens a list of state machine commands.
Figure 30: Selecting the list of state machine commands
When a command is selected, it appears in the second line of controls at the top of the window.
Figure 31: Displaying the command name and values
The second line shows details about the selected command, including the command’s name. The Received field displays the actual command received from the master state machine.
Sending Commands
You can send a command to the selected command object by typing the command name or selecting it from the pull-down menu, then clicking Send. Commands can be sent as either real commands or service commands. You can toggle between these modes using the trigger button -
to the left of the command buttons. When the command object is in service mode, its name is displayed in bold.
Sending a real command (with service mode off) overwrites the command value received from the master. Switching back to service mode restores the original command.
For commands with values between 1 and 4, the command buttons display the corresponding names. Clicking on a button sends the associated command.
2.21.1 Monitoring RTDB
Objects
The lower part of the Monitor display, which can be resized, shows all objects associated with the selected VFSM, UNIT, or user-defined object list. This section displays object values and properties, and both can be temporarily altered for debugging purposes.
Figure 32: The StateWORKS SWMon monitor
Some objects can be tested using a service mode. Service mode allows the object value to be overwritten by an entry in the Monitor.
Figure 33: The object service mode
When service mode is disabled, as shown in the figure above, the object’s value is determined by its real input value. When enabled, the real input value is disconnected, and the object’s value is determined by the service value entered through the Monitor.
The Monitor displays objects related to the selected VFSM, UNIT, or user-defined list. In the case of VFSM, an object will appear in the Monitor if it is defined in the I/O Object Dictionary. Objects must be included in the I/O Object Dictionary if they are needed as conditions (inputs) or actions (outputs) for defining the VFSM behavior.
However, not all objects need to be in the I/O Object Dictionary. For instance, Switchpoints (SWIP
), Limits, Timers (TI
), or Constants can be parameters but are rarely used as conditions, so there’s no need to add these to the I/O Object Dictionary. Nevertheless, you can display these non-dictionary objects by defining your custom list through Select → User.
VFSM objects are grouped by type, with each group starting with the object type name. The following object types can be monitored: ALARM
, VFSM
, CMD
, TIMER
, CNT
, ECNT
, DI
, DO
, SWIP
, STR
, PAR
, DAT
, UDC
, NI
, NO
, XDA
, TAB
, OFUN
. Each object is represented by a single line in the Monitor, containing elements that vary depending on the object type.
The basic structure of each object line is as follows:
Type | Name | Trace (check-box) | Control Value | Value (Numerical) | Property / Service Mode & Value (may vary) | Others |
---|
- Type: Appears only once per group of objects.
- Name: Typically shown as a button that allows interaction with the object, depending on its type.
- Trace: Each object has a trace check-box that enables tracing when selected.
2.21.2 Monitoring AL
Object
The ALARM (AL
) object line contains a button and several fields:
Type | Name | Trace | Control Value | Alarm Text | Alarm Category | Alarm Time |
---|---|---|---|---|---|---|
ALARM | Text on button | Check-box | COMING GOING STAYING ACK COM_GO | String including IDS_ and %references | Integer (1,2,4 preferred) | dd-mmm-yy hh:mm:ss |
The button carries the ALARM Name and is used to acknowledge the alarm.
There are two alarm sections in the Monitor:
- The first alarm line appears at the top of the VFSM object list, displaying all alarms generated by the VFSM under the general label
AL
. This line shows the most recent unacknowledged alarm. If multiple alarms are pending, they are queued (first-in-last-out). Acknowledging an alarm removes it from the display, allowing the next alarm in the queue to appear. By repeating acknowledgements, you can clear the entire alarm queue. - At the end of the VFSM object list, all VFSM alarms are displayed with individual lines showing their current Control Value (status):
COMING
,GOING
,STAYING
,COM_GO
, orACK
.
2.21.3 Monitoring VFSM
Object
The VFSM
object line contains three radio buttons and the following fields:
Type | Name | Trace | Run mode (radio) | Hold mode (radio) | Step (radio) | Input Action / Next state | Control Value | Service Value |
---|---|---|---|---|---|---|---|---|
VFSM | Text | Check-box | Selected if active | Selected if active | Selected if active | Input Action/Next state | State Name | State Value |
- Control Value: Displays the name of the current
VFSM
state along with the sequence of recent state transitions. The most recent state appears on the left. You can scroll through the history of state changes, although the scroll buffer is limited to 1000 characters. - Service Value: Allows you to overwrite the
VFSM
state. By entering a State Value (found in the*.IOD
file of the state machine), theVFSM
Master sees this new state as active. The true current state is still displayed in the Control Value field, but it is temporarily replaced by the value in the Service Value field.
To exit Service Mode, enter a dash (-
) in the Service Value field. Service Mode also cancels automatically when you switch to monitoring another state machine.
The radio buttons are used to control the Run, Hold, and Step modes of the VFSM Executor:
- Run mode: The first radio button sets the state machine to run continuously.
- Hold mode: The second radio button pauses the state machine.
- Step: The third radio button executes one state transition or Input Action, provided its condition is fulfilled.
- Input Action / Next State: This field shows an
A
(Action) or a dash (-
) if the state machine is paused in Hold mode. The field also displays the name of the next state if one is due. If an Input Action is due, theA
appears; otherwise, it shows a dash. If no next state is expected, the field will shownone
.
2.21.4 Monitoring CMD
Object
The CMD
object contains the following fields:
Type | Name | Trace | Control Value |
---|---|---|---|
CMD | Text | Check-box | CMD Name or Value |
The CMD
object line displays the received command Name (or Value if the commands are not named).
The CMD
object Name becomes bold if the CMD
object is in the Service mode.
2.21.5 Monitoring TI
Object
The TIMER (TI
) object line contains a button and the following fields:
Type | Name | Trace | Control Value | Value | Const (timeout) | Clock |
---|---|---|---|---|---|---|
TIMER | Text on a button | Check-box | RESET STOP RUN OVER OVERSTOP | Elapsed time | Integer | min sec 100ms |
The button carries the Timer Name.
You can overwrite the Const value. The Name button is used to restore the original Const value.
2.21.6 Monitoring CNT
Object
The CNT
(Counter) object line contains a button and the following fields:
Type | Name | Trace | Control Value | Value | Const |
---|---|---|---|---|---|
CNT | Text on a button | Check-box | RESET STOP RUN OVER OVERSTOP | Actual count | Integer |
The button carries the Counter Name.
You can overwrite the Const value. The Name button is used to restore the original Const value.
2.21.7 Monitoring ECNT
Object
The ECNT
(Event Counter) object line contains a button and the following fields:
Type | Name | Trace | Control Value | Value | Const |
---|---|---|---|---|---|
ECNT | Text on a button | Check-box | RESET STOP RUN OVER OVERSTOP | Actual count | Integer |
The button carries the Counter Name.
You can overwrite the Const value. The Name button is used to restore the original Const value.
2.21.8 Monitoring DI
Object
The Digital input object line has the following fields:
Type | Name | Trace | Control Value | Service mode | Service value |
---|---|---|---|---|---|
DI | Text | Check-box | Boolean: 0 1 | Auto: - selected: disabled - not selected: enabled | 1/0: - selected: 1 - not selected: 0 |
The Value is always the Control Value.
If you do not select the Auto
check-box the displayed input value remains the Input value though the system input is equal to the service value. In other words, the Control Value always displays the real value.
2.21.9 Monitoring DO
Object
The Digital input object line contains the following fields:
Type | Name | Trace | Control Value | Service mode | Service value |
---|---|---|---|---|---|
DO | Text | Check-box | Boolean: 0 1 | Auto: - selected: disabled - not selected: enabled | 1/0: - selected: 1 - not selected: 0 |
The Action is always the real value.
If you do not select the Auto
check-box the output value equals the service value. In other words, the Action always displays the value applied to the (real) output.
2.21.10 Monitoring SWIP
Object
The SWIP
(Switch-point) object line contains a button and the following fields:
Type | Name | Trace | Control Value | Low limit | High limit |
---|---|---|---|---|---|
STR | Text on a button | Check-box | OFF LOW IN HIGH UNDEF | Number: integer or real | Number: integer or real |
You can overwrite the limit values.
The Value displays the value of the input controlled by the switch-point.
The Name button is used to restore the original limit values.
2.21.11 Monitoring STR
Object
The STR
(String) object line contains a button and the following fields:
Type | Name | Trace | Control Value | Value | REG |
---|---|---|---|---|---|
SWIP | Text on a button | Check-box | OFF ON MATCH NOMATCH DEF ERROR | Input string | String (Regular expression) |
You can overwrite the REG string.
The Value displays the string of the input controlled by the string object.
The Name button is used to restore the original regular expression string.
The On/Off button enable/disables the supervision: clicking on it you may force the Control Value to OFF.
2.21.12 Monitoring PAR
Object
The PAR
(Parameter) object line contains the following fields:
Type | Name | Trace | Control Value | Value | Low limit/ High limit | Unit | Format |
---|---|---|---|---|---|---|---|
PAR | Text | Check-box | UNDEF DEF CHANGED INIT | Value | Value | String | bool char short float etc. |
The value type of Value, Low limit / High limit and Initial value is defined by Format. You can overwrite the parameter value. There is no way to automatically restore the original values if you forget them. There are two parameter types: PP and EP.
The EP parameter name is bold. The EP parameters are saved in a file .RTDB.par
. Hence, after the restart the last parameters shown (set) in Monitor will be loaded. Therefore, the EP parameter line gets at the end an additional property column Initial value to show the value defined in the configuration.
The PP parameters are not saved. Hence, restarting the system will load the parameters set from the configuration file (PAR
properties values in the Project Manager).
2.21.13 Monitoring DAT
Object
The DAT
(Data) object line contains the following fields:
Type | Name | Trace | Control Value | Value | Unit |
---|---|---|---|---|---|
DATA | Text | Check-box | DEF CHANGED UNDEF | Actual value | String |
2.21.14 Monitoring UDC
Object
The UDC
(Up-Down Counter) object line contains the following fields:
Type | Name | Trace | Control Value | Value | Unit |
---|---|---|---|---|---|
UDC | Text | Check-box | UNDEF DEF CHANGED INIT | Actual count | String |
2.21.15 Monitoring NI
Object
The NI
(numerical input) object line contains the following fields:
Type | Name | Trace | Control Value | Value | Unit |
---|---|---|---|---|---|
NI | Text | Check-box | DEF CHANGED UNDEF | Actual numerical value | String |
The type of the (Numerical) Value is defined in the configuration.
2.21.16 Monitoring NO
Object
The NO
(numerical output) object line contains the following fields:
Type | Name | Trace | Control Value | Value | Unit | OnOff |
---|---|---|---|---|---|---|
NO | Text | Check-box | OFF CHANGED INIT SET | Actual numerical value | String | Button |
The type of the (Numerical) Value is defined in the configuration.
The button OnOff
is a kind of Service Mode for numerical output. If OnOff
is Off the NO
output is determined by the VFSM. A click on the button OnOff
triggers the object state to ON
: in this state the NO
output is at any time linked to the parameter that determines the NO
value (corresponds to command On
).
2.21.17 Monitoring XDA
Object
The XDA
object line contains the following fields:
Type | Name | Trace | Control Value / Action |
---|---|---|---|
XDA | Text | Check-box | Integer |
You can change temporarily the object Control Value / Action. After restart the original value defined in the configuration will be restored.
2.21.18 Monitoring TAB
Object
The TAB
object has similar fields as the XDA
object, the last filed being an Action field only.
The TAB
(demultiplexer output) displays the Index value. You can change the Index value. After resetting the system the Index has always the value 0.
2.21.19 Monitoring OFUN
Object
The OFUN
object has similar fields as the XDA
object.
The OFUN
(Output function) object line displays the Action (function parameter) or the Control Value (function return value).
2.22 Tracing
If the Trace check-box of an object is marked all changes of object Control Value or Action are written into a file Trace.txt
. The Trace file is open when the Monitor is started.
The Trace file can be closed at any time using the icon:
The Trace file can be opened at any time using the icon:
Tracing can be reset using the icon:
2.23 Monitoring RTDB
using SWTerm
The StateWORKS Terminal (SWTerm) is used to debug the VFSM system of state machines, effectively to monitor the RTDB
. Due to not having a GUI the SWTerm program is of course less convenient than SWMon but it has some additional features which make its use interesting.
The basic functionality of SWTerm is equivalent to that of SWMon, i.e. you can get property values of all RTDB
objects and you can set the object values. You may also notify SWterm as a client of the RTDB
which awaits events (Advise function) but the usage is not very useful, especially if we have many often-changing events – in such a case we prefer of course the usage of SWMon.
The interesting features of SWTerm are: logging and executing of command files. SWTerm logs all typed commands and answers. The command file can be either written by hand or it can be just the log file. The conversion of a log file into a command file requires only the change of the file extension from .log
to .com
.
The SWTerm program can be started with parameters which determine the usage of log and command files:
-l
→ Without this parameter the log file has a nameSWTerm.log
.-r
→ Commands and responses will be logged, otherwise only commands.-c
→ Take commands from the fileCmdFileName
, otherwise from the console.
You start SWTerm by:
Tools → SWTerm
It opens the command line window where you type in the commands. The reactions (answers) to the command are also displayed in the command line window.
You find a full description of the SWTerm in [4].
2.24 Monitoring RTDB
using SWQuickPro
You start SWQuickPro by:
Tools → SWQuickPro
It opens the dialog based application. While connecting to SWLab ignore the password entry.
The StateWORKS SWQuick monitor is used to display all attributes of a single object at a time. If connected all RTDB
objects are displayed in the window on the left.
On selecting an object (in the example the VFSM OnOff
) all its attributes are displayed. A click on the button Get reads a selected attribute or all attributes if the .all
pseudo attribute is selected. A click on the button Set writes the value entered in the edit box right to the button into the RTDB
. Note that only some attributes may be changed; most of them are just read-only.
In addition to the “display” section SWQuickPro contains a “test” section that is used for automatic testing, i.e. for creating command files that can be used for repeated tests in a step-by-step or continuous mode. Details of the testing facilities are described in [9].
Figure 34: The StateWORKS SWQuick monitor
3. Specifying VFSM
3.1 What will you learn now?
After the introduction we will specify a more complex VFSM. We want to discuss the most often used objects.
3.2 Example: Flow
The state machine controls a gas flow regulator. The Flow
state machine accepts commands (numbers) and sets an analog signal Flow_Ao
and a digital signal Flow_Do
. As feedback from the attenuator the state machine receives the actual gas flow values as an analog signal Flow_Ai
and a digital signal Flow_Di
indicating the regulator position (open/closed). Three commands determine regulator operations:
- 1 :
Open
the gas flow by setting theHigh
value of the digital outputFlow_Do
, - 2 :
Close
the gas flow by setting theLow
value of the digital outputFlow_Do
, - 3 :
Regulate
the gas flow to the value determined by the numerical outputFlow_A
o.
Figure 35: Gas Flow regulator
If the command Open
has been carried out the state machine should check whether the gas valve has been opened. If the valve does not open after a certain time an alarm should be issued.
If the command Regulate
has been carried out the state machine should check whether the gas flow has reached the required value. If the flow cannot reach the value in a certain time an alarm should be issued.
The actual gas flow is measured, and its value delivered as an analog input signal Flow_Ai
to the control system. Normally, it is required that the flow value stays within a certain limits. If the flow value exceeds the required range the state machine should after some delay issue an alarm and count this event. If it happens more than a certain number of times the state machine should issue immediately the alarm if the flow value exceeds the range.
3.3 Defining States
We start our design by drawing a state transition diagram. It does not contain all the details, but it gives a better understanding of the control problem and it forms the basis of the full specification as expressed in the tables of the StateWORKS Studio. Figure 36 presents the state diagram of the Flow
state machine. We do not say that this is our first ST diagram for the Flow
state machine! Usually, it takes several steps before we generate the ST diagram that fulfils all of our requirements. In studying this example, we went through several stages; here we present you just the ultimate solution without the intermediate exercises.
Figure 36: Flow
- the ST diagram
We prefer to use the Moore model of the state machine. Therefore, the diagram shows that the states contain Entry Actions but no Input Actions. In addition, we use also a few Exit Actions.
We have decided to solve the problem using the following states: Closing
, Standby
, Opening
, Open
, Busy
, Regulating
and FlowNotOK
. A detailed description of the states could be found in the documentation of the Flow
state machine.
Note the difference in handling of the alarm situations in states: Opening
and Busy
. In the state Opening
the Flow_Do
output is set to High
and the state machine checks whether the valve is open by testing the value of the Flow_Ai
. If the flow does not reach a certain value within a given time an alarm is issued and the state machine stays in the state Opening
.
In the state Busy
the analog input Flow_Ai
is set to a required value and the state machine waits until the value of the analog input Flow_Ai
is within the required range. If the flow does not reach the range within a certain time the state machine changes to the state FlowNotOK
where an alarm is issued.
These two different approaches are justified by the different significance of each failure. In the case of the state Opening
the failure is less important and it is enough to alert the operator who must take an Action and solve the problem. In the state Busy
the failure is serious and the system must take some Action by itself in addition to alerting the operator. The Flow
state machine by itself cannot do more - the appropriate Action depends on the application and will be, normally, effected by another state machine that “controls” the Flow
state machine. The state FlowNotOK
in the state machine Flow
is used to “send” the information about the flow error to another state machine. We will discuss this further when dealing with a system of VFSMs.
3.4 Defining I/O Objects
We specify I/O objects to define Virtual Input and Output Names for object Control Values and Actions. The MyCmd object is created automatically. Based on the description of the control problem we define the following I/O objects:
- timers:
TimB
used in the stateBusy
andTimO
for the stateOpening
- alarms:
AlaF
to signal the flow regulating error andAlaO
to signal the flow opening error - a digital output:
Do
to open the flow valve - a numerical (analog) output:
Ao
to set the flow value - a numerical (analog) input:
Ai
as an actual flow value - a switchpoint:
SwipF
to supervise whether the flow value is within the required range - a counter:
Cnt
to count how many times the flow exceeds the required range
3.5 Defining Input Names
For each I/O object we define names using its Control Value. So, we have defined three command names: CmdClose
, CmdOpen
and CmdRegulate
on 2, 1 and 3 numbers correspondingly.
Similarly, we define names TimB_OVER
and TimO_OVER
for timers using only one Control Value OVER
as we truly need only this condition for the specification.
We define input names for Control Values of the SwipF
object: Flow_HIGH
, Flow_IN
, Flow_LOW
, NOT_Flow_IN
(note the use of a complement value) and FlowControl_OFF
.
Eventually, we define a name for a Control Value OVER of the Cnt
object: Cnt_OVER
.
3.6 Defining Output Names
Definitions of Output Names are done similarly as in the previous example: for a given Action we invent a name that describes it. We have defined only names for Actions that are really needed by the table specification.
3.6.1 Setting an analog output
The specification of an analog (numerical) Action for the Ao
object is the only new point. The available Output Values for the Ao
object are: Off, Set
and On
. Choosing the Action Off
we determine that the numerical output value will be 0. Choosing the Action On
we determine that a certain value will be set to the numerical output (object Ao
). The value is determined by a parameter that is linked with the Ao
object. The parameter and its value will be determined at system configuration. Choosing the Action Set
we determine that the output value will be set only once, just at this moment when the Action is being performed.
This technique is the simplest one for specifying an analog output. Later, we will learn two other techniques: using tables and writing a user-specific output function.
3.7 Filling state transition table
We begin the state machine specification by drawing the first ST diagram. In the next step, we analyze each state and complete the specification with all transitions and Actions that are necessary for the correct functioning of the state machine.
Additional information about the states can be found in the comment fields of the ST table.
3.8 Configuring the system
The configuration of the Flow
state machine contains several new objects that we have not used in the first example OnOff
.
Also in this example we use the top-down approach. So, we begin with the creation of an instance of the state machine Flow
that we name as Flow
. Defining the properties of the state machine (i.e. determining the objects that belong to it) we choose names for all I/O objects in the system from Flow_MyCmd
through Flow_Swip_Range
.
3.9 Specifying object properties
After that, we start specifying the properties of all I/O objects. The properties of objects: Commands, Timers, Alarms, Digital input and output are specified as discussed in the first example. Now, we describe the properties of the object types that we have not met so far.
3.9.1 NO
(Numerical Output) Properties
The properties of a NO
object type include several values:
Format defines a value type: you can choose it from a list that contains typical formats, like integer, real, etc.
Unit is auxiliary information used for display: you can choose from a list of prepared strings like V, mA, etc. or you type any string you like.
Scale Mode decides how the output value will be transformed. There are two modes available: Lin(ear), Exp(onential).
Scale Factor is a coefficient used to multiply the nominal output value as taken from the Out Data.
Offset is a value added to the output value.
Out Data is a name of the Parameter object that supplies the output value. In the example, the output value is determined by the parameter Flow_Par_FlowSetValue
.
3.9.2 NI
(Numerical Input) Properties
Five properties of the NI
object type are the same as the properties of the NO
object type. They differ only in the last property. Instead of the Out Data the NI
object type has a property:
Threshold value is a number: up to this value the input signal is ignored and treated as 0.
3.9.3 SWIP
(Switch-point) Properties
Switch-point requires the definition of the Input and two limits. Switch-points can be set on Input objects that have numerical values (NI
, DATA and PAR
).
The Limit Low and Limit High values define the range of the input values supervised by the switch-point (see Figure 37). These limits can be defined directly by value or by a parameter (deactivating the switch By Value
).
Figure 37: Switchpoint definition
For the Switchpoint SwipF
we have defined the object Flow_Ni_ActualFlowValue
as the input and two limit values: 200 and 240 as limits.
3.9.4 CNT
(Counter) Properties
An object of a CNT
type has only one property: the timeout Const value. Reaching the value of Const the Counter signals it with the OVER Control Value. The counter Const could be a parameter if you remove the mark By value
.
For the Flow_Cnt_FlowRangeExceeds
we have defined Const = 4
.
3.10 Specifying I/O Units
The state machine Flow
contains three object types that are true external objects, namely: DO
, NI
and NO
. So, we have added the I/O Units to the project and defined which inputs and outputs correspond to the objects Do8_Unit3
, Ni4_Unit5
and No4_Unit7
.
We repeat at this point that the units must have a predefined Physical Address property if you want to test the system with the StateWORKS Lab. The properties of these units are summarized in the Table below.
The Comm_Port
is not used by the StateWORKS Lab, hence we just set it to 0.
Object type | DI | DO | NI | NO |
---|---|---|---|---|
Unit name | DI8_Unit1 | DO8_Unit3 | NI4_Unit5 | NO4_Unit7 |
Physical address | 1 | 3 | 5 | 7 |
4. Managing a System of VFSMs
4.1 What is a system of VFSMs?
It is a rather rare case to design a significant control system using only one state machine. If you need many cooperating state machines that will control a complex system you need an organizational framework that makes the job easier. The StateWORKS Project Manager offers you the framework to organize a complex control system.
We prefer and indeed recommend a hierarchical system of state machines [7] as demonstrated in the Gas
example below. Of course, you are not limited to a hierarchical structure. If, for whatever reason, you need a system of freely connected VFSM you can do it using the StateWORKS Project Manager.
The crucial feature of a system of state machines is the way in which they communicate with each other. In the RTDB
system this communication is done by and exchange of states and commands:
- States of a (Slave) state machine can be used as inputs to another (Master) state machine,
- The (Master) state machine can send commands to another (Slave) state machine.
There is a further possible exchange mechanism using other objects, especially XDA
. This type of communication will be presented later as an advanced topic.
4.2 Example Gas
The example presents a control system to control a gas inlet of a vacuum chamber used by semiconductor manufacturers (Figure 38). The system contains a flow control and a pressure control. The flow regulator supplies a gas to the chamber and it is controlled by the Flow
state machine discussed previously. The chamber is used for a manufacturing process that requires a certain vacuum in the chamber. The low pressure in the chamber is produced by vacuum pumps. Effectively, the vacuum in the chamber is determined by the pumps and the gas flow. The pressure is continuously monitored and if it exceeds the required range the process is interrupted and the gas flow must be discontinued.
Figure 38: A gas flow regulator with a pressure gauge
The system as designed contains 3 state machines: the Flow
state machine for gas flow control, the Press
state machine to monitor the vacuum in the chamber and a Gas
state machine that is a Master which coordinates the activities of the Flow
and Press
state machines.
The Flow
state machine has been discussed in the previous chapter. The Press
state machine can be found in the examples. We will present now the design details of the Master state machine Gas
The functioning of the Master state machine can be explained in terms of the communication rules among state machines in the RTDB
system.
Figure 39: A Gas control system
4.3 Opening the project
A single VFSM that has no links to other state machines may be specified outside a project. You can create a project later and include the state machine into it. We handle the Flow
state machine in such a way.
A Master VFSM must “know” the states of other state machines. The linkages among state machines are managed in a project. Therefore, before you start to specify a system of several state machines you have to create a project.
Create a project and add to it all state machines that already exist and that you intend to use in the system. Only the state machines that are in the project are “seen” when defining the specification of a Master state machine. At any time, during the development you can add additional state machines to the project.
You can remove a state machine from the project at any time.
4.4 Specifying the Master VFSM
The Gas
state machine is a Master of two Slaves: Flow
and Press
. It “sees” the Slaves through their states and sends them commands. The basic behavior of the state machine is described by the ST diagram in Figure 40.
The state machine reacts to two commands: 1 (Off)
and 2 (On)
. After initializing the state machine is in the state Off
. Receiving the command On
it changes to the state OnBusy
sending to the Flow
state machine the command CmdRegulate
.
If the Flow
state machine enters the state Regulating
the Gas
state machine changes to the state On
sending the command CmdEnable
to the state machine Press
.
If the state machine Press
goes to the state PressOK
the Gas
state machine goes to the state OK
. Disturbances into the flow cause the Gas
state machine to return to the OnBusy
state sending the CmdDisable
to the Press
state machine.
Bad pressure signalled by the Press
state machine must interrupt the process: the Gas
state machine changes to the state OffBusy
switching off the pressure monitoring (CmdDisable
to the Press
state machine) and cutting off the gas flow (CmdClose
to the Flow
state machine).
Figure 40: Gas
- the ST diagram
4.5 Defining States
The Gas
state machine has six states defined in the ST diagram: Init
, Off
, OffBusy
, On
, OnBusy
and OK
.
4.6 Defining I/O Objects
The Gas
state machine has five objects: an input command that it receives (therefore CMD-IN
), two state machines (VFSM) objects: Flow
and Press
and two output commands (therefore CMD_OUT
) sent to the Slave state machines.
4.7 Defining Input Names
The two Gas
command names (CmdOff
and CmdOn
) are obvious ones: they describe the input commands of the Gas
state machine. The other input names describe conditions that cover certain state situations of Slaves.
This text applies only for versions less than 7.0.
You may create complex state conditions in the form of AND-OR logical functions observing the following rules:
- Any number of VFSM states can be linked together with the OR-operator creating a complex state condition,
- Any number of state conditions for different state machines can be linked together by an AND- operator.
Thus, the name Flow_Busy
covering two states of the Flow
state machine means that the condition is TRUE if the Flow
state machine is either in the state Busy
or in the state FlowNotOK
. You may be more specific and call this condition Flow_BusyORFlow_NotOK
.
The Flow_StandbyANDPress_Off
means that this condition is TRUE if the Flow
state machine is in the state Standby
AND the state machine Press
is in the state Off
.
4.7.1 Specifying state conditions
You specify the following names that described the situations of the Slave Flow
: Flow_Regulating
, Flow_Standby
and NOT_Flow_Regulating
. Note that the name NOT_Flow_Regulating
is a complement of the state Regulating
i.e. it covers all states different that the state Regulating
. Similarly, you define the following names based on states of the state machine Pressure: PressBad
, PressOK
and Press_Off
.
These names will be used for specifying the conditions for state transitions and Input Actions.
This text applies only for versions less than 7.0.
To specify the name Flow_Busy
you begin with the selection of Flow
as I/O Object ID. In the Input Value window you get the list of Flow
states. You choose the state Busy
. Clicking on the Add button you see in the window Name the proposal for the input name: Flow_Busy
. If you like it you click again on the Add button and the entry is copied into the Input Name list. Keeping the Name and I/O Object ID you choose another state in the Input Value window - FlowNotOK
and copy the value into the Input Name list by clicking on the Add button. Now, under the name Flow_Busy
you have two values - states Busy
and FlowNotOK
. These two values (states) are linked with the OR operator and will be interpreted as: if the state machine Flow
is in one of the states - Busy
or FlowNotOK
the condition Flow_Busy
will be TRUE.
To specify the name Flow_StandbyANDPress_Off
you select first the Name, I/O Object ID and Input Value for Flow
as in the previous case. Then, keeping the Name you choose the Press
in the I/O Object ID window. In the Input Value window you get the list of Press
states. You choose the state Off
and copy the information into the Input Name list by clicking on the Add button. Now, under the name Flow_StandbyANDPress_Off
you have one value - state Standby
of the state machine Flow
and one value - state Off
of the state machine Press
. These two names are linked with the AND operator and will be interpreted as follows: if the state machine Flow
is in the state Standby
and the state machine Press
is in the state Off
the condition Flow_StandbyANDPress_Off
will be TRUE.
You can define any AND-OR combination of states. For instance, the name abcd
defined as:
Name | I/O Object ID | Input Value |
---|---|---|
abcd | VFSM1 | state1_1 state1_2 |
VFSM2 | state2_1 | |
VFSM3 | state3_1 state3_2 state3_3 |
represents the following logical condition:
and means: the condition abcd
is TRUE if the state machine VFSM1 is in one of the states: state1_1
or state1_2
and the state machine VFSM2 is in the state state2_1
and the state machine VFSM3 is in one of the states: state3_1
or state3_2
or state3_3
.
4.8 Defining Output Names
The list of Output Names contains four items - they are two names that specify commands: Close
and Regulate
for the state machine Flow
and two names that specify commands: Disable
and Enable
for the state machine Press
. Note, that the Master state machine does not use all commands of the state machine Flow
.
You define also the Output Name MyCmd_Clear
that is then used in the state OnBusy
as an Entry Action. That action is required to avoid a restart of the Gas
state machine on returning the states: Off
or OnBusy
.
4.9 Configuring the system
Using procedure described for a single state machine you create all objects required by the state machines: Flow
, Press
and Gas
.
4.10 Displaying the system
You may display the system of state machines by
View → SMS diagram → Show
or by clicking on the icon
It opens a state machines system diagram (SMS diagram) which presents all state machines configured in the system. For the Gas
example you get the display as in Figure 41.
Figure 41: Gas
- the SMS diagram
A state machine in this diagram is represented by a rectangle which contains the name of the state machine, for instance Gas
and the type in parenthesis, for instance (Gas
). The state machines are linked by lines with arrows, which correspond to the basic interface structure among VFSMs:
- An arrow at the top of the rectangle means a command coming from the Master.
- An arrow at the bottom of the rectangle means a Slave state used by the Master.
- A missing arrow means that the Slave does not take a command (at the top) or the Master does not use the state of a Slave (at the bottom).
By placing the cursor on the arrow you can display a tool-tip with the corresponding command or state. Those signals are also shown as labels which may be freely positioned or switched off.
The state machines system diagram (SMS diagram) shows the interface among state machines very clearly: commands sent from Master to Slave and state data sent from Slave to Master. This corresponds to a hierarchical structure of the system, which we recommend using in most situations.
This diagram has also some editing functions, such as:
- A double click on a state machine opens its Properties window.
- A SHIFT+ double click on a state machine opens its ST diagram.
- A single click on a state machine selects a state machine, and at that time also shows (in red) all the links to and from the selected state machine.
You may also select any link by clicking on it; this may help to identify the linked state machines in a complex system where several links overlap on the diagram.
One additional point needs to be made. The SMS diagram only shows the formal links made between the various state machines in the project, but there are some other, “back- door” methods of communication. For example, the use of a shared PAR
object to hold some parameter. It is also possible to find that state machines are linked through the process, in that one machine could start a motor and another be influenced by the fact that it is running.
These links are not shown on the SMS diagram, for practical reasons. It is good design practice to restrict all interactions to the formal links shown on the SMS diagram, wherever possible, and the entire structure of state machines will, in the hands of an experienced designer, conform to this practice in all but the most unusual circumstances. Links via shared objects will then be used only to alter some parameters but, in general, not to produce transitions, and links via the process will be reduced by careful partitioning of the task into the various state machines. The designer and his colleagues will then be better able to master the project.
4.11 Specifying object properties
For the Flow
state machine we just repeat what we have done in the previous example.
The Press
state machine represents also no difficulties as it contains only objects already discussed.
The objects for the Gas
state machine are the Slave state machines. They are represented in the object list by the VFSM states (Flow
and Press
) and commands sent to them (FlowCmd and PressCmd).
Having specified the state machines we have created also all other objects we need for the system. Definition of their properties is a repetition of already shown specification steps.
5. Specifying Units
A Unit is a list of objects. Any object type can be used to define the Unit. Units are used by programmers to organize and program I/O drivers.
The most obvious Units are groups of digital inputs (DI
) and outputs (DO
). Similarly, systems that process numerical (analog) inputs and generate numerical (analog) outputs use groups of numerical inputs (NI
) and outputs (NO
) that usually represents digital values of numerical (analog) inputs/outputs.
To specify a Unit you have to create a file, in a similar way to specifying a VFSM:
File → New → UNIT File
Figure 42: A UNIT DI8 specification table
You are confronted with a table that is used to specify the Unit´s objects.
A specification of a Unit makes only sense if there exists a I/O-driver that can address and use the units. For instance, the StateWORKS Lab has drivers that simulate DI
, DO
, NI
and NO
Units as described in the previous sections.
Generally, the Units are application dependent. In the eventual run-time system you may use either Units that correspond to standard serial and parallel I/O´s or you can use your hardware specific Units, supported by I/O drivers written for your hardware.
6. Printing and Publishing
The ST diagram and the ST tables can be:
- copied into clipboard (Edit → Copy ST table/diagram as Metafile and Directories as RTF file)
- saved as
.wmf
or.jpg
files (Edit → Save ST table/diagram as graphics and Edit → Save all ST tables as graphics)
In addition, by building the vfsm specification is stored as a XML file (VfsmName.xml
). You may display this file in the browser using our tool (vfsmml.dtd
and vfsmml.xsl
).
7. Linking to other Applications
7.1 StateWORKS run-time systems
The RTDB (Real Time Data Base) is supplied as a library, and is used to build a StateWORKS run-time system RTDBApp. The application then takes the form of a single EXE file containing the real time date base, VFSM executor and I/O system. The user interface can be any program which is able to communicate with RTDB via TCP/IP. An example of such an application is the SWLab which is used for exercises in the Manual. It is a RTDB run-time system with simulated I/O.
7.2 TCP/IP Link
The StateWORKS execution environment supports the TCP/IP mechanism. The real time data base of the VFSM Executor serves as a Server in the TCP/IP Client/Server link.
The TCP/IP connection is realized in two phases. In the first phase, the TCP/IP link between two applications is established - a communication channel is created. After that the applications can exchange data using this communication channel.
Using monitors: SWMon, SWQuick or SWTerm you are shielded from the details of the TCP/IP interface. The monitors may run on any computer in the network in which the RTDB application is running. With a few commands like: connect
, disconnect
, get
, set
, advise
, unadvised
you can communicate with the RTDB application.
8. Other topics
8.1 Using tables
8.1.1 Generation of analog output values
A pure logic system such as StateWORKS cannot process or directly create analog values. Analog values are delivered into the system as numerical values (NI
objects) and are translated into Control Values using switch-points (SWIP
objects). The Control Values of the SWIP
object are then used for control purposes.
Similarly, the system produces any analog outputs as numerical values (NO
objects). The system can set the numerical value to the output (NO
object On
or Set
) or clear the output value (NO
object Off
).
There are several ways to determine the value of the numerical output (see Figure 43).
The numerical output is an output of a NO
object. The NO
object switches on/off the value to the output. The On
command “closes” the switch between the value and the output. Thus, if for instance a parameter is the source of value any changes of the parameter will be transferred to the output. The command Set
sets the output only once, transferring the present parameter value to the output (i.e. the switch between the value and the output “closes” only for a while to transfer the values to the output). If you want to repeat the transfer you have to repeat the command Set
. The source of the value may be a table value, a parameter or a data value. The use of a parameter (PAR
object) to define a numerical output has been shown in the Flow
example. The use of data (DAT
object) is similar and will not be discussed here in detail.
The TAB
object as a source of the output value presents the most flexible solution. It allows the numerical value to have several values determined by the table entry. The table entries are parameters or DAT
values.
The entire specification of the numerical output consists then of the following steps: While specifying the VFSM:
- Define a
TAB
object in the I/O object Dictionary. - Define output names (in the Output Name Dictionary) that determine the numerical output values using the
TAB
object entries (indexes).
Figure 43: Determination of the numerical output value
While specifying the project:
- Define a set of parameter objects with required values of the numerical output.
- Define a
TAB
object that belong to the specified state machine. - Insert
PAR
orDAT
objects into theTAB
object.
If you need a more sophisticated output control you can implement it by writing an output function.
8.1.2 Example: SetAo
The procedure as described in the previous section is illustrated by a SetAo
example. It is a system with two digital inputs: SetAo_Di0
and SetAo_Di1
and an analog (numerical) output SetAo_No
. The system is to realize a step function on the analog output - the value should be set step by step to four values, for instance: 0, 500, 1000 and 2000. The steps are triggered by setting High the input Di0
. The input Di1
switches off the analog output, effectively setting it to 0.
The state machine SetAo
has six states. Four of them are used to set (in Entry Actions) the value of the analog output according to the requirements. In the state Clear
the analog output is switched off. Note the use of Clear
Action to remove the input name IncAo
by entering a state.
Start also the Monitor to see the state changes. Notice that from the Monitor you can change the output values of the steps by changing the parameter values.
We have put the SetAo
state machine into the project Other
. In this project we also have other state machines for examples that follow. The RTDB that is in fact the application may contain several state machines. The state machines may create an integrated system of state machines as in the Gas
project or they are can be quite independent state machines, each realizing some specific functions.
8.2 Output functions
It may happen that some requirements cannot be fulfilled using standard objects offered to you by our system. Especially, tasks that require significant execution time should run in their own threads so that the VFSM executor is not blocked. These kinds of tasks should be moved to output functions that are activated by the executor. The output function object (OFUN
) represents the programmer’s interface.
To use an output function you have to specify an OFUN
object in the I/O Object Dictionary. This object appears as an input and output object in Input/Output Name Dictionaries. In both cases the (input/output) value can be an integer.
Specifying an output name for an OFUN
object means that this name will call the output function. The value for the output name is a parameter for the output function.
Specifying an input name for an OFUN
object means that this name will be triggered by the output function if the return value of the function is equal to the input value.
The XDA
object plays an important role in output functions as their private memory.
While specifying the project, in addition to the object name, you have to define the function name and the unit name. The unit name is the unit that is used when programming the output function as it contains the list of objects that the output function may access.
The details of programming interface and how to link output functions with the system can be found in the RTDB Programmer’s Guide [3].
We show here only how to use an existing output function in the state machine specification.
8.2.1 Example: Stepper
Figure 44: Stepper control
Stepper
sets the output voltage, setting numerical output Ao
and gets the feedback information about the truly set voltage via a numerical input Ai
. Assume that the output voltage sets a digital to analog converter (D/A) which delivers the required voltage and the voltage is in turn sensed by an analog to digital converter (A/D), which supplies the numerical value Ai
to the control system. Figure 44 shows objects involved in the Stepper
control.
Stepper
should generate several voltage steps, each for a defined duration. In the Off
state the output voltage should have the value 0. The process starts by a command On
. At any moment the stepping process can be interrupted by a command Off
. If the output voltage does not reach the set value in the time prescribed for a given step the system waits until the required value is reached. The output voltage should have for instance the following form:
Figure 45: Stepper output voltage (Ao)
If the output value does not reach the -10 V in T2 time the system prolongs the step 2 and waits until the set voltage is reached.
Figure 46: Stepper output voltage with delayed second step
We could realize the Stepper
control using only RTDB
objects. For the sake of this example we move some Actions to the output function which is going to perform the following tasks:
- set the timer (
Ti
), - set the switch-point (
Swip
) value and enables it (commandOn
) - set the numerical output (
Ao
).
All timer timeouts and switchpoint limit values are defined by parameters.
The use of the output function for the Stepper
has some (positive) side effects, namely we can use only one Timer and one Swip object independently of the number of required voltage steps. Instead, we shall use many parameters.
The ST diagram of the Stepper
is as follows:
Figure 47: Stepper - the ST diagram
The Stepper
waits in the Off
state for the start. On receiving the command CmdOn
or when the DiStart
signal is active, Stepper
goes to the state Step1Busy
where it calls the output function (SetStep1
) and starts the Timer. The output function does the above listed Actions and Stepper
waits until the Swip object signals (Swip_IN
) that the output voltage sensed by Ai
has reached the required value. If this is the case Stepper
goes to the state Step1
where it switches on a digital output Do1
and disables the switchpoint. The digital output just indicates that the voltage is ok. Stepper
remains in the state Step1
until the Timer is OVER which causes the transition to the state StepBusy2
. The transition condition Tim_OVER
is AND-ed with the switchpoint state Off
to avoid slipping through state on the control value Swip_IN
. When leaving the state Step1
Stepper
switches off the digital output Do1
, stops the Timer and switches off the Swip. Processing of the next steps is done exactly in the same manner.
If you analyze the list of IO objects defined for the Stepper
state machine you notice that it contains several objects (XDA
and PAR
types) that are not used by the specification of the Stepper
behavior. The reason is that we require also a list of objects used in the output function. Instead of preparing a special Unit for the output function we included all objects in the IO object list for the Stepper
state machine. The XDA
object is there as a supplier of a “private” memory for the output function thread.
8.3 Implementing combinational systems
Sometimes, a state machine reduces to a pure combinational logic system i.e. a system that does not need states to “store” the history of input changes. You can use the StateWORKS Studio to specify such a state-less system.
A combinational system is specified in the Always table. Effectively, such an application contains one default state Init that always exists in the table. Therefore, you can specify the combinational system also in the mandatory Init state as its Input Actions. In such a case the other fields: Entry, Exit, Clear and Transition are meaningless and are not used.
For each output two logical conditions must be specified: the On-function that sets the High (TRUE) value of output and the OFF-function that clears the output (Low). Note that a true don’t care situation can be achieved here. For instance, specifying logical condition for an output Y (A, B, C) as:
Logical Condition | Output |
---|---|
A B´ + B´C | Y |
A´C´ + B C´ | Y´ |
you effectively decide that the condition B=1 and C=1 is ignored. If both B and C are simultaneously TRUE the output Y will not change (remains High or Low).
8.3.1 Example Combi
The Appendix contains a more complex example of a combinational system: COMBI. This system has three outputs: X, Y, Z and six inputs: A, B, C, D, E and F.
The logical functions are realized as fully defined functions (without any don’t care input conditions). For instance, the Karnaugh map for the output X looks like this:
ABC | |||||||||
---|---|---|---|---|---|---|---|---|---|
000 | 001 | 011 | 010 | 110 | 111 | 101 | 100 | ||
DEF | 000 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
011 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
010 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
110 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
111 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
101 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | |
100 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | |
X |
8.4 Multi-valued objects
The “natural” variables often used for control are the Boolean ones. The VFSM concept adds to the Boolean variables multi-valued control variables. In fact, in the VFSM concept the Boolean variable does not play any special role: it is just a Control Value as any other multi-valued variable.
8.4.1 Input values
All input and input/output objects (DI
, TI
, CNT
, ECNT
, SWIP
, STR
, UDC
, NI
, DAT
, PAR
, OFUN
) “generate” a few Control Values. For instance, a timer (TI
) has the following Control Values: RESET
, STOP
, RUN
, OVER
, OVERSTOP
. A state machine (VFSM object) has several Control Values which are its states.
Another problem exists if we have to “translate” a number of values into Control Values. In certain situations we call the values “commands”. In other situations the values may represent a movement direction, working mode or some physical value: temperature, pressure, etc.
We may try the “traditional” way of representing a value as number of base 2 using DI
objects which are to store Boolean values. It will work at least for integer values. This solution is not very convenient as the decoding of the values is relatively complex. The easier way is to use object types which can represent multi-valued variables: CMD
, XDA
, NI
.
A CMD
[7] object can be used either as an input or as an output object. Normally, a CMD
object is an output object in one state machine (Master) and the same object is then an input object in another state machine (Slave). The CMD
object used as an input object (CMD-IN
) can be used also to generate an output name – for details see [8]. The CMD
object is a positive integer: 1, 2, 3, … and its various values are given names that are used as input names in the Slave state machine and as output names in the Master state machine. Thus, these names representing the numbers are the Control Values of CMD
objects.
An XDA
object can be used as an input or as an output object even in the same machine, the only restriction being: a XDA
-input name and a XDA
-output name must not be used in the same state. The XDA
object has several functions. It is used to:
- supply a memory for output functions (see “Example: Stepper”)
- pass information between RTDB and I/O units
- represent a multi-valued variable
- exchange information among state machine (extending
CMD
objects) - storing information in a state machine
A typical usage of an XDA
object is to convert the contents of a message to Control Values: the message is analyzed in an I/O unit and the result is coded into several XDA
values which are then used to define input names for a state machine. The same works for the other direction: the XDA
values are used to define output names that define some Actions in the I/O unit, or some messages.
The usage of XDA
to store information in a state machine should not be overused as it is nothing other than a kind of flag to store some information to be used in the future. In a properly designed state machine there should be no need to use this kind of flag.
Similarly, XDA
objects should not replace commands in the communication among state machines. Commands are the proper interface between two state machines. Any additional exchange of control information makes the system more complex and error prone. The use of XDA
for state machine communication will generally mean that the state machines are not well designed.
The NI
object itself is of no direct relevance in control. It can only store a value of any software type (int, float, bool, char, etc.) but it has no Control Value. Therefore the NI
object does not appear in the IO Object ID list of the Input Name Dictionary and cannot be used directly to define an Input Name. The Control Values of an NI
value can be generated using a SWIP
object: see “SWIP (Switch-point) Properties”.
8.4.2 Output objects
Similarly to inputs, the RTDB has not only a digital output object (DO
) which stores and outputs a Boolean value but also a few objects to supply multi-valued outputs: NO
, TAB
, AL
. The usage of the TAB
object has been discussed in “Generation of analog output values”. AL
objects are used for a very specific function - to generate an alarm.
The only object which is actually used to supply a multi-valued output is the NO
object but it does it in an indirect way. The NO
object itself has only 3 output values: Off
, Set
, On
(see “Generation of analog output values”) which are used to pass the true output value which can be of type PAR
, DAT
, NI
.
8.4.3 In-Out objects
There is a group of objects, which are both: input and output objects: TI
, CNT
, ECNT
, UDC
, OFUN
, XDA
, SWIP
, STR
. This feature of these objects allows triggering a change of its internal state using an Action, which in turn leads to a change of a Control Value which is based on its state. For instance, starting a timer with an output ResetStart
(effectively it is a timer input) results some time later when the timeout elapses in an OVER
timer state which may be used as an input Control Value.
Figure 48: Timer object
The counter objects: CNT
and ECNT
have the same features as a TI
object. The fourth counter UDC
is different from the CNT
object. The UDC
object is an event counter which in addition can be triggered by commands: Clear
, Down
and Up
but does not generate an OVER
state. Its state can be detected and translated into Control Values using a SWIP
object, as for NI
objects.
OFUN
object can be used only with an output function. The OFUN
output is a parameter passed to the output function defining the task to be done by the output function. The return value of the output function is the OFUN
Control Value.
The usage of the XDA
object has been discussed in the previous section.
The usage of a SWIP
object has been discussed by describing the translation of multi- valued inputs into Control Values of an object (NI
, PAR
, DAT
, UDC
) supervised by SWIP
. The output to a SWIP
object (Off
, On
) does not influence the Control Value of the supervised object; it simply enables/disables SWIP
functioning. The Control Values evaluated by the SWIP
object reflect the Control Value of the supervised object.
The STR
object is used for string analysis. Similarly to the SWIP
object, a STR
object “supervises” an input object that can be a DAT
or PAR
with string format. A regular expression, which defines the string used as a matching pattern, can be hard coded or a content of a DAT
or PAR
object. The output to a STR
object (Off
, On
, Set
) does not influence the Control Value of the supervised object; it simply enables/disables / acknowledges STR
functioning. The Control Values evaluated by the STR
object reflect the Control Value of the supervised object. In addition, if matched the result is stored (and automatically converted into appropriate format) into DAT
; PAR
, NI
or NO
objects (the result may contain several strings).
Principally, the CMD
object is also an object that is used as an input and an output but as we mentioned in the previous section it cannot be used in these two functions in the same state machine. The object CMD
serves as an interface between two state machines.
8.5 Using VFSM-Templates
8.5.1 What is a Template?
A complex control system contains several cooperating state machines. They cooperate by exchanging state and commands. As a rule, any state machine does not need full information about its cooperating counterparts. A state machine is interested only in a few (stable) states of its partners and can only send a few commands to them.
When developing the specification of a (Master) state machine that coordinates several other state machines we would like to have a freedom to alter the Slave state machines. A development and maintenance process requires steady modification of the state machines. If the state machines are linked together, any changes in a Slave state machine resulting in introduction or removing of states and commands may require changes in the Master state machine.
A Template is a skeleton of a state machine containing definitions of its states and commands. The Template contains only those states and commands that are interesting for and used by other cooperating state machines.
When creating a new state machine we decide whether the state machine is Generic or based on a Template. If the state machine is Template-based the Template can be considered as an interface among state machines. Other state machines that communicate with a Template based state machine “see” only the Template.
As a Template contains only a subset of states and commands it may be used as a common basis for several similar state machines. This makes easy to design a Master of such state machines. Also changes of a Template-based state machine do not have any influence on the Master if the Template does not change.
8.5.2 Example: Template
We will illustrate the concept of a Template by a more complex example of the previously-discussed Gas
control system. This time the system contains five state machines: the Master Gas
, the pressure control Press
and three gas flow control Flow
. We use the previous VFSM Press
. We replace the Flow
VFSM by a Template based version. If you compare the specifications of the Generic and Template based Flow
state machines you will not notice any differences. The only difference is that using the Template based Flow
VFSM you define the Template TFlow
as a Slave of the Gas
VFSM.
Figure 49: Gas
with 3 Flow
Slaves - the SMS diagram
8.5.3 Specifying a Template
We specify a Template for the Flow
state machine opening the Template:
File → New → Template Document
The Template window contains two tables. The state table is initialized with the obligatory Init
state. For the Gas
example we have defined: Busy
, FlowNotOK
, Regulating
and Standby
states. Defining commands we have to specify names and command values. For the Gas
example we have used: CmdClose
(2) and CmdRegulate
(3).
To be used, the Template must be Build like a normal VFSM and added to the project:
Project → Edit
In the List Files of Type window you can select the TMPL type files and Add the displayed Templates to the Project.
Figure 50: Flow
- the template window
8.5.4 Generating a Template from a VFSM
Alternatively, we may take the already existing Flow
state machine and produce a Template:
File → Generate Template
(the option is only available when the state transition diagram is open)
A Template is then generated with all Flow
states and commands.
By deleting the states (Closing
, Open
, Opening
) and commands (CmdOpen
), which are not used by the Master (Gas
) state machine we get the required Template.
This command not only allows you to generate Templates at a later stage in the project from the state machines designed already, but also to change the basis (Generic or Template) of the VFSM (see the next section).
Figure 51: Flow
- the template generated from existing Flow
state machine
8.5.5 Changing a VFSM Template
A state machine (VFSM) must be connected with a corresponding Template. It is done by definition of the VFSM base and connecting it to the Template. The basis (Generic or Template) of a VFSM can be changed at any moment. Using:
File → Change Template
(the option is only available when the state transition diagram is open)
you can either change a Generic VFSM to a Template based machine or vice-versa: a Template based VFSM to a Generic one. When changing a Generic VFSM to a Template based one you can use Templates that are part of the project (Project → Edit → Add).
8.5.6 Connecting VFSM to Template
A Template based state machine is connected to its Template in the following window:
Dictionary → Input → My Cmd
(the option is only available when the state transition diagram is open)
You have to connect each command separately, selecting them on both sides: Template and VFSM.
The changes to the VFSM basis sometimes require a manual test and adaptation of VFSM commands: First of all, you have to Add Template commands to VFSM commands. Then you are free to introduce other commands that you need for the state machine.
Remember that the Master will use only the Template commands.
Figure 52: My command window used to connect VFSM to Template
A Template is a way of defining the interface between Master and Slave state machines. When specifying the system objects in a Project we have to create true state machines and not Templates. Therefore, in a Project we use state machines that are connected to corresponding Templates.
8.5.7 Application Notes
The number of topics related to StateWORKS Studio is very large. A User’s Guide cannot exhaust all of them. Searching for other themes you may consult the Technical Notes.
9. VFSMs documentation
The files available in the ...\Projects\Samples
directory in the installation package contain full documentation of the examples discussed in the manual:
OnOff
- Standard on/off controlPress
- Pressure controlFlow
- Flow controlGas
- Master flow control (with generic state machines)Gast
- Master flow control (with template based state machines)SetAo
- Setting analog outputOnOff
- Combinational systemStepper
– Using output function
For your convenience, the state transitions printout of the first example, OnOff
has been appended to the printed manual.
9.1 OnOff
example
Object ID dictionary
Name | Object Type | Description |
---|---|---|
1 MyCmd | CMD-IN | - |
2 Timer | TI | - |
3 Alarm | AL | - |
4 Di | DI | - |
5 Do | DO | - |
Input name dictionary
Name | I/O Object ID | Input Value | Init |
---|---|---|---|
1 always | - | - | + |
2 CmdOff | MyCmd | 1 | - |
3 CmdOn | MyCmd | 2 | - |
4 Timer_OVER | Timer | OVER | - |
5 DeviceOff | Di | LOW | - |
6 DeviceOn | Di | HIGH | - |
Output name dictionary
Name | I/O Object ID | Output Value |
---|---|---|
1 Timer_ResetStart | Timer | ResetStart |
2 Timer_Stop | Timer | Stop |
3 Alarm_Coming | Alarm | Coming |
4 Alarm_Going | Alarm | Going |
5 SwitchOff | Do | Low |
6 SwitchOn | Do | High |
State name dictionary
Name |
---|
1 Init |
2 Off |
3 OffBusy |
4 On |
5 OnBusy |
OnOff
OnOff
is a simple state machine (vfsm), which demonstrates basic control principle.
It controls switching of a DO
output which is triggered by commands: On
and Off
.
The output changes have to be acknowledged by a feedback signal in a form of a DI
input.
When switching On
the feedback is supervised by a timer and in case of failure an alarm is generated.
This state is a done state.
Nothing happens when entering the state.
The vfsm waits for a command and reacts only to a command Off
.
On entering this state the Do
is set Low
and the vfsm waits for an acknowledgement from Di
.
If the acknowledgement comes the vfsm goes to state Off
.
If the command On
comes before the acknowledgement the vfsm changes to state OnOff
.
This state is a done state.
Nothing happens when entering the state.
The vfsm waits for a command and reacts only to a command On
.
All Vfsms starts from this state.
By choosing a suitable next state you decide what action will be carried out when starting the system.
On entering this state the state machine sets Do
high and starts the Timer
.
If Di
acknowledges that the controlled device has been switched on the vfsm goes to state On
.
If the command Off
comes before the acknowledgment the vfsm switches to state OffBusy
.
If Timer
expires an Alarm
is generated.
10. References
[1] Wagner F., al.: Modeling Software with Finite State Machines: A Practical Approach. Auerbach Publications. New York, May 2006.
[2] Wagner F.: The Virtual Finite State Machine: Executable Control Flow Specification. Rosa Fischer-Löw Verlag, 1994.
[3] SW Software. StateWORKS RTDB Programmer’s Guide. Release 5.0.6. 2004.
[4] SW Software. SWTerm.pdf. 2003.
[5] TN1-Virtual Environment
[6] TN2-What is StateWORKS
[7] TN3-Hierarchical system
[8] TN4-Commands
[9] TN20-Testing with StateWORKS
[10] TN22-Complement control values in VFSM concept
[11] Tutorial: Specifying state machine
[12] Tutorial: Specifying system of state machines
[13] Tutorial: Specifying RTDB
For more information, refer to other Technical Notes.
10.1 SW Studio Quick Reference
Here you can view the unedited file directly from the author: PDF