There are many applications in the industrial automation realm that benefit from state machines. Therefore, it was surprising to hear from an industrial programming specialist who says he does not like state machines and was adamant about them not working.
For a systems-focused person, this is sacrilegious but let’s have a go thinking about it. What is a state? What is a state machine? When do you use one? Why would a state machine fail in an industrial process application in a programmable logic controller?
A state is a condition or mode of operation, or situation. Many machines have an initialization state where everything is checked out for a health status, motion is homed, temperatures and levels checked. This usually happens after powering up. The result of initialization is whether the machine has permission to run. If there is not permission to run, then an alarm is set, and the operator must figure out the problem. On a basic premise, machines have four states: off or on; initializing or initialization; ready to run or faulted; and running. What mode you are in for running is also a category of a state and may be defined as manual or automatic.
What is a state machine? Events or triggers are used for transitions to move about states. A state machine is a model that consists of states, transitions, inputs and outputs. There are two types of state machines. Deterministic finite automation (DFA) machines and non-deterministic finite automation (NFA) machines. A DFA has exactly one transition for each input. An NFA can go to more than one state with a given input. Algorithms are used to wrangle NFAs as NFAs tend to be complex.
Most machines in industry fit into the NFA category and therefore are complex. The problem with this is that operational technologists are not as familiar with state machines as traditional programmers. Also, state machines are not something that can really be programmed on the fly and require forethought.
Transitions are key. For instance, if a machine is in a “ready to run” state, that means that its initialization was completed, and it is waiting on a trigger to run. This trigger is a start-button input or, if it was already running, then a function completed, so that the cycle can restart. Permissives would be used to create a transition. Problems occur when transitions are not well-defined and permissives are not quantified and captured in the code.
Traditional PLC applications apply state machines when they use sequential control. Examples are filling a tank, loading a conveyor or moving a coil into a load position or unload position. The beauty of an NFA is that there can be many substates. Failures occur in state-machine programming when programmers do not map states on paper before programming and when all states or conditions to transition are not properly defined. These are points of failure in the operational technology space.
One of the newest techniques that help with state machines in operation technology is unified namespace (UNS). Categorization of machine states is simplified in a UNS architecture—for instance, a cold mill requires a cooling system. UNS allows all the inputs to be categorized under CoolingSystem.Inputs.XXX for however many inputs that you need to include—sprays, oil levels, temperatures, anything related to the cooling system. States for the cooling system can be defined under CoolingSystem.States.XXX, and then transitions may be programmed under CoolingSystem.Transitions.XXX. Finally, there will be an output from the states. CoolingSystem.StateX.Output.XXX. All of this may be housed under a routine for cooling systems and integrated at some point in the cold mill “running” state for monitoring the cooling system and the cooling system activities. However, to get this correct, software engineers need to build truth tables and to note transitions, inputs and outputs in a manner that allows a state that is viable, and this requires that they also build code to alleviate false states.
Get your subscription to Control Design’s daily newsletter.
A false state is a state that is possible but not probable and would be better off trapped as unallowed by the software, such as user inputs that would cause a divide by zero. Or an action that would cause a failure. For instance, if the work roll in a press is not being sensed, why would a system allow the operator to thread the machine? Operational technologists use truth tables in safety and other areas; state machines beg for that kind of thorough process, as well. The reason is so false states are ruled out and coded against, so the state machine does not get confused.
State machines or sequencers are tools that can increase data consistency and speed up the processing power of the programmable logic controller (PLC), but they also can cause failure in a poorly written framework. State machines are not something to be done in a hurry.
Logic errors and transition problems are typically related to poorly defined conditions for transitioning to the next state or missing transitions. Logic for state transitions can lead to unexpected behavior and the machine getting stuck. If inputs that change state outside the intended timing of the state machine are used, then this can cause unexpected transitions or get the machine stuck in a loop. If multiple conditions that enable transitions are true simultaneously, it can lead to unpredictable behavior and the machine’s getting stuck. If a programmer uses logic that can latch on or off unexpectedly, then the machine can get stuck. Another consideration is when the code is read by the PLC because timing problems can create race conditions, which will affect transitions of states negatively. If a programmer really wants practice on states, then it’s advisable to build their own sequencer from scratch and use bit patterns to move between states in a practice mode before implementing a state machine for machine operations.
