Device State Machines Overview

• Device state machines are deterministic models that define system behavior using states, events, transitions, and outputs.
• They are applied in control systems, IoT, and distributed computing for system monitoring, recovery, and optimal operation.
• Recent advances include automated visualization, statistical learning for model inference, and integration within cloud-edge architectures to improve performance.

A device state machine is a state-based model in which the behavior of a device, subsystem, or software-controlled artifact is specified by states, events, transitions, and outputs, or, in equivalent formulations, by recursive maps from finite event sequences to outputs. In the cited literature, the term spans several layers of analysis: ordinary deterministic machines and Moore transducers; control-layer mechanisms that detect hardware modes and assign state-specific parameters; semantic frameworks that combine control states with guards, actions, valuations, and event pools; and runtime notions of dynamic, volatile, or persistent state that must be recovered, synchronized, or learned (Yodaiken, 2016, Knapp et al., 2014, Teklemariam et al., 2018).

1. Classical formalization

A standard formalization treats the device as a deterministic Moore machine. In one formulation, a machine is written as $M=(A,S,\sigma_0,X,\delta,\lambda)$, where $A$ is the event alphabet, $S$ the state set, $\sigma_0$ the initial state, $X$ the output set, $\delta:S\times A\to S$ the transition map, and $\lambda:S\to X$ the output map. The same behavior can be represented by a sequence map $f_M:A^*\to X$, with

$$f_M(w)=\lambda(f'_M(w)), \qquad f'_M()=\sigma_0,\qquad f'_M(wa)=\delta(f'_M(w),a).$$

This representation shifts attention from explicit state graphs to functions on histories: the output after a finite event sequence becomes the primary object of specification (Yodaiken, 2016).

