Collaborative State Machines in Cloud-Edge-IoT

Updated 7 July 2026

Collaborative State Machines are reactive, event-driven models that deploy distributed state machines across Cloud-Edge-IoT layers using events and persistent data.
The CSML language, a JSON-based extension of Harel statecharts, structures applications as trees of state machines with clear state, transition, and action semantics.
Empirical evaluations report up to 12x throughput improvement and notable reductions in processing time compared to traditional Serverless Workflow models.

Collaborative State Machines (CSM) denotes a programming model for reactive, event-driven, and stateful distributed applications across the Cloud-Edge-IoT continuum in which an application is composed of state machines that collaborate autonomously and can be distributed across different continuum layers. In the 2025 formulation, collaboration is realized through events and persistent data, state is treated as a first-class concern, actions and service invocations are embedded in states and transitions, and the data model distinguishes local, static, and persistent data (Etheredge et al., 29 Jul 2025). The acronym is not historically uniform, however, and adjacent arXiv literatures use CSM for several distinct state-machine traditions.

1. Terminology and scope

The current term Collaborative State Machines refers most directly to the Cloud-Edge-IoT programming model introduced in 2025, but the acronym CSM is also used for several other machine models in the literature. This suggests a broader family resemblance among compositional state-machine approaches, while not erasing substantial semantic differences among them.

Term using “CSM”	Defining emphasis	Representative source
Collaborative State Machines	Reactive, event-driven, and stateful applications across the Cloud-Edge-IoT continuum	(Etheredge et al., 29 Jul 2025)
Concurrent State Machines	Concurrent, asynchronous, signal-communicating components with Boolean transition formulas	(Daszczuk et al., 2017)
Communicating State Machines	Local participant specifications for multiparty protocols over asynchronous FIFO communication	(Stutz et al., 28 Jan 2025)
Coded State Machine	Coding-theoretic execution of multiple state machines under Byzantine faults	(Li et al., 2019)

The 2025 Collaborative State Machines model is therefore best treated as a specific programming model, not as the unique referent of the acronym. At the same time, the neighboring traditions are technically relevant because they address many of the same concerns: composition, explicit interaction, global-versus-local semantics, verification, and deployment under distributed constraints (Murr et al., 2017).

2. Core programming model

The CSM Language (CSML) is a JSON-based description language whose core abstractions are CollaborativeStateMachine, StateMachine, State, Transition, Guard, Action, Event, Variable / VariableReference, and Property. A CSM description is a tree: the root is a collaborative state machine; it contains one or more state machines; state machines contain states and may also contain nested state machines. The model is explicitly inspired by Harel statecharts, but it extends that setting by modeling an application as multiple distributed state machines rather than a single isolated machine (Etheredge et al., 29 Jul 2025).

At the top level, a CollaborativeStateMachine contains a memoryMode, one or more stateMachines, and optional persistentData. The memoryMode is either distributed or shared, and it determines whether top-level state machines may be distributed across resources. Persistent data declared at this level is globally accessible across the whole collaborative state machine. A StateMachine defines one or more states, may include nested state machines, may declare reusable guards and actions by name, and may declare local and persistent data. The paper states that at any given moment only one state is active within a state machine.

A State may be initial, terminal, or intermediate. Each state machine must have exactly one initial state. States can define entry, exit, while, and after actions, and they support two kinds of transitions: always transitions, which require no event and are used for sequential progression, and on transitions, which are event-triggered. A Transition may be external, when target points to another state in the same state machine, or internal, when the target is omitted and the machine remains in the current state. For internal transitions, entry and exit actions are bypassed, while while and timeout actions continue.

Actions are central to the model. They support service invocations, data creation/assignment/deletion, event raising, timeout setup/reset, and matching. The InvokeAction names a service type, not a concrete implementation; runtime selection decides which implementation to execute and where. This is the mechanism by which the model decouples application logic from compute and data-processing services. Guards are Boolean expressions over the variables in scope, formally given as $E : \mathbb{R}^n \to \{\text{true}, \text{false}\}$ , and all guard expressions must evaluate to true collectively for the guarded transition to fire (Etheredge et al., 29 Jul 2025).

