Chess, PLCs, and finite state machines

I was on a coffee break, after several hours programming, staring into space as if the solution were going to come from there.

When you’ve been on code for too long, your body keeps running on autopilot, but your mind starts wandering without asking for permission.

During one of those wanderings, I realized something.

There are two things I really enjoy in life: programming PLCs and playing chess.

The typical thing would be to say something like “both are strategy” and call it a day, but what obsessed me was something else: if you get formal, both can be described with the same mathematical model.

That model is the finite state machine (FSM).

And no, I don’t mean it as a cute metaphor. I mean it as: “I can write the 5-tuple, define the state, define the events, define the transition… and everything fits.”

"Alright, relax Samuel... but yes: chess is an FSM. And a well-designed PLC is too."

1) What is an FSM (a real mathematical definition)

A finite state machine is defined as the 5-tuple:

M = (S,\ \Sigma,\ \delta,\ s_0,\ F)

S: a finite, non-empty set of states.
Σ: a finite set of inputs / events.
δ: the state transition function.
s₀ ∈ S: the initial state.
F ⊆ S: final states (if the system “accepts” or “terminates”).

In the classic deterministic case (DFA / deterministic FSM), the transition is a function:

\delta : S\times \Sigma \rightarrow S

That is: current state + event → next state (unique).

And the time evolution is discrete:

sₖ₊₁ = \delta(sₖ, σₖ)

Two important technical notes (this is where it gets fun):

1.1 Partial vs total FSM (and the “error state”)

In many real systems, there are inputs/events that simply do not apply in certain states. Mathematically that means δ is not defined for some pairs (s,σ). That is a partially defined FSM.

If you want to “totalize” the model (make δ always defined), there’s a standard trick: add a sink state (error) ⊥ and send everything illegal there:

\begin{aligned} \delta'(s,\sigma) &= \delta(s,\sigma) &&\text{si está definida}\\ \delta'(s,\sigma) &= \perp &&\text{si no está definida}\\ \delta'(\perp,\sigma) &= \perp &&\forall\,\sigma \end{aligned}

In PLC terms this sounds like: “if I get something impossible, I go to FAULT/SAFE and I stay there.”

1.2 State graph (because everything ends up being a graph)

An FSM can be seen as a directed graph:

\begin{aligned} G&=(V,E),\qquad V=S,\\ E&\subseteq S\times \Sigma\times S \quad (\text{aristas etiquetadas}) \end{aligned}

And this lets you do very useful analysis:

Reachability: states you can reach from s₀.
Dead states: states with no useful exit (or where you get stuck).
Cycles: recurring behavior.
Absorbing states: once you enter, you never leave (typical FAULT).

If you like theory: you’re one step away from talking about safety properties (“X never happens”) and liveness properties (“eventually Y happens”). But I won’t get carried away… yet.

2) Chess as an FSM (no hand-waving)

To model chess as an FSM, we need to define a state that makes the system deterministic. A reasonable minimal definition is:


s = (B, t, c, e)

B: the complete board (which piece is on each square).
t: side to move (W/B).
c: castling rights.
e: en-passant capture square (or “not applicable”).

More formal (because we’re here to show off a little):

\begin{aligned} B&:\{1,\dots,64\}\rightarrow P\cup\{\emptyset\}\\ t&\in\{W,B\}\\ c&\subseteq\{WK,WQ,BK,BQ\}\\ e&\in\{1,\dots,64\}\cup\{\perp\} \end{aligned}

With that, the set of states is:

S=\{(B,t,c,e)\ \mid\ \text{estado legal según las reglas}\}

The events Σ are moves. A move can be represented as:

\begin{aligned} m&=(from,to,promo)\\ from,to&\in\{1,\dots,64\}\\ promo&\in\{Q,R,B,N,\perp\} \end{aligned}

And the transition is “apply a legal move”:

\begin{aligned} \delta(s,m)&=s' &&\text{si }m\text{ es legal en }s\\ \text{(no definida)} &&&\text{si }m\text{ es ilegal en }s \end{aligned}

The final states F include:

