StateWORKS -> Publications -> Newsletter -> Terminal Client, Commands

StateWORKS Newsletter #4, 12.07.2003

Topics:
1. Introduction: State Machine Acceptance and the Testing Problem
2. Documentation: Terminal Client
3. Technical note: Commands
4. Example

1. Introduction: State Machine Acceptance and the Testing Problem

The rainy days in Northern Europe after the hot summer in June mobilize us to do some useful work before the true summer holidays. Hence, we have produced the next Newsletter introducing the Terminal Client as an alternative solution to SWMon. In addition, we have produced another technical note explaining the difficulty of using the CMD object and how we have solved it in the new version of StateWORKS development tools and run-time systems. But I begin with some general remarks about the difficulty of promoting state-machine based tools.

Seeing the obvious advantages of the state machine technique in situations where the application requires a non-trivial "control" I have tried to understand why it finds so little acceptance. Of course, there are many reasons (lack of knowledge, fascination with coding techniques and other "sociological" factors) but there is also a technical reason - the perceived difficulties of testing. It is a factor which is underestimated, but it is in my point of view the only serious argument which can be made against usage of state machines.

The potential testing problem increases if we work with a system of many state machines. In my experience these testing problems can be overcome and state machines used with success. (Frankly speaking, I have no idea how to replace a system of state machines with any other serious solution which is easier to test rigorously.) I believe that this point is very important for promotion of the wider use of state machine based software. We try to make StateWORKS development environment as testing-friendly as possible. The last version of SWMon has a debug mode to step through the state machine system (a step represents one transition). The new Terminal Client goes one step further allowing automation of testing procedures. In section 2 you find more about this useful feature.

Some writers use the term State Charts as being equivalent to state machines. This is not quite true. State machines were invented in Automata Theory about 50 years ago. State Charts were defined 20 years ago as an extension to the state machine concept. The differences are essential and begin with the definition of state, the most important being the hierarchical concept (using State Charts we "see" other state machines through a state). But, while state machines supply an abstract representation of a system in the real world, the concept of states within states does not correspond to any reality. Furthermore, State Charts, although a sophisticated concept, have one fatal weakness - they dictate, in principle, top-down detailed design of a control system. Unfortunately, the real world imposes bottom-up implementation of the design. The unpleasant side effect is that programmers who have tried and failed with State Charts are lost to the state machine concept - they assume that it can not work and they will achieve better results just by "free" programming.

Advocates of "Extreme Programming" have accepted the need for bottom-up implementation, and have proposed various measures to keep this under control, including the wide use of test cases, based on "user stories" for example. We accept the value of some of their concepts, and have taken steps to provide for automated testing of StateWORKS designs, using a form of scripting language, as described in the next section.

I wish you good weather and nice holidays. As our vacations are rather short in autumn we will represent you next version of StateWORKS development tools.

F. Wagner

2. Terminal Client

We have two basic variants of our run-time system: for Windows and UNIX. For the Windows version we have a monitor (SWMon) which allows displaying and changing of object properties in the data base. The problem of accessing the UNIX version is more complex, the question "for which UNIX" being the main obstacle.

Of course, we could always access RTDB from another Windows computer using SWMon (with the TCP/IP interface). This solution cannot be used for stand-alone UNIX computers. So, we have developed the Terminal Client which posses the full functionality of SWMon without the graphical interface, which is less important anyway in the UNIX world. The Terminal Client can be run from the command line on any Windows and Linux computer. Other flavors of UNIX may require specific versions to be built. The Terminal Client is in one respect more powerful than SWMon as it allows monitoring and testing to be automated: the commands can be logged and the log file can be used as a command file. The full description of the Terminal Client can be found on our web site in a section Papers / Documentation ( TerminalClient.pdf).

Using the TCP/IP interface the Terminal Client can run from the command line on any computer in a network but we envisage its main use on the same computer where the RTDB application is running. Of course, the automation of tests is interesting for any system.

3. Technical note

Since the beginning of StateWORKS development we have had controversial discussions about the life time of input signals. StateWORKS is driven by a virtual environment from inputs which may or may not be steady, and whose changes cause the real-time data base to produce events, but the input states are not lost in this process. Commands represented a significant problem as they often need to be treated as signals, and cleared when they have been acted upon. At last, we have solved this problem and the latest versions of StateWORKS development environment and the run-time system implement an extended CMD object. The technical note Commands explains the details of the solution and is provided as a PDF document on the StateWORKS web-page.

4. Example

The CMD_Example is provided on the StateWORKS web-page. It accompanies the above technical note. If you have bought the StateWORKS development tools you can run it using SWLab and using SWMon to send commands. As SWLab does not have a CMD input it does not make sense to run it without SWMon. Anyway you can study the specification which is enough as the example is rather a trivial one. The purpose of the example is to demonstrate the use of the Clear output function in a typical two-states repeat sequence with acknowledgement.