3. Collaboration, state, and execution semantics

Collaboration is implemented through a hybrid of event-based coordination and shared persistent data. The event system distinguishes internal events, visible only to the state machine that raised them; external events, raised by one state machine and received by other state machines that have subscribed to them; and global events, visible to every state machine. The paper also allows peripheral events from external software or devices. Persistent data provides a globally accessible repository across the collaborative state machine, so the model combines message/event-based and shared-data-based interaction (Etheredge et al., 29 Jul 2025).

The state model is explicitly dual-state. One part is the inherent state of state machines, meaning their currently active states and configurations. The other part is persistent data / shared state. The data model then refines this further into local data, static data, and persistent data. Local data is created each time a state machine or state is created or entered and destroyed once it is terminated or left. Static data is state-specific and preserved across exits and re-entries of that state. Persistent data remains globally available for the application duration. This division is one of the model’s main departures from workflow-centric systems that primarily expose service or task input-output data.

Scoping depends on the memory model. In shared memory mode, each component $C$ can access local data within scope $C^\uparrow$ , meaning the component itself and its ancestors up to the root $C_0$ . In distributed memory mode, the root level lacks shared memory and cannot declare or access local data, while a state machine and its nested components always operate in shared memory mode within that local scope. The paper presents this as an information-hiding rule: components can access ancestor data but not sibling data.

Execution is defined per individual state machine, even though multiple state machines execute concurrently. A state machine instance has status

$\mu = \langle SM^\uparrow, E, \Theta \rangle$

where $SM^\uparrow$ is the scope, $E$ is the input-event set, and $\Theta$ is the active configuration. The execution model imposes six principles: changes during a step are effective immediately; an event is available during one step only; a state machine is alive if the active configuration contains no terminal state; the execution of a step may take time; actions are executed sequentially; and exactly one state must be active in the active configuration, written as

$|\Theta|=1.$

The operational skeleton is given by Procedure ExecuteStep(μ) and Procedure HandleEvent(e, μ), in which SelectOnTransition, SelectAlwaysTransition, Execute, and SwitchState realize the step semantics. Transition selection must return exactly one transition; if one event would imply activating two atomic states, the model treats that as invalid non-determinism (Etheredge et al., 29 Jul 2025).

4. Runtime system and deployment architecture

The runtime implementation is Cirrina. It is open-source, implemented in Java, fully distributable, and said to support all CSML features. It uses GraalVM for native compilation on x86-64 and ARM(64). The runtime is designed for deployment across cloud, edge, and IoT layers and can run on Kubernetes, Docker Swarm, and AWS ECS (Etheredge et al., 29 Jul 2025).

The paper describes a job-oriented execution architecture. A job is submitted to ZooKeeper; runtimes watch ZooKeeper for jobs; each runtime checks whether it is eligible to execute the job; eligible runtimes indicate capability; the most suitable runtime is selected; and that runtime instantiates a state machine instance from the CSM description. A submitted job contains the CSM description, service implementation descriptions, the state machine name to instantiate, instance data, state machine instances to bind events to, and conditions for runtime eligibility. Event handling and persistent data use external systems including NATS and Kafka, while ZooKeeper provides runtime synchronization.

This runtime architecture operationalizes the paper’s service-decoupling claim. A CSM model invokes service types, not fixed implementations. Runtime choice may depend on locality, resource capabilities, context, and user-supplied properties. The paper presents this as a way to avoid static application descriptions and to support data-driven runtime behavior. It also states that current work leaves several runtime questions only partially specified, including explicit fault-recovery semantics, detailed scaling policies, and formal scheduling algorithms (Etheredge et al., 29 Jul 2025).

5. Empirical evaluation and reported use cases

The evaluation is performed on the Grid'5000 testbed and covers three use cases: a railway crossing stress test, a surveillance system, and a smart factory. The reported baseline is primarily Serverless Workflow, implemented via Apache SonataFlow, and the reported gains are substantial in all three settings (Etheredge et al., 29 Jul 2025).