Checkmate: side to move is in check and has no legal moves.
Draws: stalemate, threefold repetition, 50-move rule, insufficient material, etc.

A game, mathematically, is a trajectory:

s₀ —m₁\rightarrow s₁ —m₂\rightarrow … —mₖ\rightarrow sₖ

And yes: the state space is huge, but finite. So it’s still an FSM.

3) A PLC as an FSM (an engineering model)

In automation we often think in terms of “modes” and “steps”. That’s already an FSM, even if nobody calls it that.

A typical PLC state can be written like this:


s = (mode, step, flags)

mode: STOP / MANUAL / AUTO / FAULT / ...
step: sequence index (implicit or explicit GRAFCET).
flags: internal memories, interlocks, latched diagnostics, etc.

The inputs Σ are (depending on the system): sensors, timers, operator commands, safety signals, communications, etc.

And the transition δ is implemented by you. On each scan:

sₖ₊₁ = \delta(sₖ, inputsₖ)

Note: in PLCs, inputsₖ is a time-sampled vector. Still, the FSM model works well because the scan defines a natural “discrete time”.

3.1 Moore vs Mealy (yes, in PLCs too)

In automata theory there are two typical ways to associate outputs:

Moore: output depends only on state: y = g(s).
Mealy: output depends on state and input: y = g(s, σ).

In PLCs, if you want stable behavior that’s easy to debug, you tend to design more “Moore-like” (actions per state) and keep “Mealy-like” behavior for transition decisions (guards).

4) Real common ground

4.1 Both are discrete-time dynamical systems

sₖ₊₁ = \delta(sₖ, σₖ)

In chess, each “tick” is a move. In PLCs, each “tick” is a scan.

4.2 Both are deterministic (uncertainty is outside)

In both cases, δ is deterministic: if the state and the event are the same, the next state is the same.

4.3 Valid states ≠ desirable states

This is the most useful parallel:

S=S_{\mathrm{safe}}\cup S_{\mathrm{unsafe}}

In chess: there are legal positions that are losing.
In PLCs: there are reachable states that are dangerous or unstable.

4.4 Forbidden transitions

Chess: rules → illegal moves.
PLCs: interlocks → impossible transitions.

Formally: δ not defined (or transition to error/safe).

4.5 Cycles and absorbing states

Both have cycles. And both have “terminal” or absorbing states.

\delta(s_f,\sigma)=s_f\qquad \forall\,\sigma

In chess: checkmate/draws. In PLCs: FAULT/E-STOP (until a conscious reset).

5) Okay, and how does this help in a real PLC?

Here are principles that fall straight out of the model:

Principle 1 — Make the state explicit, unique, and without “telepathy”

If your machine has modes/steps, declare them as such. If you don’t, they still exist — just hidden in scattered flags.

Principle 2 — Design δ (transitions) before “what to do”

First define the graph (which states exist and how they connect). Then implement actions.

Principle 3 — Forbid dangerous things (don’t trust luck)

If a path exists in the graph, someone (or something) will find it. Make S_unsafe unreachable or intercept it toward SAFE/FAULT.

Principle 4 — Faults are states, not random IFs

A fault is not a stray IF: it deserves an absorbing state and a conscious reset.

Principle 5 — If you can’t draw it, it’s probably wrong

A simple state diagram often reveals problems that the code hides.

6) Mini-example (typical industrial FSM)


S = {IDLE, EXTENDING, EXTENDED, RETRACTING, FAULT}

IDLE      --cmd_extend-->   EXTENDING
EXTENDING --s_ext-->        EXTENDED
EXTENDING --timeout-->      FAULT

EXTENDED  --cmd_retract-->  RETRACTING
RETRACTING--s_ret-->        IDLE
RETRACTING--timeout-->      FAULT

FAULT     --reset & ok-->   IDLE
FAULT     --other-->        FAULT

7) Closing

In chess you rarely lose because of a single move. You lose because you allowed the game to enter a region of the state space where there were no good exits left.

In industrial automation, the same thing happens. The difference is that here the cost of a mistake is real.


Designing an FSM is not “academic”.
It is engineering: explicit control of the reachable state space.