General FAQ

Where do you produce code?

StateWORKS does not produce code for state machines in the common sense of the word, as there is no need for it. StateWORKS generates specification “code” as data files that can be directly (and very efficiently) processed by the executor without any additional “manual” handling.

A project is built by means of the StateWORKS Library (RTDB Class Library) in any of several possible C++ development systems. In this way, the software for the rest of the system—input/output handlers, user interfaces, communication links, etc.—is added to the project.

The specification for systems of state machines of any degree of complexity is introduced into the run-time system as a C++ file. This specification, as designed and tested in the StateWORKS Studio development environment, is always complete, i.e. it is a part of the final executable application. During system testing and validation, if the effects of changes in the state machines need to be tried efficiently, an alternative approach is to reload the specification file from disk on each restart. This avoids repeating the build process for each small change, such as a revised timer setting.

What if we do not have a precise, written specification?

This is a common situation in real life. One of the really powerful and useful features of the StateWORKS development process is that the system designer is forced to make a completely specified system: there is no coding process where details can be fixed later. In fact, the designer will not first make a complete specification and then apply StateWORKS; they will use the StateWORKS IDE as an interactive tool, whereby all areas of missing information are revealed and must be resolved, usually in close interaction with the customer. Some projects done in this way have been claimed to be impossible to complete without using this powerful tool.

What are the most appropriate sorts of projects for StateWORKS?

A very wide variety. Industrial processes are a prime category, particularly when a series of complex operations must be applied to a number of batches, as in semiconductor production. Embedded systems in instruments and measuring equipment are other examples.

Another area of application is in communications, networks, and telephony, where numerous and often complex protocols are usually specified in terms of finite state machines.

Software for safety-critical systems, such as in transportation, could advantageously use StateWORKS. There are a number of methods for checking the validity of formal specifications, as expressed as Petri nets, state machines, or otherwise, and such specifications can be easily coded into the StateWORKS format.

Unlike some software tools that have been well publicized, StateWORKS is very well suited to the largest and most complex systems. One of the first—and highly successful—projects using this technology was implemented on ten D.E.C. VAXeln computers, networked as a system of 400 finite state machines as early as 1990. StateWORKS in its present form can be used to automate complete production lines of any size.

How is StateWORKS software tested?

The StateWORKS Studio development environment provides a simple tool, “SWLab”, which exercises the specification. With this, one uses a monitor such as “SWMon” to observe items of interest and to stimulate the system with artificial inputs. A second monitor, “SWQuickPro”, is available, which can record test sequences and save them for reuse later, to be run automatically. It can also process lists of such recorded tests, which is useful when making changes to a project to confirm the absence of unwanted side effects.

StateWORKS needs to be learned, so would one really save time?

Yes, there is a new process to learn. Many of its basic elements ought to be mastered, in any case, by a software designer. A couple of weeks of study should be enough to understand StateWORKS well enough to apply it.

Then, productivity rises by at least 30%, and in some cases by a factor of up to 3, depending on the project and the amount of conventional coding needed for various algorithmic functions that do not govern the program structure.

After that, you will see the benefits of a real engineering approach when the new system is first installed and tested on the target embedded-system hardware. The usual bug-hunting phase is drastically reduced. And, of course, as the program structure is accurately documented in the state diagrams, rather than in C++ code, “maintenance” is almost eliminated, and changes can be implemented to meet new requirements in a straightforward way.

After completing a couple of projects, you will discover that a software project can be planned and managed similarly to other engineering projects. It still takes a lot of work to implement, but it does not depend on one or two “gurus” who can churn out good code at high speed. Furthermore, the end user can be brought into the process and consulted about finer details. Using SASD (Structured Analysis, Structured Design), for example, the end user and managers tend to be presented with a very simple top-level model, but all the details are hidden from them until the beta-test stage.

There must be some problems, surely?

Yes, but they are not technical, but rather cultural. Programmers often enjoy the intellectual effort of trying to understand complex programs, making patches, and gradually eliminating obvious bugs. They may dislike having to “fill out forms” instead. Today’s software industry places far too much emphasis on coding as a valuable and skilled activity, and insufficient emphasis on analyzing system requirements, followed by synthesizing a suitable model in an abstract (i.e. not coded and not assuming a coding method) form, which is then validated and simulated.

This erroneous approach is propagated by much information-technology education, where a real education in basic concepts is replaced by training in fashionable tools of the day. Convincing potential users can, of course, be difficult. They may have been exposed to many promising tools that never fulfilled their early expectations, and therefore may be reluctant to explore StateWORKS. They may assume their project is not suitable, or that StateWORKS can only be used for completely new projects rather than developing parts of existing systems. They may claim that StateWORKS is nothing new, citing SDL or UML as examples. All these claims have been proven false, for example at the Lucent (Bell Labs) development center for the 5ESS telephony switching systems, where an early version of VFSM was introduced.

Have you found a “silver bullet” solving all software problems?

Not at all. Difficult problems cannot be simplified. If the control problem is complex, the corresponding state machines—or system of state machines—will also be complex. However, the StateWORKS solution will be better than any coded version: it requires less effort, is better documented, and allows you to achieve your goal without exceeding the planned timetable and financial resources.

You seem to be able to do just about anything with StateWORKS! Can it be true?

Just try it out on a small project or a large one, and you will be pleasantly surprised.