State Machine Design for Automated Machines: The Architecture Behind Reliable Machine Control

A machine sequence needs more than a list of actions and delays. It must also handle late sensors, repeated commands, interrupted power, and someone walking away halfway through a cycle. A state machine makes those situations explicit, so you can review the permitted transitions and test how the machine recovers.

For each state, list its entry conditions, outputs, expected events, timeout, and recovery path. Test duplicate events and a restart between each irreversible action and its confirmation. Payment-enabled machines make that distinction especially important. Connect the state model to the control-system fault matrix and diagnostic logs. A diagram improves reviewability; tests must still prove the implementation behaves as intended.

1. The Perils of Spaghetti Automation: Why Machines Lock Up

A simple blocking sequence may be enough to demonstrate a mechanism, but it can hide assumptions about timing and faults. Start by examining the following example as a teaching sketch, not production control code. Ask what it does when an expected event never arrives.

• Read user button press.
• Delay 500 ms for payment gateway serial packet.
• Energize high-side solenoid to open the door latch.
• Wait in a while(!digitalRead(DOOR_CLOSED_PIN)) loop until the user shuts the door.
• Energize UV-C lamps and ventilation pump for 30 seconds using delay(30000).
• De-energize UV-C lamps, unlock the door, and return to start.

In the sterile environment of an engineering workbench, this code appears to work. But deploy 100 units into shopping malls, factory floors, or metro stations, and this code will fail within 72 hours. Why?

• The Infinite Blocking Trap: If a customer opens the door, inserts their helmet, but fails to fully latch the door shut (it remains open by 2 mm), the code stays trapped forever inside while(!digitalRead(DOOR_CLOSED_PIN)). The touchscreen becomes unresponsive, the payment gateway times out, the user panics, and the entire kiosk is bricked until a technician manually cycles main power.
• The Blind Delay Danger: While the processor is stuck executing delay(30000), it is completely blind to the physical world. If a child forces the chamber door open with a pry tool, or if the ventilation motor catches fire and trips an optical smoke detector, the microcontroller continues blindly blasting UV-C radiation and driving high-voltage transformers because it cannot process external inputs during a blocking delay.
• The Combinatorial Flag Explosion: To patch these bugs, developers invariably introduce boolean flags: bool isDoorOpen, bool isPaymentPending, bool isEmergencyStopPressed, bool isMotorHomed, bool isSanitizing. Within three firmware revisions, the codebase becomes a tangled nest of 25 flags. A machine with 25 independent boolean flags has 2²⁵ = 33,554,432 possible internal states. No human software engineer can mentally model, simulate, or unit-test 33 million state combinations. Inevitably, an unpredicted permutation occurs in the field, causing the machine to enter an undefined zombie state.

2. FSM Fundamentals for Cyber-Physical Systems: Moore vs. Mealy

To eliminate combinatorial explosion, automated machine firmware must be structured as a formal Finite State Machine (FSM). At any given microsecond, the machine exists in exactly ONE clearly defined State from a finite, enumerated list. Changes in the physical world are converted into discrete Events, which trigger strictly validated Transitions between states.

In classical automata theory, there are two fundamental state machine architectures:

• Mealy Machine: Actuator outputs are determined by BOTH the current active state AND the instantaneous input signals (Output = λ(State, Input)). While Mealy machines often require fewer states, they are dangerous in electromechanical hardware. If an inductive proximity sensor flickers due to electrical noise from a starting spindle motor, a Mealy machine's output pins will flicker synchronously, causing contactor chattering, MOSFET heating, and relay welding.
• Moore Machine: Actuator outputs depend STRICTLY on the current active state (Output = λ(State)). Outputs only change when a formal state transition occurs. In cyber-physical product design, SolveMpire standardizes on an extended Moore architecture augmented with explicit State Entry Actions and State Exit Actions.

3. The Production Machine Lifecycle: The 10-Step Execution Loop

Consider a mission-critical commercial or industrial machine: an automated helmet sanitization kiosk (such as SolveMpire’s FreshPod platform), a chemical dispensing cell, or an automated pick-and-pack workstation. The operational cycle consists of ten rigorous, closed-loop states. No state may transition to the next without verified physical sensor confirmation and watchdog supervisor assertions.