The same line of work defines sequence primitive recursive functions by recursion over words rather than over natural numbers: $f(w)=h(f'(w))$, $A$0, and $A$1. Every Moore machine induces such a function, and conversely every such function corresponds to a Moore machine tuple. This equivalence is significant because it preserves the classical deterministic automaton model while making large specifications more concise and more compositional. Composition is expressed through direct products and connector maps, for example

$A$2

with

$A$3

so each component remains a deterministic machine while its local input history is generated from global outputs and the enclosing event stream (Yodaiken, 2016).

An analogous formulation appears in circuit theory, where a device is treated as a state machine with output, equivalently a transducer. A machine may be represented directly by a string function $A$4, with $A$5 and $A$6, or by the Moore transducer tuple $A$7 with $A$8. This framework is used to specify gates, latches, SR latches, ripple-carry adders, timing constraints, and transients without leaving ordinary automata theory (Yodaiken, 2010).

2. Device operation, control layers, and optimization

In operational settings, a device/state machine need not be the physical controller itself. For superconducting RF cryomodules in PIP-II, the state machine is described as a passive control-layer mechanism that detects the current hardware state and applies the correct control metadata for that state. The paper is explicit that it is not the system controller, does not affect the hardware operation directly, is not for personnel or equipment safety, and has no user interactions with the state machine itself. Instead, the system monitors process variables, identifies the current state, reads the corresponding $A$9 configuration from a database, dynamically sets alarm limits and severities, adjusts archiving behavior, and identifies critical PVs (Hanlet, 2024).

That approach distinguishes static states from dynamic states. In static states, all PVs are expected to remain constant within dead bands, alarm limits are tight, and archiving is done in monitor mode. In dynamic states, some PVs are expected to change, those changing PVs get wider alarm limits covering expected excursions, and archiving is done in period mode. The implementation is in the EPICS framework using EPICS State Notation Language, with a passive state identifier, a relational configuration database, and a sequencer IOC that updates record fields such as LOLO, LOW, HIGH, HIHI, LLSV, LSV, HSV, HHSV, and ADEL, while switching archiver behavior to or from Monitor and Scan and pausing or unpausing PV archiving as required (Hanlet, 2024).

A different operational interpretation models smart devices as finite-state machines embedded in a Markov Decision Process. In that framework, the full state is $S$0, combining machine/device state and external state such as electricity price, weather, or human behavior. The device is a price taker, chooses actions from $S$1, evolves under $S$2, and maximizes expected discounted reward

$S$3

The paper differentiates four device types: optional loads that can be shed, deferrable loads that can be delayed, controllable loads with inertia, and storage devices that can alternate between charging and generating. In this usage, the device state machine is not merely descriptive; it is the substrate for optimal control under stochastic market signals (Turitsyn et al., 2011).

State-machine control also appears in infrastructure reliability. Microsoft Azure’s Fabric Controller tracks nodes through a larger state machine and, for the subset studied in the paper, uses states such as Ready, Unhealthy, Booting, PoweringOn, and HumanInvestigate. The central optimization problem is the intervention threshold $S$4 after a node becomes Unhealthy. With organic recovery time $S$5 and intervention cost $S$6, the expected downtime is minimized when the hazard rate satisfies

$S$7

The paper further generalizes from one threshold to many thresholds in a node state machine or Markov chain, where thresholds become interdependent and must be optimized jointly by numerical techniques such as gradient descent (Pandey et al., 2018).

3. Semantics of state, event, and concurrency

A substantial semantic literature argues that the meaning of “state” in device and system modeling is not self-evident. One line of work claims that a state is a timeless change: a subdiagram of an atemporal static model rather than a primitive temporal condition. In this view, the static model $S$8 is decomposed into changes or static states $S$9, and behavior $\sigma_0$0 arises only when time is imposed so that ordered static states become events. The transformation is summarized as

$\sigma_0$1

On this account, events, not states, are the genuine conveyers of behavior, and familiar finite-state descriptions of devices such as car transmissions are re-read as ordered structural fragments that only later acquire temporal chronology (Al-Fedaghi, 2020, Al-Fedaghi, 2020).

The same family of papers extends this critique through the Thinging Machine model, which is built from five generic actions: create, process, release, transfer, and receive. A thimac is defined as $\sigma_0$2, where $\sigma_0$3 is the machine side and $\sigma_0$4 the thing side. In this framework, a state is defined as a type of an event, and the paper explicitly concludes that in a TM, states are just compound events. The motivation is partly ontological and partly methodological: state-machine terminology is described as conceptually muddled and graphically unwieldy, especially when software models require integration between structural and behavioral views (Al-Fedaghi, 2022).

A more orthodox semantic formalization appears in the institution-theoretic treatment of simple UML state machines. There, guards are formulas over variables, actions are valuation-to-valuation transitions that may emit messages, and a state machine structure $\sigma_0$5 operates over configurations combining valuation, event pool, and control state. Behavioral state machines discard unhandled events, whereas protocol state machines move to an error state. The interleaving product then composes multiple state machines into one concurrent system, with the composite control state as a pair and communication realized by routing messages that are also legal events of the partner machine (Knapp et al., 2014).

Concurrency becomes especially intricate in UML/PSSM doActivity semantics. A doActivity is not merely “the state doing work”; it is an independently executing behavior associated with a state. According to the PSSM analysis, it starts after state entry behavior has completed, runs concurrently with the state machine’s run-to-completion processing, registers its own accepters, can compete non-deterministically with the state machine for the same event, and is destroyed before the state’s exit behavior executes. The paper identifies more than 20 issues reported to the standardization committee and studies 11 patterns showing that doActivities can introduce race conditions, event loss, delayed or reordered signaling, and nondeterministic event consumption even in models that appear straightforward (Elekes et al., 2023).

4. Dynamic runtime state and recovery

In constrained IoT systems, device state often includes volatile runtime information that is neither part of the immutable firmware image nor reducible to the current sensor reading. The relevant paper distinguishes dynamic states from static/device firmware state and from sensor resource state. Dynamic states are information created as a result of interactions and stored in volatile memory on constrained nodes, including runtime configuration changes, observe/notification relationships and their counters, binding relationships, and dynamically deployed code or RESTlets. These states are lost on reboot and can lead to erroneous results or malfunctions if not restored (Teklemariam et al., 2018).

The proposed recovery architecture centers on a State Directory placed at the LLN gateway. Because the gateway is non-constrained and most state-changing interactions originate from outside the LLN, it can intercept communication, inspect packets at the application layer, store metadata needed to recreate state later, and replay the original requests when a node reboots. The paper describes an implicit lifecycle: state generation, state capture, normal operation and updates, loss event, startup detection, and restoration. State-changing interactions include PUT requests, observe registrations and notifications, flexible binding relationships, and runtime deployment of application code through CoAP block-wise transfer (Teklemariam et al., 2018).

The restoration logic is transparent to client and sensor. When a node sends a registration request at startup, the gateway checks whether the node already has State Directory entries; if so, it replays stored PUTs, re-establishes observe relationships, restores bindings, and reloads or retransfers dynamic code. The paper reports functional recovery of two PUT states and one observe relationship, with observe notifications resuming after reboot. It also reports that proactive node-State Directory registration delay grows with hop count but remains under about 1 second for 3 hops with ContikiMAC and under 100 ms for 3 hops with NullRDC, while interception overhead at the gateway is less than 100 ms (Teklemariam et al., 2018).

5. Learning, analysis, and visualization

Device and finite-state models are also subjects of tooling for explanation and inference. FSMIPR, “Finite State Machine with Input and Process Render,” is an automatic visualization tool for teaching and learning finite state machines. An educator supplies a machine according to its formal definition and an input string; the tool, implemented in Python with Automata-lib, Manim, and GraphViz, generates a video showing a state diagram, formal transition table, remaining input string, and synchronized highlighting of the current transition and state. In the example described, when the machine is in $\sigma_0$6 and reads $\sigma_0$7, the transition $\sigma_0$8 is highlighted, the symbol $\sigma_0$9 is removed from the displayed input, and the matching table entry is highlighted simultaneously (Bennett-Manke et al., 2024).

State-machine learning addresses a different problem: inferring compact models from traces. A streaming method for probabilistic deterministic finite automata uses count-min sketches to summarize each state’s future traces and the red-blue framework to limit merge candidates to a red core and blue fringe. Implemented in FlexFringe and evaluated on the PAutomaC dataset, the method reported average error 2.34 with $X$0, compared with 3.14 for Alergia, and 2.29 with $X$1. Runtime was similar to Alergia, while memory usage in streaming mode was dramatically lower than in batch mode; example values include Scenario 8 with Alergia batch 1 GB versus sketching stream 95 MB and Scenario 21 with 2.049 GB versus 56.58 MB (Baumgartner et al., 2022).

These developments indicate that device state machines are not only design abstractions but also executable pedagogical artifacts and learnable statistical objects. This suggests a broadening of the concept from hand-authored transition systems toward automatically rendered simulations and data-driven reconstructions, while remaining within the state-machine idiom (Bennett-Manke et al., 2024, Baumgartner et al., 2022).

6. Distributed and collaborative device state machines

The representation of large systems as deterministic state machines was explicitly proposed for operating systems, databases, real-time control, distributed and composite systems, and distributed consensus. In that work, sequence maps rather than state diagrams or tables are presented as more concise and better suited to describing behavior and compositional architecture, and the framework is used to specify or verify counters, control systems, memory arrays, schedulers, asynchronous networks, and the Paxos distributed consensus algorithm. The main theorem for Paxos safety is stated as

$X$2

showing that if two proposals win, they must have the same value (Yodaiken, 2016).

A recent development pushes the state-machine model into the Cloud-Edge-IoT continuum. Collaborative State Machines are presented as a programming model in which an application is a collection of state machines that run autonomously, communicate via events, share data through persistent data, and may be distributed across different layers of the continuum. The model uses a dual-state concept: control state and data state. It supports local, static, and persistent data; internal, external, and global events; entry, exit, while, and after actions; and shared or distributed memory modes. The runtime system, Cirrina, interprets CSML, uses ZooKeeper for synchronization, supports NATS and Kafka for events and persistent data, and deploys on Kubernetes, Docker Swarm, and AWS ECS. The evaluation reports a 12x increase in throughput in a stress test, a 2.3x improvement in processing time per processed image in a surveillance system, and a 55x reduction in total processing time for a smart factory use case (Etheredge et al., 29 Jul 2025).

Viewed together, these strands show that the device state machine has evolved from a compact deterministic formalism into a family of models for specifying behavior, architecture, timing, optimization, recovery, collaboration, and execution. The common invariant is that device behavior is organized around state-dependent reaction to events; the major differences concern what counts as state, how much data and time are internalized into the model, and whether the machine is used primarily for specification, control adaptation, runtime recovery, or distributed execution (Yodaiken, 2016, Etheredge et al., 29 Jul 2025).