StateWORKS Newsletter 2/04
Topics:
- Welcome
- Standard I/O Unit with DLL
- XML Standard
- StateWORKS Studio Home and Programmers editions
- ECBS'04 Brno conference
1. Welcome
In the last weeks we have introduced several new items in the StateWORKS development and execution environment. We had been so busy that I had to delay the newsletter. Eventually, I am able to present you the results in one run.
- Our Standard Executor now includes the Standard IO-Unit which is a very important extension to the StateWORKS execution environment. See the technical note TN7-StandardlIOUnit.pdf on our web site.
- After a long development we present on our web site the VFSMML which is the XML mark-up language. See the document VFSMML.pdf on our web site.
- StateWORKS Studio version 5.2 is now available. It contains several visible and many more invisible improvements. You can get StateWORKS Studio now in several editions: Professional, Home and Programmers. The LE edition stays of course a free demo. Note that the version 6.2 of the LE edition requires a new key that you will receive on request from the CYDON distributor.
- We shall present a paper at the ECBS'04 conference - a preprint is already on our web site.
Regards
F. Wagner
2. Standard I/O Unit with DLL
The IO-interface problem is the key issue in using StateWORKS executor. The StateWORKS execution environment is meant as a framework for application development where the RTDB library is used to build an application. Our experience shows that most of the applications, especially in the embedded domain may be realized as a uniform input/output interface. The interface is in most cases limited to accessing D-A and A-D converters, i.e. numbers, and digital inputs and outputs, i.e. boolean values. Completing it with string (serial interface) and integer values for any special use we get an interface which covers many application domains.
These considerations have been the base of the Standard IO-Unit. The Standard IO-Unit handles a few commonly used interface objects and is built into the Standard Executor. The Standard IO-Unit works with DLLs which fulfill the interface definition. Details are covered in the Technical Note TN7-StandardlIOUnit.pdf on our web site. We believe that introduction of the Standard IO-Unit lower essentially the acceptance threshold of StateWORKS executor. Using the Standard IO-Unit the user is completely isolated from the RTDB details. Writing a DLL according to a predefined definition is a rather conventional programmer's task requiring no knowledge about the RTDB interface. We may on request supply in a very short time a version of the Standard IO-Unit which corresponds to specific user requirements.
3. XML Standard
A standard definition of control system behaviour keeps busy different forums and organisations. A concept of VFSM gives us the unique opportunity to realize it. The concept of a virtual environment and its implementation in the form of the StateWORKS RTDB is the base of the VFSMML standard which is the XML notation for state machines. It is an open standard not limited to StateWORKS. The only true feature that identifies its origin is the state machine execution model taken from StateWORKS. Anyway, the StateWORKS state machine model is nothing special - it is a model resulting from Automata Theory and it does not essentially influence the standard. It may be exchanged against any other model requiring some cosmetic changes to the standard definition. StateWORKS objects with their properties are used as examples and represent a base of possible objects which can be expanded or changed. The presented set of predefined objects is defined as a default one. By adding or changing the set of predefined VFSM anybody can generate his own version of predefined objects.
The standard has been implemented in the StateWORKS development environment. The StateWORKS Studio "building" operation automatically generates the XML file which you can display in your browser, using for instance our style sheet file vfsm.xsl. For validation of VFSMML documents we supply a DTD file vfsm.dtd.
The VFSMML notation opens the way for exchanging state machine specifications. At least, you may send the specification to your friend or boss who can display it using the browser instead of specialized tools. The other possibility is to exchange state machines for application development. Eventually, a state machine specification becomes a non-proprietary good!
4. StateWORKS Studio Home and Programmers editions
To lower the acceptance threshold we introduce in addition to the Professional and LE versions two new editions of StateWORKS Studio: Home and Programmers.
The Programmers edition is for programmers who want to use the StateWORKS Studio for specification only. In such a case they have a tool which allows them to specify and document the behavior of the designed control system (state machines). For some reasons they prefer or must code its implementation. This kind of specification does not require many object types. Therefore, the Programmers edition contains only four object types: CMD (command), XDA (number), VFSM (state machine) and CNT (counter). Experiences have shown that this set of object is sufficient for specification of state machines which are later coded.
The Home edition is for non-professional activities, for instance hobby or test. It contains an optimized set of objects and can be used for private purposes, but not to create software incorporated into commercial products.
The prices of these editions are provided corresponding to their usage.
5. ECBS'04 Brno conference
StateWORKS will be present also this year on the ECBS (Engineering of Computer-Based Systems) conference which takes place this year in Brno (24-26.May, 2004). We are glad to be again there and hope that with our contribution we realize also our aims of spreading the message of true executable specification possible with StateWORKS development and execution environment.