1. STATE_IDLE: The machine rests in a low-power standby mode. The HMI screen displays an inviting user interface animation. High-voltage power stages (UV-C ballasts, ozone generators, 230V pumps) are hard-disabled via high-side MOSFETs. The microcontroller continuously monitors optical presence sensors, thermal probes, and cloud heartbeat telemetry at 10 Hz.
2. STATE_SELECTION: Triggered when a customer touches the capacitive HMI screen or an optical proximity sensor detects an operator. The controller reads user parameters (e.g. standard vs. intensive disinfection cycle). The firmware verifies that internal consumables (sanitizing fluid level, ozone catalyst temperature) are within operational thresholds. A non-blocking 60-second User Inactivity Watchdog is armed.
3. STATE_PAYMENT: For commercial kiosks, the controller commands the cellular/Ethernet telemetry module to request a dynamic UPI QR code or wake the contactless EMV card reader. The FSM transitions to an asynchronous polling sub-loop. Crucially, the main firmware thread is never blocked: it simultaneously monitors the physical CAN bus, checks the user 'Cancel' button on the screen, and enforces a strict 90-second payment gateway timeout.
4. STATE_VERIFICATION: Upon receiving a payment webhook or hardware pulse, the machine executes an internal cryptographic verification. The controller confirms valid transaction authorization, verifies that the internal safety loop (E-stop relay continuity) is closed, and tests that the chamber optical sensor reads 'Chamber Ready'.
5. STATE_UNLOCK: The controller energizes a high-side smart power switch (e.g. Infineon PROFET) to drive a 24V solenoid door latch for exactly 350 ms. It starts an Actuator Motion Watchdog (1,000 ms). An optoisolated magnetic reed switch on the door striker plate must transition from HIGH to LOW within 1,000 ms to confirm physical unlatching. If the sensor does not transition, the solenoid is de-energized immediately to prevent coil burnout, and the FSM routes to FAULT_DOOR_LATCH.
6. STATE_USER_ACTION: The door pops ajar; the HMI prompts the user with step-by-step visual graphics: 'Please open the door, insert your helmet facing forward onto the sanitized cradle, and close the door firmly.' Time-of-Flight (ToF) distance sensors and infrared light curtains monitor the chamber threshold. A 45-second Door Left Ajar watchdog runs in the background with audible progressive chimes.
7. STATE_SENSOR_CHECK: The user closes the door. The magnetic latch snaps shut. Before a single drop of fluid is pumped or high-power UV-C lamp energized, the controller executes a mandatory 200 ms Sensor Assertion Barrage: (a) Dual door safety interlock switches must both report closed, (b) Optical reflection sensors must confirm helmet presence on the cradle, (c) Light curtains must verify zero human fingers breaking the door perimeter, and (d) Chamber temperature must be below 45°C. If any assertion fails, the door remains unlocked and the HMI instructs the user to reposition the workpiece.
8. STATE_PROCESS: The physical automation cycle runs. The controller initiates the sequence: high-side MOSFETs energize internal UV-C tubes, ozone generators, and radial ventilation blowers. An internal FreeRTOS software timer tracks cycle duration (e.g. 180 seconds). Concurrently, an ADC task samples hall-effect current transducers at 1 kHz to verify that ventilation fans are actually spinning (detecting sheared belts or stalled bearings) and ozone generators are drawing expected current.
9. STATE_COMPLETE: The disinfection timer expires. The process stage de-energizes. Radial exhaust fans run a mandatory 15-second ozone purge. Non-volatile FRAM increments the lifetime cycle counter and transaction database. The door latch solenoid pulses, popping the door open. A pleasant audio chime rings, and the HMI displays: 'Sanitization Complete! Please retrieve your helmet.'
10. RETURN TO IDLE: An optical sensor confirms the customer has removed their item, and the door switch confirms the chamber has been closed. The HMI resets, the session tokens are cleared from RAM, and the machine deterministically re-enters STATE_IDLE, ready for the next customer.

4. The Architecture of Error Handling: The 4-Tier Fault Matrix

The hallmark of amateur machine design is routing all unexpected events into a single, generic ERROR state that displays 'Machine Out of Order' and halts execution. In commercial kiosks and industrial automated cells, a single error state destroys revenue and infuriates operators.

At SolveMpire, we architect error handling as a 4-Tier Fault Hierarchy. Each tier features distinct recovery mechanics, safety overrides, and user remediation workflows:

5. The Anatomy of a Robust State: Entry, Tick & Exit Actions

