I have a simple state machine like the above. As far as, I looked over the online resources (example - x-sate) the state machine could have three different things "State", "Action Or Event" and "Side effect".
So Basically the event comes from outside of the state machine like User clicks, Reboot triggered etc., and the state machine should change its state based on those events. Also, each state could perform some side effects, but the side effect should not affect the state machine (for example, perform a cleanup task before Reboot)
Questions:
Is it allowed for a state to perform some operations(side effects) which could change the state of the state machine(fetch A, B, C in the above diagram) without any external event or action?
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.
My system has two state machines, one master, one slave. And the states between the master and the slave are not one to one. The possible interactions are as follows.
If the master transits to certain master state, it will notify the slave to transit to certain slave state
The slave may request the master to enter certain master state; if master succeeds, the master will notify the slave to enter certain slave state.
The slave may request certain data from master
What is the proper UML diagram to describe those interactions? Statechart diagram is limited to state transition only and can't describe the request from the slave(either state transition or data); Interaction diagram is limited to class/object and can't applied on state.
You can describe those interactions using two UML state machine diagrams, one for the master and one for the slave. For example, to specify that a transition from state Idle to state Busy of the slave takes place upon receipt of signal Req from master, you draw a transition from Idle to Busy with transition label Req in the slave's state machine diagram. To specify that master sends signal Req when it enters state X, you write entry/Req inside the state symbol of X in the master's state machine diagram.
Alternatively, you may draw elements for sending and receiving signals (see sections 14.2.4.8.2 to 14.2.4.8.5 of UML 2.5.1 specification):
For example, to go from Idle to Busy upon receipt of signal Req with parameter id:
You also described the situation where the slave requests certain data from the master. For this, you need a third diagram (or a textual specification) of the interface provided by the master and required by the slave, for example:
In the slave's state machine diagram, you can call an operation defined in the interface. For example, to call the read operation of master when the slave enters state Busy and store it in local variable x, write entry/x:=master.read() inside the state symbol X.
For an introduction to the UML state machine diagram, please refer to wikipedia
What you describe is the interaction between the master and the slave.
There is no single solution to that and it is really difficult to have at the same picture both all possible states and the logic of the transaction (actually I don't think it is possible at all).
The main diagrams to be considered here would be:
Sequence diagram depicting the process of requesting/changing states (you may have few showing various triggers for the change and use alt/opt to show further behaviour)
Activity diagram depicting how the process of state changing is handled
Interaction overview diagram with state changes being shown at the "activity" level and negotiation between the master and the slave in the "sequence" parts.
Especially the last one is an interesting option here as it combines possibilities of activity and sequence diagrams. Usually it's an overkill but might be the best idea for your specific case.
In addition to those you may also use the state machine diagram (two, one for master and one for slave) but they will not be able to show the interaction between the two entities. It might be useful though to explain what are the available states.
If it is not clear feel free to comment this answer asking for more details. I will try building example of each of those diagrams then (activity diagram example you already have in the answer by www.admiraalit.nl).
Following on the discussion at State machine program design in FreeRTOS - vTaskStartScheduler in a switch statement, I have a state machine with 4 states, each of them with different tasks reading sensor data.
When a sensor data reaches a threshold, its task has to cause a state change.
The idea is to have a superior task which controls the states (and suspends/resumes corresponding tasks) with a switch statement. My question is: how should the sensor tasks communicate the STATE with the superior task?
One proposed solution is to have a set_state function which is called by the event generating task, but I read that having global variables in FreeRTOS is discouraged. I thought to implement it through Queues:
1- Task1 detects sensor threshold, and sends STATE to a Queue.
2- Superior task is blocked waiting to receive data from Queue. When it receives STATE, the switch statement processes the state change.
If this approach is correct, my doubt relates on how and where should be STATE defined (global, or just existing in the stack of each task, or the superior task...)
STATE should exist only where it needs to, 'in' the superior task. I'm presuming you're using C, so declare STATE as a static variable in "superior_task.c" (or whatever it's called). This means it can then only be affected within that file - the C equivalent to a private member variable in C++.
Then, if your inferior tasks need to affect a state change, they post a state change event to a queue managed by the superior task. When the queue is processed, the superior state makes the change to the private STATE variable.
If other tasks need to know what the state is for their own processing, they can use an accessor for the private variable, e.g., State get_state() { return STATE; }. As Martin says though, the other tasks shouldn't need to know the state, as otherwise there's inter-dependencies between tasks that shouldn't exist.
I have implemented a simple state machine for an embedded system using C's switch statement. I know it would be better if I used function pointers with a look up table but I'm saving that as a next step.
My state machine has the following states:
Startup (the initial state)
Startup Error.
Idle (the system only checks for input in this state. It does not update the display or anything else. It's just 'idle').
Check (this is the actual application)
Program
Copy to Internal Memory
When the system starts up, it enter the startup state which configures the ports, initializes the display and does a hand-shake with the ICs connected on the SPI bus to ensure everything is A-OK. If so, the system enters the Idle state. If not, it enters the Startup Error state, displays an error on the LCD, flags a variable and then enters the Idle state.
In the Idle state, the program polls 3 pins on the microcontroller to check if one of the 3 buttons (Check, Program, Copy to Mem.) is pressed. Depending on which button is pressed, it enters the appropriate state, executes some code, updates the LCD and then returns back to the Idle state. NOTE: The system does NOT care if a button is pressed if there was a hardware fault in the system. The Startup Error state flags a variable called hardware_fault which, if set, ensures that the Idle state does not bother polling any of the input buttons.
This is the first time I'm implementing a state machine and I was just unsure if this was a good design. I haven't really seen any examples of FSMs where they poll for input in an Idle state. Instead, it seems, most examples are rather sequential in nature (like a counter, for instance). So, my question is, is my design reasonable? It DOES work but as everyone here knows, there is bad design and then there is good design.
You should refactor your code away from a switch statement and use a transition table as you mention. Code around a switch doesn't scale, is messy and quickly becomes difficult to read and update.
To answer your question, I would say that most state machines are actually like yours: they react to events (in your case, the poll). If they are purely sequential, without events at all, they are for specialized usages, like implementing a regex...
As a note, the Idle state is equivalent to the runtime core of a state machine library: it intercepts events and posts them to the state machine. With a state machine library, it would be "hidden" from the client code, while a bare bones implementation like yours has to do event polling explicitly.
And now a design critique: one should avoid global variables in general, and especially so in a state machine. State Idle should not know about a hardware_fault global variable. With state machines, one should strive to "embed" global variables in the state machine itself, by adding states (when it makes sense!). A very good introduction to (hierarchical) state machines and explanation of the rationale is here.
Using the UML notation (see here for a tutorial), your state machine is:
An easy refactoring to remove the hardware_fault dependency all together is:
That is, we just stay forever in the StartupError state, without transitioning to Idle.
The ε (epsilon) represents an empty transition, that is, a transition that is taken as soon as the activity associated with the source node is over, without any event. This is what you mean by "sequential" state machines.
I am also including the sources to the first diagram (the second one is very similar), generated with the very easy and powerful PlantUML.
#startuml
skinparam shadowing false
title Embedded v1
state Startup
state StartupError
state Idle
state Program
state Check
state Copy
Startup : entry/ init HW
StartupError: entry/\n display error\n hw_fault = true
Idle : do/ if not hw_fault: poll
Program : do/ program
Check : do/ check
Copy : do/ copy
[*] -> Startup
Startup -> StartupError : ε [error]
Startup --> Idle : ε [not error]
StartupError --> Idle : ε
Idle --> Program : program_btn
Idle --> Check : check_btn
Idle --> Copy : copy_btn
Program --> Idle : ε
Check --> Idle : ε
Copy --> Idle : ε
#enduml
I have been using State machine based design tools for some time, and have seen UML modeling tools that allow you to execute your logic (call functions, do other stuff) inside a state. However, after spending a couple days with IAR VisualState, it appears that you cannot execute your logic inside a state without a trigger. I am confused as it does not make sense TO HAVE A TRIGGER for every single action inside a state !
Here is what I expect from a state chart tool:
If I enter StateA, upon entering the state I set my values in entry section, then I would like to call a function (I just want to call it, NO TRIGGER), and inside that function, I want to trigger an event based on some logic, and that event would trigget state transition from StateA to StateB or StateC.
Is there something wrong with this expectation? Is it possible in VisualSTATE?
Help is greatly appreciated.
VisualSTATE imposes the event-driven paradigm, just like any Graphical User Interface program. Anything and everything that happens in such systems is triggered by an event. The system then responds by performing actions (computation) and possibly by changing the state (state transition).
Probably the most difficult aspect of event-driven systems is the inversion of control, that is, your (state machine) code is called only when there is an event to process. Otherwise, your code is not even active. This means that you are not in control, the events are. Your job is to respond to events.
Perhaps before you play with visualSTATE, you could pick up any book on GUI programming for Windows (Visual Basic is a good starting point) and build a couple of event-driven applications. After you do this, the philosophy behind visualSTATE will become much clearer.
Create 3 states: A, B, C where state A is a default state.
By entering state A, call action function [that sets you
variables a and b following some algorithm], followed by ^Signal1.
Entry/ action()^Signal1
Make a transition driven by Signal1 [will serve you as an event] from state A with 2 guards:
a <= b, transition to state C
a > b, transition to state B