[SCXML] Feedback

Hello,

The company I work for uses state machine in most embedded systems.
That a single embedded device contains 1000 states is not uncommon. The
software we used for modeling, uses a closed (inferior) implementation
and therefore we seek better ideas. The document asks for feedback at
different locations. Here is my attempt:

3.1

The "scxml" element shares some properties with the "state" element.
But "scxml" allows no transitions. Implementations have to handle them
differently. Later I will show that based on the pseudo code, a fake
transition in the root element can be useful. The "scxml" element
should be a "state" element, or the "scxml" is stripped down to a bare
minimum (no "parallel" element e.g.).

3.3.3

I like to highlight the following sentence: "If the event clause is
missing, the transition is taken whenever the cond evaluates to true".
There is no hint that the transition is only taken, if there is a new
external event. But the pseudo code does not behave this way, because
the whole machine is blocked until a new external event arrives. The
problem is that there is possibility that the datamodel is changed
externally. If there is need to add tons of events just to update the
datamodel, that is a bit cumbersome. If I have to do this, I preferably
add them to the root element, but as written above the "scxml" does not
allow transitions and therefore I have to introduce a single state. I
will try to show that the sentence here is desirable, and the pseudo
code should be changed (see B).

I have to admit that I do not understand which chapter you mean with
"Such a transition is equivalent to an event handler in Harel State
Table notation". I see a problem how to graphically draw the different
possibilities, transitions without a target, and transitions whose
target is the source state. Maybe it would be a nice idea, if you add
some images how such different behavior should be displayed (I
understand that this may open Pandoras box).

3.14

The form "error.*" is more clear. Remove the first form "error". This
additional 2 characters are not worth it and it simplifies
implementations somewhat because they do not have to handle two
different cases.

A.1

The "Executable Content" allows a "script" element. "foreach",
"while", ... are no problem with a scipt. The same is true for "if",
"else" and "then". Is do not see good reason to implement a whole
scripting language that is written in XML. Maybe that should be another
project and SCXML allows the use of such W3C defined XML scripts.

A.2

The current naming convention is ok. If there are more software tools
available to visually show state machines, I does not matter anymore.
But implementations have problems with words like "if", because this
often are keywords.

A.5

In all our state machines the "delay" attribute is so widely used, that
"raise" is often neglected.

B

First some simpler things:

Datatypes:

tail is not defined here, and not what I expected while reading it
first. According to the implementation it is more something like Lisps
car/cdr or Pythons list[0] and list[1:]. On the other hand, head and
tail are not useful. They are used only in findLCA, but every function
that calls findLCA has first to merge two lists. Operations and
definitions that are superfluous. If findLCA accepts two parameters
(e.g. first and rest) things get simpler.

Global Variables:

Assign them at least once, so the datatype is known.

Predicates:

Could be easily written as pseudo code like the rest of the chapter. No
need for prose here.

procedure interpret

Maybe the datamodel should be explained a bit better. E.g. "doc" is not
explained in more detail, and why it does not correspond to the name
attribute of the SCXML element.

procedure exitInterpreter

Missing pseudo code for sendDoneEventToParent().

procedure enterStates

Missing pseudo code for getChildStates(). Used in other
procedures/functions as well.

function findLCA

getProperAncestors could be written as peudo code. No need for prose.

There are as well some missing characters in the pseucode (e.g.
isPreempted has a missing) but I guess they get fixed anyway. While I
appreciate that the whole document is very readable, the pseudo code
seems unfinished/unpolished. The pseudo code looks so Python-like
(indentation, colons, ...) that one may ask why you not append a Python
implementation.

But there is something else, I think has a somewhat bigger implication:
The external queue is blocking. What are the drawbacks:

- If the datamodel is updated externally the state machine is not
updated.

A good SCXML implementation would parse all script elements and add
dependency graph to every script element. If variable X is updated the
implementation could check all event-less transition for the X
variable. Are more simpler implementation could just check all
event-less transitions. No need to add tons of transitions just to
import values from the external world to the internal datamodel.

- The application must be multithreaded (or multiple processes),
although there is no need for that.

The pseudo code should just provide a method to handle one external
event. How the external queue is implemented is up to the implementer.
If he likes to block, it is possible as well. But for the definition
here the external queue should share the same implementation as the
internal queue.

It is also a valid idea to sort the external queue based on some
priorities (In fact the implementation we used before, allowed this, it
is not my idea). While the raise element may have a well defined order,
this may not be the case for the send element (and may distinguish the
two elements better).

E

It would be nice to show the examples visually as well.

But the biggest problem here is, that there is no defined way, how this
state machines should behave. If every transition, onentry and onexit
(or more generally each element that may contain executable content)
element would contain a log (with a unique output string) element. It
would be possible to test my own implementation against the examples
and compare the log output.

The SCXML standard is easy enough to grasp that a I do not need tons of
examples just to understand it better, but a well defined way to test
an implementation IMHO more important than the pseudo code.

Additions

In a possible future state charts are displayed graphically I guess.
This opens lots of possibilities and, unfortunately, for incompatible
standards.

A simpler problem is, how to store location, size of the states.
Something that is maybe more useful is the following:

Harel State Charts include a possibility to minimize the number of
arrows. See Fig. 17 in the original paper. While it is only different
way to represent things it also avoids (possibly faulty) repetition.
The same is true for the later mentioned conditional entrances.


Some ideas may be usefull, others useless, but what I am really missing
is a defined way to test an implementation.

Thomas Stauffer



Note:
This e-mail is for the named person's use only. It may contain confidential and/or privileged information. If you have received this e-mail in error, please notify the sender immediately and delete the material from any system. Any unauthorized copying, disclosure, distribution or other use of this information by persons or entities other than the intended recipient is prohibited.
Thank You.

Received on Monday, 20 September 2010 07:09:56 UTC