To guarantee that hardware remains completely safe under all operating conditions—including sudden power failures, emergency stops, or unexpected sensor trips—every state inside the FSM must be structured around Three Mandatory Execution Hooks:

• State Entry Action (on_enter): Executed exactly ONCE when the machine enters the state. This is where hardware outputs are configured for the state: energizing specific indicator LEDs, commanding HMI screen page changes, configuring ADC sampling rates, and initializing the State Watchdog Timer.
• State During/Tick Action (on_tick): Executed periodically at fixed real-time intervals (typically every 10 ms inside a FreeRTOS task). This hook evaluates sensor inputs, runs software debouncing filters, updates UI progress bars, monitors the state timeout counter, and evaluates whether a valid state transition event has occurred.
• State Exit Action (on_exit): Executed exactly ONCE whenever the machine transitions OUT of the state—regardless of whether the exit was caused by normal completion, a user cancellation, or an emergency abort. This is the single most vital safety hook in firmware engineering.

6. Handling Asynchronous Physical Realities: Debouncing & Timeouts

In pure computer science textbooks, inputs to an FSM are instantaneous mathematical symbols: a, b, 0, 1. In physical industrial product design, inputs are dirty, continuous, noisy analog voltages. Designing a reliable state machine requires conditioning the physical world before feeding it into the state logic:

• Software State Debouncing: Mechanical limit switches, door interlocks, and pushbuttons oscillate physically between contact points for 5 to 25 milliseconds upon closure. If fed directly to an edge-triggered state machine, a single button press can trigger 10 state transitions in 1 millisecond. In our firmware architecture, raw digital GPIO pins are never fed directly to the state machine. Instead, a dedicated 1 ms Timer Interrupt samples the pin into an 8-bit shift register. Only when 8 consecutive samples are identical (0xFF or 0x00) does the debouncer emit a formal validated event: EVENT_DOOR_LATCHED.
• The State Watchdog Pattern: Every single state in your machine must have an upper-bound time limit ($T_{max}$). For example, STATE_UNLOCK has a $T_{max}$ of 1,200 ms; STATE_USER_ACTION has a $T_{max}$ of 45,000 ms; STATE_PROCESS has a $T_{max}$ of 195,000 ms. An active state counter increments on every 10 ms tick. If the timer exceeds $T_{max}$ without a valid sensor transition, the state machine forcibly raises an internal EVENT_TIMEOUT, preventing the system from ever locking up indefinitely.

7. State Machine Implementation Patterns in Embedded C

How should an industrial FSM be implemented in embedded C/C++? There are three standard software engineering patterns, each with distinct trade-offs:

• Pattern A: Switch-Case State Machine: The simplest pattern. An outer switch(current_state) evaluates the state, and an inner switch(event) or if-statements handle transitions. Excellent for small sub-systems (under 6 states). However, for complex machines with 15+ states and multiple fault modes, switch-case blocks grow to thousands of lines, becoming unwieldy, difficult to navigate, and prone to fall-through bugs.
• Pattern B: 2D State-Transition Table Matrix: A two-dimensional lookup table where rows represent States, columns represent Events, and array cells contain the Target State and a Function Pointer to execute. Highly deterministic and mathematically elegant. However, transition tables become sparse memory wasters when there are 20 states and 30 events (600 cells, most of which are invalid).
• Pattern C: Function-Pointer State Handler with Entry/Exit (SolveMpire Standard): Each state is represented by an explicit C struct containing three function pointers: void (on_enter)(void), void (on_tick)(void), and void (*on_exit)(void). The state machine engine maintains a pointer to the current State struct. State handlers remain completely modular, encapsulated in their own C files, and unit-testable in isolation.

8. Production Code Blueprint: FreeRTOS Event-Driven FSM in C

Below is an architectural production C blueprint showing how SolveMpire structures a deterministic, event-driven state machine running on an ARM Cortex-M7 (STM32H7) microcontroller using FreeRTOS. Notice how physical inputs are decoupled from state logic using an asynchronous thread-safe FreeRTOS Queue:

/* ==========================================================================
 * SolveMpire Industrial Control Framework - Deterministic Machine FSM
 * Target: ARM Cortex-M7 / FreeRTOS v10.4+
 * ========================================================================== */

