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.3 Defining States
  • 2.4 Defining the Virtual Environment
  • 2.5 Defining I/O Objects
  • 2.6 Defining Input Names
    • 2.6.1 Initializing the virtual input
    • 2.6.2 DI (Digital Input) Input Names
    • 2.6.3 TI (Timer) 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.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.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.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.22 Tracing
  • 2.23 Monitoring RTDB using SWTerm
  • 2.24 Monitoring RTDB using SWQuickPro
• 3. Specifying VFSM
  • 3.1 What will you learn now?
  • 3.2 Example: Flow
  • 3.3 Defining States
  • 3.4 Defining I/O Objects
  • 3.5 Defining Input Names
  • 3.6 Defining Output Names
    • 3.6.1 Setting an analog output
  • 3.7 Filling state transition table
  • 3.8 Configuring the system
  • 3.9 Specifying object properties
    • 3.9.1 NO (Numerical Output) Properties
    • 3.9.2 NI (Numerical Input) Properties
    • 3.9.3 SWIP (Switch-point) Properties
    • 3.9.4 CNT (Counter) Properties
  • 3.10 Specifying I/O Units
• 4. Managing a System of VFSMs
  • 4.1 What is a system of VFSMs?
  • 4.2 Example Gas
  • 4.3 Opening the project
  • 4.4 Specifying the Master VFSM
  • 4.5 Defining States
  • 4.6 Defining I/O Objects
  • 4.7 Defining Input Names
    • 4.7.1 Specifying state conditions
  • 4.8 Defining Output Names
  • 4.9 Configuring the system
  • 4.10 Displaying the system
  • 4.11 Specifying object properties
• 5. Specifying Units
• 6. Printing and Publishing
• 7. Linking to other Applications
  • 7.1 StateWORKS run-time systems
  • 7.2 TCP/IP Link
• 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.3 Implementing combinational systems
    • 8.3.1 Example Combi
  • 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
• 9. VFSMs documentation
  • 9.1 OnOff example
• 10. References
  • 10.1 SW Studio Quick Reference

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 to OffBusy with the command CmdOff.
• From OffBusy to OnBusy with the command CmdOn.

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, or string.
• 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
• External digital signals: DI, DO
• External numerical (analog) signals: NI, NO
• Output demultiplexer: TAB
• Supervision:
  • Switch-point: SWIP
  • String: STR
• 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.

Note

The I/O objects you have specified are real but not yet fully configured. You can use them to make the VFSM specification. However, they will become truly “real” when you configure them with the StateWORKS Project Manager during system setup. For example, you’ll configure properties such as the timeout value for the Timer.

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.

1. Choose the I/O Object ID and its Input Value.
2. 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 for HIGH
• DeviceOff for LOW

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.

Note

After initializing, the value of a DI object is not known, and the virtual input contains no names defined on digital inputs. The virtual input can be explicitly initialized to certain values by marking the Init flag in the Input Name Dictionary.

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 and Going 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.

Caution

All state machines are initialized in the Init state. Generally, state machines do not return to the Init state. If you specify a state machine that returns to the Init state, remember that it likely does not make sense to specify an Entry Action for the Init state, as this action will not be executed at start-up.

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:

(DeviceOff | TimerOVER) & CmdOff

By using the menu command:
Options → Expand Expression,
this expression will be transformed into:

DeviceOff & CmdOff | TimerOVER & CmdOff

In the standard form, the AND (&) operator has higher priority than the OR (|) operator.

Caution

Once an expression is expanded, it cannot be reverted to its original form with brackets.

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

Note

The Physical Address property of the units must remain unchanged if you plan to test the system with the StateWORKS Lab. The value of the Comm Port property is irrelevant for this testing scenario.

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:

1. Entering a numerical value (clicking on the number opens an entry window), or
2. 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:

1. First line: Displays object type information based on your selection (VFSM, UNIT, or User).
2. 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:

1. 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.
2. 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, or ACK.

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), the VFSM 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, the A appears; otherwise, it shows a dash. If no next state is expected, the field will show none.

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 name SWTerm.log.
• -r → Commands and responses will be logged, otherwise only commands.
• -c → Take commands from the file CmdFileName, 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 the High value of the digital output Flow_Do,
• 2 : Close the gas flow by setting the Low value of the digital output Flow_Do,
• 3 : Regulate the gas flow to the value determined by the numerical output Flow_Ao.

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 state Busy and TimO for the state Opening
• alarms: AlaF to signal the flow regulating error and AlaO 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.

Caution

The counter functions like a timer. Hence, you have to Start or ResetStart it before you apply the Inc (increment) or Dec (Decrement) Action.

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.

Caution

The Scale Factor should not be 0.

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.

Caution

The Scale Factor should not be 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:

abcd = (state1_1 OR state1_2) AND
state2_1 AND
(state3_1 OR state3_2 OR state3_3)

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 or DAT objects into the TAB 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 (command On)
• 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, 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 control
• Press - Pressure control
• Flow - Flow control
• Gas - Master flow control (with generic state machines)
• Gast - Master flow control (with template based state machines)
• SetAo - Setting analog output
• OnOff - Combinational system
• Stepper – 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] StateWORKS RTDB Programmer’s Guide
[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

ST table and diagram

SMS diagram

---

Here you can view the unedited file directly from the author: PDF