I know that in FSM, state transition occurs when input changes. But is it possible to receive input when state is changing from one to another?
State changes are considered atomic, so (effectively) nothing happens during the transition.
Related
I have a state machine diagram for an application that has a UI and a thread that runs parallel. I model this using a state with 2 parallel regions. Now I want when that thread gives some message, for example an error, that the state of the UI changes, for example to an error screen state.
I was wondering what the correct method to do this is, as I was not able to find any example of this situation online.
The options that I thought of were creating a transition from every state to this error state when the error state is called, which in a big diagram would mean a lot of transitions. Or by just creating a transition from the thread to the error state (As shown in the image), which could possible be unclear.
Example of second option
You don't need a transition from every state. Just use a transition from the State State to the Error window state. It will then fire no matter what states are currently active.
Such a transition will also leave the Some process state. Since you didn't define initial states in the orthogonal regions, the right region of the state machine will then be in an undefined state. Some people allow this to happen, but for me it is not good practice. So, I suggest to add initial states to both regions. Then it is clear, which sub state will become active, when the State state is entered for any reason. The fork would also not be necessary then.
How you have done it in your example would also be Ok. However, since the Some process state is left by this transition, this region is now in an undefined state. Again, the solution to this is to have an initial state here. I would only use such a transition between regions, when it contains more than one state and the On error event shall not trigger a transition in all of the states.
If the Some process state is only there to allow for concurrent execution, there is an easier way to achieve this: The State state can have a do behavior, that is running while the sub states are active. Orthogonal regions should be used wisely, since they add a lot complexity.
I do not know if there is a good way to represent this in a UML2 statechart diagram.
Given a set of states, State 1, State 2, State 3, and State 4. Given a set of events, Event 2, Event 3, and Event 4.
States have a relative priority indicated by the State number. A higher number is higher priority. Receiving an event with a number that matches the state number toggles if that state is potentially active. Given that State 1 is a default priority, there is no event to toggle this priority.
So, for the following sequence of events I would expect the following transition:
State machine initialization -> Enter State 1
Event 2 -> State 2 becomes potentially active. Transition from State 1 to State 2.
Event 4 -> State 4 becomes potentially active. Transition from State 2 to State 4.
Event 3 -> State 3 becomes potentially active. No transition.
Event 4 -> State 4 leaves potentially active. Transition from State 4 to State 3.
Event 2 -> State 2 leaves potentially active. No transition.
Event 3 -> State 3 leaves potentially active. Transition from State 3 to State 1.
The only way that I can think of to diagram this as a statechart is to have an orthogonal state. One side captures events to determine if each state is potentially active. The other side would have to transition based on the current set of states in the first side. This seems pretty ugly and confusing.
Is there a good way to represent this in a UML2 statchart diagram?
Well, it can be done with orthogonal states. However, as you say, it's pretty ugly. First of all, modeling a simple boolean variable with an orthogonal region and two states is really overkill (maybe you didn't plan to do that, but I have seen it many times). And secondly, because the selection of the right state is actually an algorithm and an activity diagram suites this much better.
So my solution looks like this:
The internal transitions in state 3 and 4 just consume the event without doing anything, thereby preventing that the state is left and reentered unnecessarily.
I think the interesting part of this model will be how the behavior differs in the different states. By moving the selection of the state into another diagram, these two concerns are nicely separated.
I have a basic question about FIFO.
There are EMPTY and FULL flag behaviors corresponding to empty and full state of FiFo. About full state of FiFo, I can understand why it is bad for design because Fifo will not accept any coming data after full flag is asserted.
But about the EMPTY state, does it have any bad effects ? Because I see that when FiFo is empty, it still receive any coming data.
In certain cases EMPTY can be just as detrimental as the FIFO being full. Say you have a constant data rate to maintain and you need to be aware and send an error if you have ran out of data. The empty flag would be a way to indicate this. PCIe/USB and various other protocols use an Elastic Buffer which is essentially a FIFO with some additional logic. In this case, empty or full is basically the same error (data is invalid this cycle).
Whether or not EMPTY (or full even) is a good or bad condition is dependent on your application.
I'm using a finite state machine to control the voltage of power supply.
I've three states programmed:
OFF
ON
Stop
OFF state: the output voltage is 0V, the microcontroller is waiting for an input if there is no input it remains in the same state.
ON state: In this state the output voltage will increase progressively until it reaches some preset value if this value is reached the power supply will turn off. From this state the power supply can also change to Stop or to OFF if the proper signal is received
Stop: In this state, the output voltage will reaming constant at the last reached in the ON state. From this state, the power supply can return to ON and continue increasing the output or go to OFF.
My concern is the following, while in the ON state if the voltage limit is reached the state won't change immediately, the output will remain constant for a time delta_t, and then it will go to OFF I'm already implementing that behavior in the ON state, should I add a different state for this time for this transition when the voltage isn't increasing? or it is correct to have the delay within the state? This new state will basically just be a delay.
Edit.
This is the ideal output when the power supply is in ON state, It starts at 0, the increase until it reaches a preset value, remains in this value for a given time and the it goes to OFF state.
I've put current instead off voltage in this image, but since the load is pure resistive it makes no difference.
If the voltage plateau is an intended behavior (i.e. you have instantaneous control over the voltage, and your state machine is deliberately holding it high): It could make sense to split the 'ON' state into separate 'RAMP' and 'HOLD' states.
If the voltage plateau is a consequence of external hardware (e.g. your state machine stops sending the 'on' signal, but there's some delay before the actual behavior of the system catches up: It could make sense to add a separate 'WAIT' state, which either waits for a fixed time (if the delay is very repeatable), or operates in closed-loop fashion (e.g. measure the voltage, stay in 'WAIT' while it's nonzero, then transition to 'OFF').
In either case, it seems like the system is doing something different than during the voltage ramping phase, so a separate state makes sense.
As a newbie am trying to develop a state machine using Visio for a cd writer. below are the device operations/transactions and attached, is a diagram of what I've done so far, am unsure if its accurately represented.
Device operation
Load button- causes the drawer to open and to shut if open(load an empty cdr)
Burn button- starts recording document on the cdr, green light comes on in the burning process
and goes off when completed. Once cdr is burned writer stops.
Verify button- verifies the document previously recorded on the cdr, green light comes on in the
process and goes off when completed, then device stops
Cancel button- stops process anytime during recording or verifying
Cancel button- no effect if cd writer is empty or not busy verifying or recording When powered up- CD Writer will ensure the drawer is closed
Burn button – has no effect when cd writer is empty and during recording or verifying process.
Verifying can only be started when the CD Writer is not busy recording.
Visually your diagram looks like a state machine and states have good-sounding names - it's a good start. :)
The first issue I see there is the transition specification. It is definitelly not correct. State transitions in UML are specify in the folowing format:
event [guard] /action
where:
event (or trigger) is an external on internal "signal" that starts the transition. It can be a button activated by a user, an elapsed timer, a detected error, etc. It can even be omitted.
guard is a logical condition that should be fulfilled in order to start the transition. It is usually an expression returning a boolean value of tru or false. It can also be omitted.
action is a kind of side-effect, something that is executed when the transition is triggered. Ic can also be omitted.
Getting back to your diagram I would say that...
most of the labels on your transitions should not carrry "/" as it indicates an action. There are mostly manual triggers, like "load" (pressing the button to open the drawer), "Cancel", "butn", etc.
Consider some events that are triggered internally, like "burning done", or "CD loaded"
You can add some guard conditions in the situations where possible
I would remove all the triggers with no effect (like cancel with no CD in). It makes the diagram simplier with no loss of information
States LOADED and IDLE in your case are kind of strange, weak. It is not clear what makes them different (see the example below)
Here is a diagram that I find a bit more acurate (see notes for additional comments):
You need to specify explicit events as triggers of the transitions.
In the current state machine, each transition (except the one leaving the initial vertex) has an effect, but not a trigger. More accurately, they are triggered by the default completion event, and are therefore automatic.
Moreover, since all transitions react to the same event, your state machine is non-deterministic. For instance, in the state loaded, the transitions to Recording, empty, and loaded all react to the completion event. When the completion event is dispatched, these transitions are said to be conflicting, and one of them is selected non-deterministically. I am sure this is no what you want.
Read the UML Specification, and define triggers for your transitions.
You don't need to depict the transitions from "empty" to "empty" as transitions without any actions or state transitions would not need to be drawn in the Statemachine diagrams. (State Transition tables are often used for the checks of any missing transitions for such cases.)
"loaded" and "Idle" can be represented in one as a same state
To represent the "green light", I would write "turn on the green light" as entry action in Recording and "turn off the green light" as exit
Here's the diagram I drew. The status of tray (whether its opened or closed) should be considered in the actual model, but its not on my sample diagram below.