typedef enum {
    STATE_IDLE = 0,
    STATE_SELECTION,
    STATE_PAYMENT,
    STATE_VERIFICATION,
    STATE_UNLOCK,
    STATE_USER_ACTION,
    STATE_SENSOR_CHECK,
    STATE_PROCESS,
    STATE_COMPLETE,
    STATE_FAULT_RECOVERABLE,
    STATE_FAULT_CRITICAL,
    STATE_COUNT
} machine_state_t;

typedef enum {
    EVENT_NONE = 0,
    EVENT_USER_TOUCH,
    EVENT_SELECTION_CONFIRMED,
    EVENT_PAYMENT_SUCCESS,
    EVENT_PAYMENT_FAILED,
    EVENT_DOOR_UNLATCHED,
    EVENT_USER_ACTION_COMPLETED,
    EVENT_SENSORS_VALIDATED,
    EVENT_PROCESS_FINISHED,
    EVENT_ITEM_RETRIEVED,
    EVENT_TIMEOUT,
    EVENT_ESTOP_TRIGGERED
} machine_event_t;

typedef struct {
    machine_state_t state_id;
    const char*     name;
    uint32_t        max_timeout_ms;
    void (*on_enter)(void);
    machine_event_t (*on_tick)(uint32_t elapsed_ms);
    void (*on_exit)(void);
} state_descriptor_t;

/* Function Prototypes for State Hooks */
static void state_idle_enter(void);
static machine_event_t state_idle_tick(uint32_t elapsed_ms);
static void state_idle_exit(void);

static void state_unlock_enter(void);
static machine_event_t state_unlock_tick(uint32_t elapsed_ms);
static void state_unlock_exit(void);

static void state_process_enter(void);
static machine_event_t state_process_tick(uint32_t elapsed_ms);
static void state_process_exit(void);

/* The State Table Descriptor Registry */
static const state_descriptor_t g_state_table[STATE_COUNT] = {
    [STATE_IDLE] = {
        .state_id = STATE_IDLE,
        .name = "IDLE",
        .max_timeout_ms = 0, /* Infinite standby */
        .on_enter = state_idle_enter,
        .on_tick  = state_idle_tick,
        .on_exit  = state_idle_exit
    },
    [STATE_UNLOCK] = {
        .state_id = STATE_UNLOCK,
        .name = "UNLOCK",
        .max_timeout_ms = 1200, /* 1.2s max to verify unlatch */
        .on_enter = state_unlock_enter,
        .on_tick  = state_unlock_tick,
        .on_exit  = state_unlock_exit
    },
    [STATE_PROCESS] = {
        .state_id = STATE_PROCESS,
        .name = "PROCESS",
        .max_timeout_ms = 185000, /* 3 mins + 5s margin */
        .on_enter = state_process_enter,
        .on_tick  = state_process_tick,
        .on_exit  = state_process_exit
    },
    /* Additional state descriptors registered here... */
};

/* Thread-safe FreeRTOS Event Queue */
static QueueHandle_t g_fsm_event_queue = NULL;
static machine_state_t g_current_state = STATE_IDLE;
static uint32_t g_state_entry_timestamp = 0;

/* Deterministic State Transition Function */
void FSM_Transition(machine_state_t next_state) {
    if (next_state >= STATE_COUNT) return;
    
    /* 1. Execute Exit Hook of Current State */
    if (g_state_table[g_current_state].on_exit != NULL) {
        g_state_table[g_current_state].on_exit();
    }
    
    /* 2. Record Microsecond Transition Telemetry in FRAM */
    FRAM_LogStateTransition(g_current_state, next_state, xTaskGetTickCount());
    
    /* 3. Update State Variable & Reset Timer */
    g_current_state = next_state;
    g_state_entry_timestamp = xTaskGetTickCount();
    
    /* 4. Execute Entry Hook of Next State */
    if (g_state_table[g_current_state].on_enter != NULL) {
        g_state_table[g_current_state].on_enter();
    }
}

