---
title: Collaborative State Machines in Cloud-Edge-IoT
url: https://www.emergentmind.com/topics/collaborative-state-machines-csm
type: topic
---

# Collaborative State Machines in Cloud-Edge-IoT

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 [2507.21685]. 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 | [2507.21685] |
| **Concurrent State Machines** | Concurrent, asynchronous, signal-communicating components with Boolean transition formulas | [1703.05541] |
| **Communicating State Machines** | Local participant specifications for multiparty protocols over asynchronous FIFO communication | [2501.16977] |
| **Coded State Machine** | Coding-theoretic execution of multiple state machines under Byzantine faults | [1906.10817] |

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 [1702.07951].

## 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 [2507.21685].

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 [2507.21685].

## 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 [2507.21685].

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 [2507.21685].

## 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** [2507.21685].

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 [2507.21685].

## 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 [2507.21685].

| 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 [2507.21685].

## 6. Related formalisms, verification traditions, and limitations

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** [1703.05541]. A later timed extension, **Timed Concurrent State Machines**, combines coincidence-based concurrency with clocks, testing automata, and **Region Concurrent State Machines** [1710.07997]. 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 \(\Sigma_{\text{ext}}\) and \(\Sigma_{\text{int}}\), and operationalize atomic event cascades through **XQueue** [1702.07951].

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 [2306.09068]. 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 [2501.16977]. 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 [2507.21685].

Source: https://www.emergentmind.com/topics/collaborative-state-machines-csm