Skip to content
StateWORKS

Getting Started

Getting Started with StateWORKS Studio

Table of Contents

1. Overview

1.1 What is StateWorks?

StateWORKS is a set of tools for producing reliable software. The basis is the use of finite state machines to express the behavior of a system. These are created by using a special editor, which operates on State Transition diagrams, in a graphical form, and State Transition tables, in a text format, holding all the details. These two different expressions of the same design are closely synchronized throughout the process.

StateWORKS includes powerful tools and techniques for handling complex systems using many state machines at the same time. Normally, state machine designs start to get difficult when all sorts of possible error-handling measures have to be added to a design which would be fine when everything worked around it. This can cause an increase in the number of states, if not handled correctly. StateWORKS makes it easy to split a design into a number of state machines, normally arranged in a hierarchy, and to implement the resulting system. In fact this is one of its strongest points. Most programmers can easily handle the programming of a single FSM, but it can be tricky to deal with a large number of them running in a big system.

The finite state model used by StateWORKS is a pure one, from which input-output processing and numerical computations are kept out of the state machines, which run in what we call a “Virtual Environment”. They are called “Virtual Finite State machines” for this reason, and you will encounter the abbreviation “VFSM” in several parts of the documentation. A VFSM is only aware of significant instantaneous aspects, or states, of its inputs (including lower-level VFSMs in a hierarchy).

Of course, real physical input-outputs have to be connected, and for this a set of routines is provided, linked through a Real Time Data Base to the VFSM structure. This also deals with interconnections between VFSMs and with use of system resources such as timers. We believe that it is vital to separate the behavioral aspects of software from the detailed computations it carries out.

The designer constructs formal models of his system, using the StateWORKS tools such as VFSM Editor. These models are so designed as to be able to be directly executed by the StateWORKS Executor: a sort of virtual machine running in the system. Coding of the intricacies of behavior of software can in this way be avoided. Neither huge amounts of if, then, else, switch and other control statements, nor more formally arranged code expressing finite state machines, need be generated. An important aspect is that the models are “Platform Independent Models” which are exactly the same under test in the IDE and as loaded into the run-time system. There will, of course, be a need to write code in the conventional way for user interfaces, data analysis, special drivers etc. and this code is easily linked to the VFSM structure.

With StateWORKS come tools for testing designs, by manipulating the inputs and monitoring the results. Using these tools, test may be carried out to include all the obscure error paths which could be difficult to handle. This testing is easier to perform and to understand than conventional testing of code, on account of the way in which the environment can be manipulated in subtle fashion.

The complete StateWORKS package goes under the name “StateWORKS Studio” and comes with all the run-time system support software. It is available for various operating system environments, including Microsoft® Windows®, and various styles of UNIX™ and Linux. Versions are also available for smaller real-time operating systems, such as VxWORKS and O.S.E.

Using StateWORKS, it is possible to make huge improvements in productivity. Typically, a project requiring 5 programmers over 18 months could be done with 3 programmers over 15 months, and with much less after-delivery maintenance to be done. It has even been known for an expert to carry out a 6-month project within 3 weeks! One hears a lot about “code re-use” these days, but it is not always easy to do, as code is hard to fully understand. StateWORKS offers the possibility of “component re-use” on a large scale, as the VFSM models are well documented and easy to understand, by comparison with code of similar complexity. The full product is very complete, of course, and takes some time to fully understand: just the RTDB Class Library Manual has over 160 pages, but many users will not need to refer to it.

1.2 StateWORKS Studio Professional

This is the standard and very complete system, with the IDE for design and the Standard Executor for the target system. The Standard Executor includes the real-time-database, and a small API. library plus source code examples are included to make it easy to connect to other software.

In its normal off-the-shelf version it runs under Microsoft Windows 10/11, but versions for Linux or other Unix variants can be supplied. And of course variants for other real-time systems, are available on request.

1.3 StateWORKS Studio Basic

This is similar to Pro above but has a limited scope – design and run-time systems are limited to 300 “objects”. It is suitable for small systems, and is sold at a much lower price.

1.4 StateWORKS Studio LE

