Skip to content

What is StateWORKS

just another tool to model a state machine and produce code.

Several tools on the market allow the development of state machine software. They use incomplete state transition tables and are not able to offer a standard solution for a system of state machines. The run-time system must be coded.

Tools on the market describe the behavior of a state machine in terms of events that trigger an action and/or a state transition. Representative of this way of reasoning is the state transition table in the form:

transition_table

Common state transition table

The table reads: if the state machine is in state here and receives event1, it performs this and transitions to the state there. Unfortunately, real control tasks are more complex, and the actions to be performed, as well as the transition conditions, are generally more involved. For example, the event might be “key pressed”, but its effects will depend on “which key?” and whether the system is enabled. Therefore, the action and the next state require footnotes (1 and 2 in the example), where the full details are described (the complete conditions are defined). Input events are often only relevant to a single state transition vector, so the table ends up having many rows. Of course, this kind of table must be coded; there is no way to translate it into a pure software table.

These tools model state machines, but not the entire software. Therefore, the code they produce is just a piece of software in the form of a function that must be integrated into another program.

A non-trivial control system application requires more than one state machine. These tools do not offer a complete solution for a system of state machines but leave it to the programmer to connect several state machines using events and messages—in other words, the programmer must make it work through additional coding.

a development environment to specify a system of state machines and an execution environment to run the specified system. StateWORKS does not produce code.

StateWORKS has both a development environment and a run-time system. The designer specifies the behavior of a system using the development environment. The run-time system is a ready-to-use program that performs control as specified by the StateWORKS editor. Any remaining coding is limited to I/O and user interface functions.

By using the concept of a virtual environment (VFSM) and the rules of logic algebra, completed by a complement value, the StateWORKS editor allows you to fully specify the behavior of a state machine as a formal model (without footnotes).

The VFSM concept is based on a complete separation between data and control flow. This means that a system of state machines specified in StateWORKS uses only control flow (no data flow). This, in turn, permits the definition of a standard Master/Slave interface between state machines. Using this interface, the StateWORKS editor allows you to specify a system of state machines using terms such as commands and states. Programming language concepts such as events, messages, semaphores, etc., are not part of the StateWORKS state machine specification, but belong only to the external software handling I/O, communications, and similar tasks.

The specification of the state machines’ behavior and of the overall system is executed by a standard program (run-time system), which loads the specification results at startup and controls the application.

The run-time system is a fixed, ready-to-use program that often requires the addition of I/O and user interface software. The rules for writing I/O and user interface software are defined by a TCP/IP interface and/or the StateWORKS I/O library functions, depending on the project’s requirements.

Some products use the term “executable model” to refer to a model that can be tested by means of an interpreter in simulation runs. StateWORKS also provides this capability, but with a crucial difference: execution takes place efficiently in the run-time system, not merely for testing purposes.

There are vital differences between StateWORKS and other “similar” approaches. The similarity is limited to the names: State and State Machine. StateWORKS is not merely a simple software development tool.

  • StateWORKS provides a run-time system for controlling an embedded application.
  • StateWORKS is a true implementation of a run-time-executable specification.