Specifying RTDB (execution environment)

Introduction

The tutorial teaches you how to specify the RTDB which is the base of any StateWORKS application. We assume that you know about the specification of a virtual finite state machine and about the specification of a system of virtual finite state machines.

The result of the RTDB specification is a set of files that may be read by a StateWORKS run-time system. To test the specified system you may use the SWLab and Monitors available in StateWORKS Studio under the menu Tools.

The tutorial uses the project Pumps from the book, to illustrate the design steps. In the book you find detailed requirements and analysis of the control task. For the purpose of this tutorial some partial specifications are provided which may be loaded to accelerate the training (observe corresponding notes).

Terminology table

Terminology	Explanation
Always (table)	A table used for specification of combinational systems or Input actions valid for all states
Entry action	An Output name describing an action performed by entering a state
Exit action (written also as eXit action)	An Output name describing an action performed by exiting a state
Id name	A name of an object
I/O Object Dictionary	A list of all defined objects
I/O Object Id	see: Id name
Init (flag)	A flag: if marked instructs the execution system (RTDB) to initialize the virtual input to that value
Init (state)	A default state which cannot be deleted but can be renamed
Input	see: Input Name
Input (tab)	see: Input Name Dictionary
Input action	An Output name describing action performed if an Input action condition is due
Input action condition	A condition defined using Input names linked by AND and OR operators
Input action expression	Input action condition and Input action
Input action priority	The sequence of Input action expressions in the ST table; used for documentation purpose
Input Name	A name of a control condition (defined on an Input Value)
Input Name Dictionary	A list of all defined Input Names
Input Value	Object input value
MyCmd	A default Input Name of a type CMD which cannot be deleted but can be renamed
Next State priority	The sequence of state transitions in the ST table; determines the execution sequence
Operators: AND (&), OR (|)	Boolean operators
Output	see: Output Name
Output (tab)	see: Output Name Dictionary
Output Name	A name describing an action (defined on an Output Value)
Output Name Dictionary	A list of all defined Output Names
Output Value	An Object output value
Prefix	A VFSM specific prefix used in h-files generated for each VFSM
ST diagram	A state transition diagram used for graphic presentation of a state machine behavior
ST table	A state transition table used for detailed specification of a state.
State	see: State Name (drawn as a circle on the ST diagram)
State Name	A state name
State Name Dictionary	A list of all defined State Names
Transition	A transition between two states (drawn as an arrow on the ST diagram)
Transition condition	A condition defined using Input names linked by AND and OR operators
Transition expression	Next state and Transition condition

What is this process for?

A very powerful feature of the StateWORKS concept is the way state machines (VFSM objects), once they are designed, can be used, in several instances, in a project and can also be taken over to new projects very easily.

All state machines (VFSM) are designed to function in a “virtual environment”, and you now need to learn how to configure them to run them in the real environment, using the RTDB. For this, the project window is used.

The VFSM you have designed - and in fact each instance of any such design – must be placed in your project and linked to the real input-output signals, commands, etc. which will be used.

Creating a VFSM object

Most of this work is carried out in the project window.

1. Expand the tree VFSM in the Project pane Object type.
2. Select an object type, for instance Pressure.
3. Clicking on the button New create a VFSM object in the pane Object Name. The object gets the default name Pressure1.
4. You may edit the object name in the Property window which opens automatically by creating or selecting the object.
5. You will define all Properties of the VFSM object later when all required objects are created. At that moment you may define the name and prepare the Description (Text and Link).

6. Similarly, create other required state machines: Main, Device1, Pressure1 and Pressure2.
7. You may control the progress by opening the SMS diagram (shape the diagram according to your preference).

Creating a CMD object

1. Selecting any state machine, you see in the Property window a list of all its objects.
2. Start creating objects, for instance MyCmd for Pressure.
3. Expand the tree Interface in the pane Object type.
4. Select the type Cmd and create the object Cmd:01 by clicking on the button New.

5. Define properties of the newly created object in the Property window:
   • Give the object a more expressive name, for instance Cmd:Pressure.
   • Fill the property Type with the name of the state machine type; in that case Pressure (case not sensitive).