For evaluation purposes, for educational use, and for the design of very small systems in which a single VFSM is sufficient, a low cost version of StateWORKS Studio is available. This does include the Standard Executor for Microsoft Windows.

The main restriction is that the “Limited Edition” or LE version can only handle a single finite state machine (but it can display systems of VFSM if provided from another source): it does not deal with the “SMS Diagram”. Of course, the clever designer might find a way to use Studio LE to design a system with several VFSMs, by inventing means of interconnecting them. If you wish to do that: good luck! But try to follow the general guidelines we give for use of the full products, so that you can eventually upgrade and save a lot of hassle.

For practical reasons, StateWORKS Studio LE do not have specific documentation and Help files: the differences will be quite obvious when you use this product.

1.5 Run-time Systems

We recommend using the complete StateWORKS Executor products for general use in run-time systems. In many cases, you can use the Standard Executor, which is supplied with StateWORKS Studio, for this purpose. As mentioned earlier, the models produced by StateWORKS Studio can be executed directly, a feature that is primarily used for testing designs. When you test a design this way, it functions just as it would in the run-time system of a target computer, utilizing a special version of the StateWORKS RTDB (Real-Time Database).

Additionally, you have the option to work with our VFSM Run-Time Library. This can be an ideal solution for smaller systems where the RTDB might be too large to install conveniently or for scenarios where users prefer more direct control over execution.

Communication between various tools is managed through a TCP/IP interface. This interface allows, for example, a MS Windows computer to supervise a system running on a Linux computer. It can also be used in situations where an “Industrial PC” connects to its input-output units via a network using TCP/IP. For more details on this topic, contact us.

1.6 About this Document

It’s important to note that the example provided in this “Getting Started Guide” is primarily designed to help you become familiar with the development tools. It is not intended to fully showcase the benefits of StateWORKS. The example features a simple stream of numbers as input, with basic transition conditions and only a single finite state machine. In fact, traditional state machine design and programming methods described in various textbooks could be used for this project, as it represents a kind of “deterministic” state machine similar to those found in text parsing.

The process of specifying the “virtual environment” when designing a state machine and then defining the real environment in the project editor may feel cumbersome for newcomers. However, this approach is a crucial aspect of StateWORKS, allowing the same state machine to be reused across multiple projects with custom configurations for each case. This feature is one of the key factors that makes StateWORKS powerful in simplifying large and seemingly complex projects. We encourage you to invest the time to master its effective use.

1.7 Installation

The installer will have allowed various options for the directories. Normally, all the tools and associated help files are placed in the C:\Program Files\SW Software\StateWORKS Studio LE folder. Various project files are located in a Projects folder, and each project has its own directory. Note that VFSM designs are easily re-used, so these are always stored in the \projects\VFSM folder, rather than with the project(s) using them. On opening a project, you will be asked for the paths to the VFSM and UNIT folders holding files associated with it, if the project cannot locate them.

The installer should have set up the configuration data correctly for the “Tools” such as SWLab, SWMon, and SWQuickPro. Each tool needs to know the path for finding it, optionally a home directory, and for SWLab and SWQuickPro, the current project is normally selected by setting the Argument as $Project.

2. Starting up

2.1 Starting StateWORKS Studio

  1. Open the StateWORKS Studio editor:
    • Navigate through the Start → Programs menu, use a shortcut if available, or double-click SWStudio.exe in the appropriate directory.

2_1_starting

  1. The editor will open with a project called CombLock (unless you have worked on another project).
    • Close this project with Project → Close to start fresh.
    • If the VFSM window is open, close it as well.

2.2 The VFSM Editor

  1. Start a new VFSM design:
    • Go to File → New → VFSM File → Generic.
    • A new window titled VFSM1 will open (you can change the title later by selecting Save).
  2. Note that the menu items at the top of the Studio Editor will change depending on whether the Project window or the ST diagram is selected.
  3. Initially, the window contains:
    • A box labeled Always for technical reasons. You can use it to add comments about the design.
    • Double-click on the Always box to open a test window. Write a comment like "My first test" and close it.
      (The Always box allows for input events to trigger “Input Actions” unrelated to any state, which is occasionally useful. For example a VFSM could be a degenerate case with just a logical expression inside it, but you can ignore this for now.)
  4. The diagram shows one state, Init, which is the obligatory starting state for any VFSM.
    • Double-click on the Init state to open its state table.
    • As you explore the table, explanations for each section will be displayed.
    • The Init state cannot be removed, but it can be renamed.

