Click the little blue text to follow!
Yesterday, a friend working in industrial motor control complained that their production line frequently experiences inexplicable shutdown issues. Sometimes the motor suddenly reverses, and sometimes the safety door closes abnormally. After investigation, it was found that the problem lay in the state machine programming logic, where some boundary conditions were not considered, leading the system to enter an undefined state. This prompted me to share knowledge about risk assessment in state machine programming.
State machine programming is fundamental to industrial control systems, but a lack of systematic risk assessment can easily lead to safety incidents. Many engineers focus solely on whether the program can run, neglecting the handling of abnormal states, much like building a car without brakes.
1
What is State Machine Programming?
State machine programming is akin to designing different “rooms” (states) for the system and specifying the conditions under which to transition from one “room” to another. For example, a motor control system includes three states: “Stop”, “Forward”, and “Reverse”, which are switched via buttons or sensor signals.
Microcontrollers commonly use a switch-case structure to implement state machines; PLCs use step instructions in ladder diagrams or SFC to achieve this. A simple example of state machine code for a microcontroller is as follows:
enum MotorState {STOP, FORWARD, REVERSE};
MotorState currentState = STOP;
void processState() {
switch(currentState) {
case STOP:
if(startButton && safetyDoorClosed) currentState = FORWARD;
break;
case FORWARD:
if(stopButton || !safetyDoorClosed) currentState = STOP;
if(reverseButton && speedBelowThreshold) currentState = REVERSE;
break;
case REVERSE:
if(stopButton || !safetyDoorClosed) currentState = STOP;
if(forwardButton && speedBelowThreshold) currentState = FORWARD;
break;
}
}
2
Risk Points of State Machines
I once encountered a case where a factory’s conveyor belt control system used state machine programming, but the programmer forgot to handle the situation of pressing both the forward and reverse buttons simultaneously. As a result, the operator accidentally triggered both buttons, causing the system to enter an undefined state, with the motor speeding up and slowing down erratically, nearly damaging the equipment.
The three major risk points in state machine programming are: undefined state transitions, conflicting transition conditions, and state handling timeouts. These issues are particularly common in complex systems.
STAR Risk Assessment Framework
I have summarized a practical “STAR” risk assessment framework to help analyze the safety of state machine programs:
S (States): List all possible states, including normal and abnormal states. For example, in a motor control system, normal stop, emergency stop, forward, reverse, fault, etc.
T (Transitions): Analyze the transition conditions between all states. Check for conflicting conditions (multiple transition conditions being satisfied simultaneously) or missing conditions (unable to transition out of a certain state).
A (Actions): Check whether actions executed in each state are safe. For example, directly switching from high-speed forward to reverse is dangerous; it should first decelerate to stop before transitioning.
R (Recovery): Test the system’s recovery capability in abnormal situations. For instance, after a power outage, the system should return to a safe state rather than continue with the previous dangerous operation.
In PLC programming, we can visualize this process through a state table:
Current State | Condition | Next State | ActionStop | Start Button & Safety Door Closed | Forward | Start Motor ForwardForward | Stop Button or Safety Door Open | Stop | Stop MotorReverse | Stop Button or Safety Door Open | Stop | Stop MotorAny | Emergency Stop Button Pressed | Emergency Stop | Cut Power Immediately
3
Common Issues and Solutions
“System confusion when multiple buttons are pressed simultaneously”? Set priority handling logic, such as giving the stop button a higher priority than the start button.
“System state lost after power outage”? Use EEPROM or power-fail-safe registers to store critical states.
“Program logic flaws causing the system to enter an undefined state”? Add a default handling branch:
default:
emergencyStop();
currentState = STOP;
logError("Undefined state detected");
break;
4
Safety Reminders
In industrial environments, the safety of state machine programs directly relates to personal and equipment safety, and must be rigorously tested and verified. For large equipment control, hardware safety redundancy design must be implemented, such as adding independent hardware limit switches, thermal protection, and other physical safety measures, rather than relying solely on program logic.
I once troubleshot at a water treatment plant where, despite having a well-designed state machine, a sensor failure led to the system misjudging the state, nearly burning out the pump due to running dry. Later, triple protection was added for water level, current, and temperature, ensuring that even if the state judgment was incorrect, there would be hardware protection in place.
State machine programming is the soul of control systems, and risk assessment ensures that this soul does not cause harm. Next time you program, don’t forget to use the STAR framework to check your state machine logic; it may help you avoid many troubles. I hope every control system can operate stably and reliably, making work and life safer and more convenient.