Use case	Baseline / comparison	Reported result
Railway crossing stress test	Remote service invocations + persistent data vs local service invocations + local data	12x throughput improvement
Surveillance system	Serverless Workflow / Apache SonataFlow	2.3x lower processing time per processed image
Smart factory	Serverless Workflow / Apache SonataFlow	55x reduction in the abstract; 56x in the evaluation and conclusion

In the surveillance system, the paper reports a mean processing time per image of 763 ms with standard deviation 38 ms for Serverless Workflow and 335 ms with standard deviation 49 ms for CSM. In the smart-factory study, it reports time to assemble 1000 products as 2904 s for Serverless Workflow, 144 s for CSM with one instance per runtime, and 52 s for CSM with five instances per runtime. The same section notes a 2.8x reduction when increasing CSM instances per runtime from one to five, and it attributes the larger improvement over the workflow baseline to higher sustainable event rates, advanced event semantics, and lower overhead from state-machine-based organization.

The paper also gives small productivity metrics. For the surveillance system, it reports 344 lines of code and 16 states for Serverless Workflow, versus 244 lines of code and 5 states for CSM; the number of workflows/state machines is 3 versus 2. For the smart factory, it reports 1264 lines of code and 42 states for Serverless Workflow, versus 922 lines of code and 22 states for CSM, with 6 workflows/state machines in both versions. No user study is reported; the productivity argument is based on implementation metrics rather than human-subject evidence (Etheredge et al., 29 Jul 2025).

Several adjacent arXiv traditions illuminate what is specific about Collaborative State Machines and what remains shared across state-machine research. Concurrent State Machines model systems composed of several units that operate concurrently, asynchronously, and communicate by signals; they are represented as labeled directed graphs whose transitions are guarded by Boolean formulas over simultaneously present signals, and the COSMA 2.0 environment supports graphical editing, symbolic product construction, and temporal verification over a Reachability Graph (Daszczuk et al., 2017). A later timed extension, Timed Concurrent State Machines, combines coincidence-based concurrency with clocks, testing automata, and Region Concurrent State Machines (Daszczuk, 2017). In a more software-architectural direction, Multiple Coupled Finite State Machines (McFSMs) make couplings explicit by letting state transitions generate internal events; they define a global state $Q_1 \times \ldots \times Q_n$ , distinguish $C$ 0 and $C$ 1, and operationalize atomic event cascades through XQueue (Murr et al., 2017).

Other nearby lines place the collaborative semantics in the protocol layer rather than the deployment layer. In Behaviorally Typed State Machines in TypeScript for Heterogeneous Swarms, a swarm protocol is an “idealized global view of the cooperation of machines of different roles,” and protocol well-formedness plus projection conformance imply eventual consensus on overall state progression without further coordination (Kuhn et al., 2023). In the Automata-based Multiparty Protocols framework, Protocol State Machines (PSMs) serve as global specifications and Communicating State Machines (CSMs) as local participant specifications, with a sound and complete PSPACE projection for tame PSMs (Stutz et al., 28 Jan 2025). These formalisms differ in semantics and target domain, but they reinforce a common structural pattern: local state machines, an explicit global interaction view, and a nontrivial relation between the two. This suggests that the 2025 Collaborative State Machines model belongs to a larger research space of compositional state-machine systems, even though its own emphasis is the Cloud-Edge-IoT continuum.

The 2025 CSM paper is also explicit about limitations. It does not provide a full formal account of distributed consistency, end-to-end event-delivery guarantees, or fault recovery. Transition selection must yield exactly one transition, so conflicts that would activate two atomic states are invalid. The paper notes a trade-off in distributed memory: it improves scalability, parallelism, and decentralization, but may increase data-transfer times across resources. The empirical comparison is concentrated on Serverless Workflow / Apache SonataFlow, rather than on all related systems discussed in the paper. Its future-work agenda centers on advanced scheduling techniques for both state machine instances and runtime placement across the continuum (Etheredge et al., 29 Jul 2025).