2_2_VFSM_editor

3. Create a new project

3.1 The Combination Lock Project

This tutorial will guide you through creating a simple combination lock, illustrating key features of StateWORKS.

The combination lock is an electronic version of a common lock design used for safes and filing cabinets. Richard Feynman amusingly described its workings in his autobiography “Surely You Are Joking, Mr. Feynman?”, which he encountered while working at Los Alamos on the Manhattan Project.

The lock consists of a single knob with a scale from 0 to 100. The knob must be turned to a sequence of four positions, alternating directions, to open the door. For this example, the knob must first be turned “upwards” to the first number. As Feynman discovered, the lock allows for some tolerance (±2 steps from the correct position).

3.2 New project: a new Finite State machine

  1. Create a new project:
    • Go to File → New → Project.
    • Enter the project name "Comb_Lock2".
    • Ensure the project folder is created in the correct directory.
  2. Create a new VFSM file:
    • Go to File → New → VFSM file → Generic.
    • This will be the ST diagram for the CombLock2 VFSM.
  3. Design the finite state machine (which means inventing states and transitions between them):
    • Start by putting a few state symbols on the diagram: Double-click on a blank area to the right of the Init state symbol.
  4. A list “State Name Dictionary” opens:
    • The list only contains Init, which is greyed-out (cannot be removed).
    • Enter the name "Start" in the text box.
    • Click Append to add this state to the list.
  5. Click OK:
    • The new state Start will appear on the ST diagram. (The reason why a Start state is wanted will be made clear in a moment.)
    • Repeat this process to add states Number1, Number2, Number3, and Number4, one at a time.
  6. Arrange the states:
    • Move the state symbols around using the mouse to create a clear layout.

3_2_new_VFSM

3.3 Set up Virtual I/O for the state machine

Now we need to set up the transition equations. We will need to know the position of the big knob.

  1. Open the I/O Objects list by selecting Dictionary → I/O Object on the toolbar.
  2. From the Type drop-down list, select a NI object (Numerical Input).
  3. Set the ID name to "position" and the Description to "Knob".
  4. Click Add to include this object in the list.
  5. Keep the I/O Object Dictionary window open.

3_3_1_ni_object

Next, we set the knob positions for the four numbers using the SWIP object. The SWIP (switch-point) checks if a numeric value is “in range” (between the lower and upper limits).

  • Create 4 instances of SWIP:
    • Select SWIP as the Type.
    • Name it "pos1" and click Add.
    • Repeat for "pos2", "pos3", and "pos4".

3_3_2_swip_object

Now, configure each SWIP:

  1. Close the I/O Object Dictionary window and open the Input Name Dictionary by selecting Dictionary → Input on the toolbar.
  2. From the I/O object ID drop-down list, select pos1.
  3. Look at the Input Value drop-down list, which shows OFF, LOW, IN, and HIGH.
  4. Assign names for LOW, IN, and HIGH:
    • Select LOW and click the Input Name textbox, where a suggested name, "pos1_LOW", appears. Accept it and click Add.
    • Repeat this for IN and HIGH.
    • Do the same for pos2, pos3, and pos4.

Close the Input Name Dictionary window.

3_3_3_input

SWIP objects are initially disabled by default, so we need to create “Output Actions” to switch them on.

  1. Open Dictionary → Output.
  2. Select pos1, choose the value On, and accept the name pos1_On.
  3. Repeat this for pos2, pos3, and pos4.
  4. Click OK to save the list.

3_3_4_output

3.4 Complete the state transition diagram

Now we have enough of a “virtual input” structure to specify the state machine more completely. We will start by adding the five basic transitions for the correct opening of the lock.

  1. Right-click and hold on the Init state in the ST diagram, drag the cursor to the Start state, and release. This will create an arrow representing the state transition.
  2. A window will open to set the conditions for this transition. Select the “transition condition” zone to the right of the “Next state” zone, and the Next state is already marked “Start”.

