FSM diagrams - Modern device with battery / charger

Question

I'm studying state machines diagrams and was asked to come up with a diagram for a device that turns on and off when a button is pressed... but as with other modern devices nowadays, it can operate either when the battery has charge in it, or when connected to electricity, such as a cellphone device.

My question is... how is that check made in state machine diagrams (if done at all). Should there be states that verify if battery has charge in it or if a charger is connected, or are those just transitions in the diagram?

Don't need full solutions, just need some help in understanding this. Thanks everyone in advance!

Could you clarify the question a bit more? Is it that this state machine (when implemented) draws power from these sources - in which case it is an implementation detail and is irrelevant to the FSM. Or is it that this state machine needs to be aware of its power source in order to make decisions on it - in which case states/transitions are equally good depending on the style of state machine being aimed at. — Kain0_0, Nov 09 '20 at 22:36
@Kain0_0 the device needs to draw power from the battery, since if you press the power button on such a device that has no power, it doesn't turn on. It's indeed an implementation detail in that sense, however shouldn't that be reflected on the diagram? If you press the power button, is it not relevant to somehow show the decision of turning on the device, but only when a power source is available? thanks for the help — h0tfus3, Nov 10 '20 at 00:01

score 1 · Answer 1 · answered Nov 09 '20 at 23:57

1

In a finite state machine with no push down stack, all state is encoded in... the states.

You have several different dimensions I can identify:

Battery state: depleted/charging/charged
Plgged-in state: unplugged/plugged
Device state: on/off

You can imagine a 3D chart that has one cell for every possible comination of battery state, plugged-in state and device state. That gives 12 potential states, although perhaps not all of them make sense (deleted+unplugged won't make sense, for example).

You can then draw the arcs between all of these states. E.g. a button press takes you from charged/unplugged/off to charged/unplugged/on. Prolong usage might transition that to depleted/unplugged/off, etc.

answered Nov 09 '20 at 23:57

Alexander

4,884

Not necessarily, the battery information can be encoded as transitions with states focusing on the on/off status of the light itself. – Kain0_0 Nov 10 '20 at 00:01
Button state depressed, not depressed is another state. It could also have an indeterminate state (e.g. when battery is depleted and device is not plugged in). It depends on the way the model models.

ben rudgers

Nov 10 '20 at 00:08

@benrudgers I'm modelling the button as an instantaneous push-button. Really, you could keep adding detail (e.g. finger-on-the-button, finger-off-the-button, with arcs like "move finger to button", "apply finger pressure", "release button", etc.) – Alexander Nov 10 '20 at 01:02

Move finger to button is not a state of the device. Button up-down is and what happens varies with the on-off state of the device...and varies in the off state depending on if there is or is not available power. The way to create the state machine begins with the button because the button generates the next state except for running out of power. – ben rudgers Nov 10 '20 at 01:13

My phone unlocks when I put my finger on the button without clicking the button itself, so actually, it is a state of the device (my device). Nonetheless, my point is that none of these minutia matter, they're mere speculations of the specifics of the device, which is irrelevant to the meta-problem of how to approach such modelling problems. – Alexander Nov 10 '20 at 01:17

score 1 · Accepted Answer · answered Nov 10 '20 at 01:13

One way, focusing on the light and button. Viewing the power system as a separate concern.

| current State | event        | new State |
|---------------|--------------|-----------|
| Unpowered     | press button | Unpowered |
| Unpowered     | powered      | Off       |
| Off           | press button | On        |
| Off           | unpowered    | Unpowered |
| On            | press button | Off       |
| On            | unpowered    | Unpowered |

You could go further and model the battery state as well... But it itself has no relevance to the state of the light.

You can also fill in the other events combinations, I'm going with undefined => no change in state from event, as this is a controller, not a verifier fsm.

We can flip it so that processes (like on/off) are the events themselves, where as above they were the states.

| current State                       | event    | new State                               |
|-------------------------------------|----------|-----------------------------------------|
| Not Pressed,Plugged In,Battery Flat | On       | Pressed,Plugged In,Battery Flat         |
| Not Pressed,Plugged In,Battery Flat | Charging | Not Pressed,Plugged In,Battery not Flat |
| Pressed,Plugged In,Battery Flat     | Off      | Not Pressed,Unplugged,Battery Flat      |
| Pressed,Plugged In,Battery Flat     | Off      | Not Pressed,Plugged In,Battery Flat     |
...

Notice that this one isn't deterministic, the event "Off" implies two possible states, from the same starting state.

FSM diagrams - Modern device with battery / charger

2 Answers2