/* Dedicated FreeRTOS FSM Supervisor Task (10 ms Period) */
void Task_MachineFSM(void *pvParameters) {
    machine_event_t event = EVENT_NONE;
    g_state_entry_timestamp = xTaskGetTickCount();
    g_state_table[g_current_state].on_enter();

    while (1) {
        uint32_t now = xTaskGetTickCount();
        uint32_t elapsed_ms = (now - g_state_entry_timestamp) * portTICK_PERIOD_MS;
        uint32_t timeout_ms = g_state_table[g_current_state].max_timeout_ms;

        /* 1. Check State Watchdog Timer */
        if (timeout_ms > 0 && elapsed_ms > timeout_ms) {
            FSM_Transition(STATE_FAULT_RECOVERABLE);
            vTaskDelay(pdMS_TO_TICKS(10));
            continue;
        }

        /* 2. Process Asynchronous Events from ISRs / Networking */
        if (xQueueReceive(g_fsm_event_queue, &event, 0) == pdTRUE) {
            if (event == EVENT_ESTOP_TRIGGERED) {
                FSM_Transition(STATE_FAULT_CRITICAL);
                continue;
            }
        }

        /* 3. Execute Periodic State Tick Hook */
        if (g_state_table[g_current_state].on_tick != NULL) {
            machine_event_t tick_event = g_state_table[g_current_state].on_tick(elapsed_ms);
            if (tick_event != EVENT_NONE) {
                /* Evaluate State Transition Logic based on validated event */
                FSM_EvaluateTransition(tick_event);
            }
        }

        /* Non-blocking 10 ms execution cycle */
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

Notice three crucial architectural details in this code:

• 100% Non-Blocking: The task never invokes delay() or busy-waits on a sensor. It sleeps cleanly for 10 ms (vTaskDelay(10)), allowing FreeRTOS to service motor PWM tasks, network stacks, and HMI display rendering.
• Zero-Latency Emergency Override: The EVENT_ESTOP_TRIGGERED event instantly bypasses normal state processing, forcing an immediate transition to STATE_FAULT_CRITICAL without waiting for the current cycle to complete.
• Automatic Watchdog Assertion: If elapsed_ms exceeds max_timeout_ms, the machine automatically transitions to an error state. Mechanical binding or dropped sensors can never freeze the processor.

9. Telemetry, Black-Box State History & Post-Mortem Debugging

When a machine fails in a customer facility 800 kilometers away, asking the customer 'What happened right before it stopped?' yields useless answers: 'It just stopped working.'

To eliminate field mystery, every production state machine engineered by SolveMpire incorporates a Non-Volatile FRAM Black-Box Circular Buffer. We allocate 16 KB of high-speed Ferroelectric RAM (virtually infinite write endurance, zero write-delay) configured as a ring buffer storing the last 64 state transitions.

• Transition Header: From State (uint8_t), To State (uint8_t), Triggering Event (uint8_t).
• Microsecond Timestamp: 64-bit hardware RTC timestamp synchronized to network time.
• Hardware Sensor Bitmask: 32-bit register capturing the exact optical, magnetic, and thermal sensor logic states at the microsecond of transition.
• Actuator Power Bitmask: 32-bit register recording which MOSFETs, contactors, and pneumatic valves were energized.
• Analog Bus Telemetry: DC supply voltage, 24V field rail voltage, and primary motor current draw.

When a fault occurs, this entire black-box log is frozen and transmitted via MQTT/HTTPS over cellular telemetry to the SolveMpire Cloud Dashboard. Within seconds, our engineering team can reconstruct the exact electromechanical timeline: 'At 14:32:08.412, the machine entered STATE_UNLOCK. At 14:32:09.612 (1,200 ms later), the State Watchdog tripped because the striker plate magnetic sensor remained open, indicating mechanical solenoid friction or a bent door hinge.' Root cause identified in 30 seconds without flying an engineer to the site.

10. SolveMpire’s Turnkey Machine Firmware Engineering Protocol

Developing a well-engineered automated machine requires bridging the chasm between mechanical kinematics, industrial PCB electronics, and deterministic embedded software. At SolveMpire, we engineer full-stack physical automation systems from concept to mass production.

Our embedded state machine engineering protocol includes:

• Formal Statechart Modeling: Developing mathematically verified UML Statecharts with complete state-transition matrices, hazard analysis, and failure mode effects analysis (FMEA) before writing a single line of firmware.
• Deterministic FreeRTOS Firmware Architecture: Implementing modular, non-blocking C/C++ state engines with sub-millisecond real-time event queues, hardware watchdog supervision, and strict memory safety.
• Industrial Controller PCB Integration: Designing custom 4-layer industrial electronics with optoisolated 24V field sensing, smart high-side power switching, and integrated Modbus/CAN communication.
• Automated Edge Telemetry & Diagnostics: Embedding non-volatile FRAM black-box recorders and secure cellular/Wi-Fi IoT connectivity for 24/7 remote fleet monitoring, automated error alerting, and over-the-air (OTA) firmware updates.