3_4_1_transition_condition

  1. Click on A (for Always) on top of the input box to copy it as the transition condition.

3_4_2_input_name_list

  1. Add the following transitions:
    • From Start to Number1 using the condition pos1_IN.
    • From Number1 to Number2 using pos2_IN.
    • From Number2 to Number3 using pos3_IN.
    • From Number3 to Number4 using pos4_IN.

3_4_3_insert_name

Now the state machine should allow the lock to open by turning the knob to the correct four positions. Each time the knob reaches the next position, the state machine advances to the next state.

But, as designed, the lock could still open randomly! Let’s add transitions to handle incorrect movements:

  1. Add transitions back to Start for incorrect knob positions:
    • From Number1 to Start using the condition pos1_HIGH (This might have been given a Description e.g., “too far up”).
    • From Number2 to Start using pos2_LOW.
    • From Number3 to Start using pos3_HIGH.
    • From Number4 to Start using pos4_LOW.
  2. Adjust the transitions visually by dragging them with the mouse, making sure the diagram is tidy and clear.

3_4_5_complete_ST_diagram

Now we need to ensure the SWIPs are enabled when the VFSM starts:

  1. Open the table for the Init state and click into the “Exit Action” field.
  2. Add the following exit actions by double-clicking their names in the output list:
    • pos1_On, pos2_On, pos3_On, pos4_On

This ensures the SWIPs are activated when the VFSM begins. This is why the Start state was needed.

3_4_6_exit_action

Finally, let’s add output actions to unlock and lock the door:

  1. Open the I/O Object Dictionary from the toolbar (F5), and:
    • Select a DO (Digital Output) object, name it Unlock, describe it as Solenoid, and click Add.
    • Close the list using OK.

3_4_7_do_unlock

  1. Open the Output dictionary, select Unlock from the I/O Object list, and:
    • Set the output value to Low and name it Unlock_Low, then click Add.
    • Set the output value to High and name it Lock, then click Add.
    • Close the list using OK.

3_4_8_output_unlock

Now set up these actions in the state machine:

  1. Open the table for the Number4 state and add the Unlock_Low action in the Entry Action field (from the output name list to the right).

3_4_9_entry_action_number4

  1. Add the Lock action in the Entry Action field for the Start state, ensuring the safe can be locked again.

3_4_10_entry_action_start

Save your progress:

  1. Save your files using File → Save as…CombLock2. You will be prompted to enter a three-letter prefix for your VFSM. Accept the default and ensure VFSM designs are saved in a VFSM directory, with other files in the Project directory.

3.5 The Project Window

The objects which you created in the VFSM editor are “virtual” rather than real: the VFSM uses “object control properties” to define the virtual environment. Contrary to this, objects in the Project Window are specifications of real objects defining their properties. These real objects can be all handled by the Real-Time Data Base (RTDB), an essential part of the StateWORKS system. Virtual objects defined in the VFSM editor are linked to real RTDB objects in the Project Window. Any object defined in the VFSM editor may be linked with several incarnations of objects in the Project Manager. In a significant project, you might need to use half a dozen identical incarnations of the same state machine, with different properties set for each of them, in the project window.

Investigating the Project Window (all sorts of possible objects are listed here)

  1. In the Project Window, expand the VFSM section, and you’ll see the state machine Comb_lock2 that you designed.
  2. Select it and click New. This creates an instance called Comb_lock2:01, which we will keep as is for this project.

3_5_1_project_window

Adding Instances of I/O Objects

  1. In the Project Window, select an NI object from the Inputs group, and click New.
  2. Select a DO object from the Outputs group, and click New.
  3. Select SWIP from the Supervisory group, and click New four times to create four instances.

To view all the real objects in the project, select All types at the top of the left-hand list. You need to set up the properties of the various objects, and you will need to select physical objects for each of the virtual objects. In most cases there is only one name offered, and it should be selected.

3_5_2_project_window