6. Similarly, create command objects for all state machines.
7. You may use the button New or Duplicate.
8. You may Delete at any time an existing object if it is not used by other objects (try commands Where used and Mark not used in the menu opened by the right mouse click in the pane Object Name).

Creating a TI object

The Pressure1, Pressure2 and Device1 need timers; thus you have to create 3 objects of type Ti.

1. Select the type Counter → Ti in the pane Object type.

2. Create the object Ti:01 in the pane Object Name and edit its properties in the Property window.
3. Accepting for instance the By Value = True and defining the timeout (Const Value = 100) and the Clock = 100ms you get a timer Pressure1:Ti for the state machine Pressure.

4. Similarly you define a timer for the state machine Pressure with the Const Value = 80 and a timer for the state machine Device1 with the Const Value = 120: other properties are the same.

5. Choosing Const Value = False you have to define a source of the timeout value (Object Name); it may be an object of type PAR, NI or DAT. As a rule such an object is not owned by a state machine; it is just a parameter of another object.
6. Create a required object, for instance PAR and complete the Ti properties.
7. The same procedure must be applied to other objects like for instance SWIP, CNT, etc.

Creating RTDB objects

Creation of RTDB objects until you define all objects required by the application.

Now you can finish the definition of state machine properties.

1. Select for instance the state machine Pressure1 in the pane Object Name, select the property Ti in the Property window and open the list of timers in the system.
2. Clicking on Pressure1:Ti define a timer for the Pressure.

3. Eventually, you get all properties for a state machine Pressure1 as shown below.
4. Similarly, you define properties for all state machines in the system.

SMS diagram

If you create objects required by all state machines (Device1, Pressure1, Pressure2, Main) you get the system of state machines as shown in the SMS diagram below.

Note: load Pumps.prj from the Pumps_Tutorial folder.

You may test the system using SWLab and StateWORKS monitors but you will notice that it does not work correctly (missing access to output functions).

Creating UNIT object

The RTDB objects created so far can be accessed via TCP/IP; you do it for instance using StateWORKS Monitors.

The TCP/IP access is mainly intended for a user interface. But you may define an I/O interface which requires to have specific I/O handlers in the run-time system. SWLab has such an I/O Handler to simulate digital / analog inputs and outputs available on the SWLab user interface in the form of switches, LEDs, potentiometers and gauges.

In the following part you will use predefined UNIT types for creation of UNIT objects required by the SWLab I/O Handler.

In addition you need a UNIT which represents the interface for the user function called by objects of type OFUN.

(Using the button Add in the dialog window opened by Project → Edit,) add UNIT types: DI8, DO8, NI4, NO4 and OfuLimit to the project

1. Create UNIT objects for each I/O type.
2. Create two objects of type OfuLimit: one for each state machine of type Pressure.

In principle, a UNIT is a list of objects. In addition to standard properties (Name, Description), it has also two specific properties: Phys Address and Comm Port.

Specifying the UNIT object list you have to decide which elements of SWLab will be used for the project Pumps.

For instance for the DI-UNIT, you may choose object as shown below.

Note the value 1 chosen for the Phys Address. It is required by the run-time system. Similarly, the DO-UNIT requires the value 3, NI – the value 5 and NO – the value 7.

Below you see values chosen for UNITs of type OfuLimit. To interpret them you have to know the requirements of the OfuLimit function used by the state machines of type Pressure.

The values of properties Phys Address and Comm Port are irrelevant in that case.

System complete

Note: load Pumps.prj from the Pumps folder.

Now you have a complete system Pumps which is able to use the User functions for calculating of SWIP limits as well as SWLab I/O interface. The SMS diagram of the Pumps system and the SWLab is shown below.

References

[1] Book Modeling Software with Finite State Machines: A Practical Approach
[2] StateWORKS Studio Help
[3] StateWORKS Development Tools: User’s Guide & Training Manual
[4] StateWORKS: Technical Notes
[5] StateWORKS: Specifying a state machine
[6] StateWORKS: Specifying a system of state machines

---

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