I received an email from John M. who is evaluating StateWORKS. He started with a fairly complex example that has confronted him with several issues that must be understood to use effectively our tools and the run-time system. Because of a general nature of his questions I put (with his acceptance) my answers into that blog.
Before I answer your questions I would like to make a general comment. There are two aspects of any method that uses a state machine concept. The first one is the specification, the second its implementation. Most methods are just limited to the specification. In that case the implementation is left to the user that interprets it on his own and completes the missing issues in the specification. After a while the specification looses its meaning and only the implementation (that is the code) counts. This rule is true not only for a state machine specification but defines a relation between any specification and implementation. We want to do it better in StateWORKS and provide a run-time system that executes the specification. The obvious consequences of our approach are:
- The specification must be complete as there is no chance to complete it in the code.
- While specifying we have to keep in mind the execution model.
The last problem should not be underestimated as you will see later when I answer your question.
Q1) The execution sequence of input actions in the current state is not ordered per 4th point in box at top of page 187. Fine. From page 199 : “ …. actions may change other control variables and in turn corresponding virtual inputs: all of them are treated 1-by-1 in the emerging sequence until all events are fully processed.” Does this imply that input actions in the present state may be executed iteratively? [Yes - order of consequent and causative input actions in StateA ST immaterial!] If an input action that was not due initially then becomes due after a subsequent due action is performed will it get executed? [Yes] The flowchart on page 186 implies not, I think.
A1. The first part of the book is about specification of a state machine and a system of state machines. We have tried to keep it implementation independent and therefore we have limited our consideration of the execution path to the flow chart represented on p.186. We need the flowcharts to explain the basic idea of multiple state transitions after a single events. Note that other implementations are imaginable and also available in StateWORKS (we can discuss it sometime later). The executor as implemented in RTDB has a queue (which is not shown on the flow chart) where events wait to be served. If the executor terminates serving of a given state machines (i.e. there are no transitions due) it returns on the flow chart to the point “wait for VI change”. The real executor checks whether the queue is empty and if not it takes the event from the queue and continues. In reality it is still more complex but I try in this moment just to explain the mechanism.
Q2. With multiple state transitions after a single VI event, the input actions of the intermediate states are ignored per 2nd point in box at top of page 187. Ok but what about those of the final state? [Also ignored.] If these simply do not get executed I have concerns that the vfsm will be left sitting in the final state when it may have already due input actions that would cause actions resulting in changed outputs or even further state changes. [True] Assuming such due input actions remained so, they’d then get executed when the next (unrelated?) VI event occurred – yes? [Yes – toggling the increment Cnt1 DI causes StateB to then trigger input actioned DO-HIGH showing Cnt2 over!] Possible alternative ………determining no immediate state transition is due defines the “final” state and then if the VI has changed since starting execution of the original current state this should be a “new” VI event causing any due input actions of the “final” (for now) state?
A2. Yes, by multiple transitions only the input actions in the starting state are performed. We are not able to distinguish between intermediate states and a final one. In event driven systems there is always a chance of “missing” trigger. We have to think about it while specifying the system. We should not overuse the input actions. The best state machines are of type Moore where the only actions are the entry actions. We pay for the simplicity with more states but avoid problems with input actions. Do not forget we are not building a hardware system where number of state does cost. In software minimizing the number of state is a rather irrelevant criteria; we should speak about optimizing the number of state, i. e. to have as many states as we need to make an understandable state machine.
Q3. Something that came up in my test : An entry action does ResetStart on a counter that was over. There is a transition action with condition same counter over – it gets triggered?
A3. If the counter is reset the control value OVER is replaced by RESET. Thus, any condition containing the RESET value could be triggered (but not the condition with OVER which is not present any more). This effect has come up because of the generation I have explained in my direct email to you discussing the details of your state transition diagram.
Q4. Lastly a probably silly question but just to make sure I’m not missing something ……. Is it true that there is no way to cause an external source input (DI, DAT, PAR, NI) to change other than to have the controlled system or the “user” do it or for an OFUN to do it (DAT I’d assume)? Don’t see a way to connect a controlled system input to one of it’s outputs in swLab or SwMon?
A4. There are 3 types of objects in the specification system (and consequently in RTDB): input, output and input/output type. An input type as for instance DI can be used as a condition to control a transition or an input action. An output type as for instance DO can be used to define an action to be performed. The input/output as for instance XDA can be used (with some restrictions) for both purposes.
Other issues seen in your first example:
- The use of Input actions should be limited to actions that can be repeated without any side effects. For instance setting a Do output several times does not do any harm. But incrementing a counter on a static control value (like Di) will in general result in erroneous behavior: if the Di value (which triggers the counter) stays HIGH any event triggers the execution of Input actions, i.e. the counter will increment. Any event causes execution of the state machine as shown in the flow chart.
- Due to multi state transition mechanism a not “consumed” transition condition may cause an unintended transition while returning to the initial state. This results in an infinite loop that is detected and terminated by the Executor but it is of course an erroneous, not intended behavior.
One Response to “Getting started”
Leave a Reply
You must be logged in to post a comment.