Setting Object Properties

  1. Select the NI:01 object and open its properties in the right window:
    • Rename it to position.
    • Set the format to ushort, units to <none>, and scale mode to Lin.
  2. Select the DO:01 object:
    • Rename it to unlock.
    • Set the Invert option to true.
  3. For each SWIP object, configure it to supervise the “position” input: (In a real project we should set the combination as parameters which could be changed easily, but to simplify matters we shall set each limit value directly.)
    • For SWIP:01, set the low limit to 64 and the high limit to 68.
    • For the other three SWIP objects, set the limits as follows:
      • SWIP:02: 31-35
      • SWIP:03: 82-86
      • SWIP:04: 46-50

3_5_3_project_window

Handling the MyCmd Object

There is a minor issue with the default MyCmd object, which will signal an error if left as is. While the error can be ignored, it’s better to create a new Cmd object:

  1. In the Project Editor, select Cmd under the Interfaces section.
  2. Create a new Cmd object, name it "MyCmd", and set its type to CMD-IN.

Configuring NI and DO Units

Since the NI and DO objects correspond to physical input/output, additional configuration is needed:

  1. Go to Project → Edit → Add and add the files DO8.unt and NI4.unt from the UNIT/ directory.
  2. Open Unit in the Project Window, and create new NI4 and DO8 units, setting their properties:
    • Set the DO8:01 physical address to 3, and select unlock for Do0.
    • Set the NI4:01 physical address to 5, and select position for Ni0.

These steps will link your design to the physical input/output for testing using SWLab.

3_5_4_project_window

Linking Virtual and Real Objects

The final step is to link the virtual objects from the ST diagram to the real objects in the Project Window:

  1. In the Project Window, select the VFSM Comb_Lock2:01.
  2. You will see a list of used objects. For each, link the virtual object to a corresponding real object by selecting the name. For the SWIP objects, make sure to assign them correctly, as we have four.

While this process may seem tedious in this simple project, it provides flexibility in larger, more complex projects.

Building the Project

  • Once everything is linked, select Project → Build All. A list of errors may appear regarding unused inputs and outputs—just close it and ignore these errors.

3_5_5_project_window

3.6 Improve Security of the Lock

A little reflection can lead to ideas for improving the lock’s security. For example, the solenoid is currently activated immediately when Position 4 is reached, meaning that the lock can be opened without knowing the final setting. To improve this:

  • Add a short delay: Instead of immediately energizing the solenoid upon reaching Position 4, you can introduce a short delay and transition to a new state where the solenoid is activated. A transition to Start would occur if the knob is turned too far. You can experiment with the Timer object for this purpose.
  • New rule: After reaching Position 4, the user must turn the knob back slightly. To implement this:
    • Add a new state called Unlock which is reached from Position 4 when the condition pos4_HIGH is met.
    • Move the solenoid activation to this new state.

Another issue arises from examining the transitions. The transition from Start to Number1 occurs as soon as the SWIP senses the IN condition, regardless of direction. This flaw allows the lock to be opened without knowing the first setting—only the second setting is needed. To fix this:

  • Introduce a new state called Ready:
    • Insert the Ready state between Start and Number1
    • Set the transition from Start to Ready to occur only when the condition pos1_LOW is met.

The updated state transition diagram, incorporating these changes, is shown below:

3_6_improve_security_of_lock

Benefits of Diagram-Driven Design

At this point, you might begin to appreciate how discussing a state transition diagram (ST diagram) with a colleague can help you identify weaknesses in the design and fix them much more easily than starting with direct coding. While testing is still crucial, many issues can be spotted through close study of the ST diagram alone.

For example, although the lock might initially appear to have 100⁴ = 100 million combinations, Richard Feynman famously discovered that tolerances reduced this to 20⁴ = 160 thousand. Moreover, without fixing the issues detailed above, there are only about 400 combinations to try, starting at 100 for the first number and slowly turning the knob until the solenoid clicks on the fourth! A patient safecracker could work through this in just a few hours.

Enhancing Security Further

Once these flaws are addressed, you can enhance security by adding features such as:

  • Timeouts: Implement time-outs that make the state machine pause for a specified duration after a mistake.
  • Penalty delay: For example, a failed attempt could cause the state machine to remain in Start for 45 seconds or more before accepting new inputs from the knob, significantly hindering brute-force attempts.

