# Independent states in a state machine diagram

I'm wondering how to represent independent states in a state machine diagram.

Let's say we have 2 LEDs: each can be on or off, but each LED's state has nothing whatsoever to with it's neighbour's state.

So we might have A on a timer, and LED_A_on changes to LED_A_off when the time is up, and on again next time the time expires.

B could be on a button, toggling each time the button is pressed, LED_B_on => LED_B_off => LED_B_on etc

I have represented those independently in V1 of the diagram. It means each LED needs its own starting point from the solid blob.

Alternatively, the system as a whole has 4 states, with A and B being on/on, off/off, off/on and on/off. That's represented in V2, with only one starting state. (I've left out the diagonals: let's assume it can only cross a diagonal by doing 2 separate changes round the sides.)

V1 looks simpler, but I'm wondering if V2 isn't "more correct" since it represents the state of the total system. In V1, 2 states are active at any moment; in V2 only 1 can be.

Is there a "right" (or at least "best practice") way of representing such independent states?

While you can represent all combinations and say the whole system has 4 states, that may not be actually useful.

If your 'A' Led is independent from 'B', treat it as such.

Practically, for writing code, you want to define enough states for which you need specific transitions to occur.

It makes sense combining these states:

``````Aoff Boff
switch1 -> Aon Boff
switch2 -> Aoff Bon

Aon Boff
timer1 -> Aoff Boff

Aoff Bon
timer2 -> Aoff Boff
``````

if we really want the last 2 states to ignore the switch inputs

whereas these are separate states of separate processes:

``````Aoff
switch1 -> Aon
Aon
switch1 -> Aoff

Boff
switch2 -> Bon
Bon
timer1 -> Boff
``````

Looking at your diagrams, the code for these would look a bit like:

``````// two state machines for two separate processes
//
switch( ledAstate )
{
case A_OFF:  if( timer ) ledAstate= A_ON; break;
case A_ON:   if( timer ) ledAstate= A_OFF; break;
}
switch( ledBstate )
{
case B_OFF:  if( button ) ledBstate= B_ON; break;
case B_ON:   if( button ) ledBstate= B_OFF; break;
}

// messy state machine
//
switch( state )
{
case A0B0:
if( button ) state= A0B1;
if( timer ) state= A1B0;
break;
case A1B0:
case A0B1:      this gets confusing pretty quick.
case A1B1:
}
``````

Unless this is an academic exercise, don't get too hung up on representing all the states in diagrams - they are useful but have practical limits.

Yours,
TonyWilk

Yeah your code is exactly how I would write it, either the clean way or the messy way.

If as I have hypothticalled (if there’s no such word, there is now) the two LEDs have literally no interdependence then there’s no point trying to show them as “joint” states, unless of course that has some significance to the system as a whole. If that’s the case then of course that significance needs to be shown. Maybe Aon & Bon has some system meaning, and is the only time some other switchX needs to be read.

wilfredmedlin:
Maybe Aon & Bon has some system meaning, and is the only time some other switchX needs to be read.

Yes.

In practice, you often have 'overrides' which would just make nice state diagrams look real messy.

For example: implementing a HOLD button which ignores all inputs. Adding that to every state would be a real pain, but trivial in code.

Yours,
TonyWilk

If they're really independent, you create two state diagrams. If they share inputs / timers, you can still use two diagrams.

Only if a state in one state machine affects the state of another statemachine, you might want to opt for a single state diagram. But you can also add that in the condition for the transition in the other diagram.