Actually, I want validation about execution order about HSM.
Are there true on picture, below?
I suppose the question is about the unique transition present in the diagrams
self transition
There is no transition to s2 so it is impossible to be in s2 when the transition occurs. The transition is external so s1ExitAction then T1TransAction then s1EnterAction
Supposing there is an additional initial pseudo state and a transition from it to s2 then the execution is the one you indicate.
If we are in s2 because of a hidden transition which is not from an hidden initial pseudo state then the execution is s2ExitAction then s1ExitAction then T1TransAction then s1EnterAction
external transition A
Supposing the transition occurs for at least the second time then the execution is the one you indicate, else the transition occurs when being in s1 and the execution is s1ExitAction then t1TransAction then s1EnterAction then s2EnterAction
local transition A
Supposing the transition occurs for at least the second time or we are in s2 because of a hidden transition then the execution is the one you indicate, else the transition occurs when being in s1 and the execution is t1TransAction then s2EnterAction
external transition B
There is no transition to s2 so it is impossible to be in s2 and then it is impossible to do the transition.
Supposing there is an additional initial pseudo state and a transition from it to s2 then the execution is the one you indicate.
If we are in s2 because of a hidden transition which is not from an hidden initial pseudo state then the execution is s2ExitAction then s1ExitAction then t1TransAction then s1EnterAction
local transition B
There is no transition to s2 so it is impossible to be in s2 and then it is impossible to do the transition.
Supposing there is an additional initial pseudo state and a transition from it to s2 or an hidden transition allowing to be in s2 then the execution is the one you indicate.
internal transition
There is no transition to s2 so it is impossible to be in s2 when the transition occurs, then the execution is t1TransAction
Supposing there is an additional initial pseudo state and a transition from it to s2 then the execution is the one you indicate.
If we are in s2 because of a hidden transition which is not from an hidden initial pseudo state then the execution is s2ExitAction then t1TransAction
Related
I'm just reading into the theory of state machines. Please consider this:
event[guard]/action
State A -----------------------------> State B
Here's my question: If I define a transition between states A and B, with event, guard, and action, like in the above "picture"; and furthermore the event is received and the guard expression evaluates to true, then: will the action be performed while my object is in state A, or B?
In other words, do I need the action to be configured to be performable in state A, or B (let's assume I want to choose only one state in which the action can be performed)?
Google finds tell me that the action will be performed at the exact time of transitioning; but my brain has problems to accept it: imo my object needs to be in a certain state while the action is being performed (just because my object needs to always be in a certain state). And the performing of the action may take a while.
Related: What happens if an error occurs during the performing of the action. Will my object stay in state A, or will it transition to state B anyways (remember that the event was received and the guard expression evaluated to true)?
This is fairly easy to check with a custom state machine listener, in which you override the corresponding methods for entering/exiting state and transitions.
will the action be performed while my object is in state A, or B?
Your action (which is on transition) will be performed while you're in state A.
The order of what happens is the following:
Started transition
State Entered: A
SM changed states from:null to: A
Ended transition
---
Executing guard logic
Started transition
Executing normal action //action is executed before exiting State A
State exited: A
State Entered: B
SM changed states from:A to: B
Ended transition
What happens if an error occurs during the performing of the action.
Will my object stay in state A, or will it transition to state B
anyways
You will stay in State A.
As you can see in the above output, the exit of the state happens after the action is executed (successfully). If an exception occurs before that you will still be in state A.
The action will be performed while your object is in state A.
If an error happens during action your state machine will not go to target state B and remain in state A. Additionally you can also define custom Action() for error scenario when actual action() throws exception.
In UML state machines, what exactly happens to the history of a composite state if a final state of a substate is entered?
Consider the state machine shown below. After the trigger sequence T1-T2-T3-T4 it will end up in the final state. By entering the final state the history of the region of State21 gets cleared, and since the region also gets completed by this, the completion transition to State1 will be executed. Now, when trigger T5 gets enabled, the state machine enters the deep history state. I suppose that in this situation the deep history state represents State21, which means the state machine enters State21 and then executes the transition from the initial pseudostate of State21 to State211. Is this correct?
I prefer the behavior described above, but I can see an alternative in which the history of State2 also gets cleared when the final state in State21 is entered. In that case the state machine executes the transition from the the initial pseudostate of State2 to to State22. So what do you think?
From my understanding of deepHistory description
This type of Pseudostate is a kind of variable that represents the most recent active state configuration of its owning Region. As explained above, a Transition terminating on this Pseudostate implies restoring the Region to that same state configuration, but with all the semantics of entering a State (see the Subclause describing State entry).
Your first behavior description seems to be the good one. By trigerring T1, T2, T3, T4, and T5 transitionns you are back to State21 entry i.e. State211.
I read this diagram in the following way:
While in State1 you can enter into State2 by calling T1 (which is a fresh sequence) or via T2 (a retry of the previous sequence).
When the application / system is in State1 it appears to have logic in it that allows for retrying a previous State2 sequence in certain situations. As such deep history keeps those process variables around in the parent state until State1 can make a decision on which way it wants to proceed.
However ambiguities exist in the example state machine model:
The transition back to State1 is not named/numbered, and
An intermediate partially complete state, that requires deep history, has not been defined. The model needs an exit state / criteria defined as a sub-state within State21 that serves as the source for this unnamed transition back to State1.
The current flow within State21 only has one end state and therefore runs to completion every time. Its only when you need to re-enter a state at a given sub-state location that deep history makes sense.
I am self-teaching myself VHDL, and took this answer's advice by starting with Frank Vahid's Digital Design (2nd edition).
On page 254 (link) he explains that updates to storage items occur on the next rising clock edge, therefore, at the end of a state's clock cycle. This is explained in figure 5.14 using the "Jreg" storage item, the behavior of which I understand.
What I don't understand, is why the storage item "P" behaves differently:
1) Its value is already known upon entering state S0 (whereas "Jreg" is not)
2) Upon transitioning to state S1, "P" immediately updates to the value given by state S1, whereas "Jreg" is not updated until the end of that clock cycle
Is there a difference between "Jreg" and "P" I'm not aware of? Is it an error in the example?
It appears that P is a combinational signal (not dependent on a clock) and that Jreg is sequential register (is dependent on a clock). Jreg appears to behave as a counter (which requires a clock or drive signal of some sort). The example says that the machine waits for an input signal B to go high and once it does, it sets output P high. Then, using Jreg to count the number of clock cycles passed since B went high, it holds P high until Jreg counts to a certain number of clock cycles (2) at which point both Jreg and P are reset to 0.
1) Jreg is unknown at the start and most likely so is P, however P does not have to wait for a clock tick because its a combinational signal.
2) Again Jreg is sequential so it must wait for a clock tick to change its state.
Please explain to me if I get right the meaning of these 3 state machines.
1, StateA Enter action is called (which is nothing at the moment) and then the timer is set up. When the timer triggers Acion1 is executed, then the StateA Exit action (also nothing) is executed, then the whole loop repeats. So StateA Enter action, setting up the timer, etc. This makes a kind of polling with Action1
2, StateB Enter action is called, timer set up and triggers after 10ms and executes Action2. The timer will be not renewed, so it is a kind of delayed action on the state
3, StateC Enter action, Timer is set up, when triggers then Action3 is called, then StateC Exit action and finally StateD Enter action is executed.
Please confirm or correct if it is correct.
1: Your description is correct, with one exception: the exit action is executed before Action1 is executed, at least, that is how I interpret the UML 2.5 spec. Section 14.2.3.4.6 says:
If the composite State has an exit Behavior defined, it is executed (...) before any effect Behavior of the outgoing external Transition.
I think you can safely assume that this is also true for non-composite states, but the UML 2.5 spec should be more explicit in this respect.
2: I don't think this is a proper UML notation, so I cannot confirm or deny your description.
3: This state machine diagram does not specify whether the initial state is StateC or StateD. If it is StateC, then your description is correct, with the exception that StateC's exit action is executed before Action3. To be unambiguous, the diagram should have an initial pseudostate (filled circle) with a transition from the initial pseudostate to StateC.
Generally states are drawn with rounded rect.
1) The notation along the transition is <trigger>/<effect>. The semantics of After(10) leaves some room for interpretation. So when the <trigger> fires it will perform <effect> and return to the same state.
2) I don't know this notation. You can specify entry/do/exit operations like this
3) Is like 1 but enters a new state.
The scenario:
I have a simple state machine:
Happy path:
Uninitialized->Initialized->InProgress->Done
Unhappy path:
Uninitialized->Initialized->Error
Simply put, I need to cause a transition (either into InProgress or in Error state) without an external event/trigger. I.e. Initialized state should immediately result in one of those states.
Questions:
Is it OK to cause state transition from within Initialized.Enter() ?
I could use state guards to do this, but I'd rather not have non-trivial logic in the state guard (and initialization can very well be complex).
If it is NOT OK, how can I do it differently?
Should I just take this decision out of he FSM all together and have some other component cause the appropriate transition? But then, wouldn't I still have to call that external component from within Initialized.Enter() ? so it solves nothing?
In a state machine, next state is a combinatorial logic function of both input and current state.
In the case you are describing, the same cause (Initialized state) seems to be able to trigger two different effects (either InProgress or Error state). I guess that there is a hidden input whose value makes the difference. I also guess that this input is received during transition from Uninitialized to Initialized.
Therefore I would have a different model:
Uninitialized -> Successfully initialized -> InProgress -> Done
\
`-> Failed Initialization -> Error
Possibly combining Successfully initialized with InProgress and Failed initialization with Error.
EDIT: From your comment, I understand that the hidden input actually is the result of an action (a device initialization). Taking your model, I assume that initialization takes place while in Initialized state (let's call it Initializing). This way, the result from the device is your external event which will trigger transition either to InProgress or to Error.
So keep your state machine and simply add the result of device.Initialize() to the list of inputs or external events.