3.7 Locking

In a real safe, it’s important to de-energize the solenoid after opening the door. While this can be done by turning the knob, a better approach would be to use a micro-switch that detects when the door is open. Once this switch is activated, the solenoid should be turned off, and the system should return to the Start state.

We can assume that the door locks mechanically by a latch. However, for additional security, a second solenoid could be activated for a couple of seconds to lock the door securely when it is closed. This is a design consideration that should be reviewed with your engineering team to ensure proper implementation.

3.8 Save and Check the Design

To finalize the design:

  • Save both the VFSM and the Project.
  • In the Project menu, select Build All to compile and check the design.

After the build process, an error window may open. Ideally, there will be no errors listed. This ensures that the necessary files for other tools are generated. The error window may also display some warnings, depending on the project settings. These warnings can be useful for identifying potential issues or optimization opportunities.

3.9 Note About this Example

This example is provided primarily to demonstrate how to use the StateWORKS IDE and is not representative of a typical StateWORKS project. Key differences include:

  • Single FSM: This example uses only one FSM. In real-world projects, the strength of StateWORKS is more apparent when handling 10 or more FSMs. Dividing the control behavior across multiple FSMs is more powerful for system implementation compared to techniques like StateCharts™, which treat groups of states as single states.
  • Simplified Input: The example uses only a single input object (the knob position). StateWORKS is capable of handling much more complex expressions for transitions or actions. This example doesn’t showcase that capability.
  • Event-driven design: This FSM could be “event-driven” which is a dangerous concept.

4. Testing

4.1 Start SWLab

If your design has no serious errors, the Build All command will generate the necessary project files for execution by the run-time system or for testing. To begin, navigate to the Tools menu and select SWLab. Once SWLab is open, your design will be running. You’ll be able to observe both the Unlock output and the position input.

4_1_start_swlab

Use the up/down arrows or double-click on the field to the left to enter a value.

4.2 Start SWMon

Next, open SWMon in a similar way (Tools → SWMon). A small TCP/IP setup window will appear. Accept the default settings for Host (LocalHost) and Port (59091), then click OK. This will bring up the Monitor window.

Initially, the monitor window may not show much. However, by selecting the VFSM icon, you can view a list of state machines in the system. Choose Comb_lock2:01 to monitor its current status and activities.

VFSM Icon: 4_2_0_vfsm_icon

4_2_1_start_swmon

For now, you can ignore the upper section of the window. In the lower section, you’ll see a list of objects, starting with the state machine itself. You will notice that the system is in the Start state, and not much is happening, as the NI position input is set to 2048 by SWLab.

4_2_2_start_swmon

To interact with the system, switch back to SWLab. Use the cursor or the up/down arrows to adjust the position setting, first to around 50, then to 68. Although adjusting the position can be a bit tricky, keep in mind that holding the Shift key will speed up the adjustments by a factor of 8, and the Control key by 64. Once the value is set to 68, the state machine will transition to Number1.

Continue the process by adjusting the position to 33, 84, and 48 sequentially to advance through the states. Upon reaching Position4, increase the value slightly to around 55 to transition to the Unlock state. At this point, the Unlock output will change from 1 to 0, which will drive the solenoid, as specified by the inversion set in the output driver for this function.

4.3 Use of SWQuickPro

While SWQuickPro is a powerful tool, it’s a bit too complex to cover in detail within this guide. However, it’s worth noting that it allows you to generate and use command file scripts for automating and repeating test sequences. You can easily try this testing facility by following these steps:

  • Start SWQuickPro (Tools → SWQuickPro).
  • Connect to SWLab by clicking the Connect button.
  • Load the command file CombLock.swc by clicking Load.
  • Execute the command file using the buttons NEXT, RUN, RUN Cont., and STOP.

If you are familiar with UML or Extreme Programming methodologies, you know that they stress regular testing of models or software to ensure correct functionality. StateWORKS Studio supports this by enabling automated testing, saving time and effort. You can create command scripts that define expected behaviors in the external environment and observe how the software responds. Whether you use prepared scripts or manually issue commands, you can complete a range of tests and save a log file as a record of the test results. Furthermore, this log file can be reused to create a new command script, allowing you to check that modifications to the design have not introduced any new issues.

While Use Cases often focus on “sunny-day scenarios” where everything functions smoothly, it’s critical to also test error scenarios—how the system handles unexpected or incorrect inputs. Testing error-handling can get quite complicated, and discussing your VFSM designs with colleagues can help identify possible flaws. These discussions are much easier when referencing a State Transition (ST) diagram than combing through traditional source code.

4_3_use_of_swquickpro

5. Results

5.1 Files Generated: Documentation

StateWORKS Studio provides two options for generating documentation: one for the text files and one for the state transition (ST) diagrams. You can print either of these to a file, just like any other document. If you have Acrobat Distiller installed, you can also generate .pdf files. The text file may include various elements such as the contents of your dictionaries and the state transition tables. Several options are available for what to include in the file. Don’t forget to add comments to your state transition tables, as they can be extremely helpful for understanding the project in the future.

5.2 Special Files Generated

Most of the files generated by the “Build” process are specialized for use by testing software and the various run-time systems. For instance, the .cpp file is used to create “C tables,” which are necessary for forming the Real-Time Database (RTBD) in systems where there is no disk drive. You typically won’t need to worry about these special files, as they are mainly for internal use by the system.

5.3 XML Import/Export

StateWORKS Studio exports designs in XML format when you use the Build command. This allows StateWORKS designs to be integrated with other tools or used alongside UML finite state machine specifications as the basis for more detailed VFSM implementations. You can view these XML files using a standard file explorer, and since DTD and XSL files are included, the XML can be displayed in a readable format. However, StateWORKS requires its own specific XML DTD due to its unique features. Full documentation for this is available on the StateWORKS website.

Future versions of StateWORKS Studio will also support XML import of designs and include other advanced features. Be sure to stay in touch so you can be notified about upcoming upgrades.

6. Systems of Multiple VFSMs

6.1 The Principles

While an ST diagram with 10 to 20 states is usually manageable, designs can become overly complex when accounting for all potential system problems, causing the number of states to grow beyond comprehension. The best way to handle this complexity is by splitting the design across several state machines, which work together. StateWORKS supports flexible arrangements for linking these state machines, though we recommend using a hierarchical structure. In a large system, you might need a hundred or more VFSMs across five or six levels—StateWORKS can easily handle this level of complexity.

At the top level, there are master state machines, with slaves beneath them. The masters issue commands to the slaves, while the slaves, visible to the masters, return information about their states. For more information, refer to Hierarchical systems of state machines.

6.2 Using the SMS Diagram

For designs involving multiple VFSMs, you can open the System of State Machines (SMS) diagram from the project window. This diagram displays each VFSM as a rectangle and illustrates the command links between them. To get a clearer understanding, we suggest opening the “gas” project from the Examples folder and reviewing the SMS diagram for that project. You can find more detailed information in the SMS section of the help file.

7. Run-Time Systems

The files generated by StateWORKS Studio fully define the behavior of each VFSM in your project, along with the input-output systems. These specifications are directly executable by the VFSM Standard Executor software module. The SWLab tool already includes a Real-Time Data Base and the VFSM Executor, making it a pre-built system. In principle, SWLab operates similarly to the run-time systems you would use for execution.

The Standard Executor can be implemented in various run-time environments. For instance, it can run on an Industrial PC, though with somewhat limited I/O options. However, it’s possible to connect external I/O units to the computer via TCP/IP networks or serial lines, for more advanced configurations.

We provide comprehensive tools and documentation to help you build custom systems with your own I/O drivers, integrated into the real-time database. Since the real-time database is highly adaptable, customized versions can be developed without difficulty.

Consult us for further details.

8. Final Remark

From here on, after following the guide for an hour or two, you should find that working with StateWORKS Studio is fairly obvious, and you should get up to speed quite soon.

Don’t hesitate to use the Help system. Further information and technical papers can be seen at our website.

If you are happy with the product, tell your colleagues and friends. If you have a problem, tell us! Perhaps there is a small misunderstanding or an error in the help files or other documents - give us a chance to fix it! Send an e-mail to [email protected] with your complaint quoting your user code number.

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