Using the Actor Model for High-Rate Industrial Event Processing in IIoT

The Actor Model in IIoT: Building Resilient Concurrent Systems

Across years of building industrial software, teams often encounter a common architectural scaling limit: treating high-velocity factory data identically to standard transactional IT data.

When a standard REST API backend is connected to a traditional relational database (like PostgreSQL or Microsoft SQL Server), PLCs are often mapped directly to database tables. This approach is frequently sufficient for localized pilot projects with low sensor counts.

However, transitioning to full-scale production introduces significant challenges. A high-speed packaging line can generate tens of thousands of state changes per second, per line. If a system attempts to write all these events simultaneously to a standard SQL database, it often encounters table locks, thread pool exhaustion, and latency spikes that delay dashboard updates and rule execution. Traditional IT architectures often struggle with the high concurrency and velocity requirements of factory floor data.

To build a low-latency IIoT platform that scales across multiple sites, the fundamental approach to state and concurrency must be re-evaluated. This is where the Actor Model becomes highly relevant.

• µs-level: In-process actor dispatch (single-node, no network I/O)
• High concurrency: Concurrent actors per node (hardware dependent)
• High availability: Supervision-tree recovery potential (topology-dependent)

Important: Latency figures assume in-process message passing on the same machine. Remote actors across a network add serialization and network transit on top. Results heavily depend on workload profile, hardware capacity, and deployment topology.

Concurrency Challenges: Threading vs. Factory Scale

To understand the Actor Model, it is helpful to examine why traditional shared-state Object-Oriented architectures often struggle at industrial scale.

In a standard C# or Java application, if 5,000 sensors send data at the exact same moment, the runtime relies on thread pools, async I/O, and internal queues rather than spawning 5,000 discrete OS threads. Under sustained burst load from industrial equipment, this can still create queue growth, lock contention, and latency spikes.

If two sensor events try to update the same machine state simultaneously, a "race condition" can occur, potentially leading to inconsistent state calculations. To prevent this, engineers implement "Locks."

Lock contention limits throughput. While Thread A updates a machine's state, Threads B, C, and D must wait. As data volume increases, this contention compounds. Servers end up spending significant CPU cycles managing thread synchronization rather than processing actual operational data.

Enter the Actor Model: Distributed Decoupling

The Actor Model is a mathematical model of concurrent computation proposed in 1973. It forms the backbone of highly reliable distributed systems (such as Erlang-based telecommunications infrastructure).

In this model, the fundamental unit of computation is the "Actor." An Actor is a microscopic, highly isolated execution context. It encapsulates its own private state, its specific behavior, and a private "Mailbox."

The core principles are:

1. No Shared State: Actors do not share memory. This drastically reduces the need for application-level locks, as isolated execution contexts do not compete to modify the same mutable variables.
2. Asynchronous Messaging: Actors communicate only by sending fire-and-forget messages to each other's Mailboxes.
3. Sequential Processing: An Actor reads messages from its Mailbox strictly one at a time. It processes the message, updates its private state, and then moves to the next message.

How This Applies to the Factory Floor

Consider a factory floor with 1,000 physical motors. In an architecture designed for the Unified Namespace, the system provisions 1,000 independent "device actors" in memory.

• Each device actor operates as an isolated process in memory.
• It acts as the explicit digital twin for one specific physical motor.
• When the physical motor generates 50 vibration alerts in a single second, those messages are routed directly into that specific device actor's mailbox.
• The actor processes them one at a time, evaluates any associated Industrial Rule Engine logic, updates its internal state, and outputs the result. In-process message handling is measured in microseconds; end-to-end latency depends on the network and on storage.

Because these actors do not share memory, the underlying runtime can distribute their execution across all available CPU cores in parallel with minimal contention.

The Core Distributed Engine

Building a resilient, actor-based system requires careful distributed systems design. To achieve low-latency telemetry across highly distributed OT networks, modern IIoT architectures often rely on high-performance, cross-platform implementations of the Actor Model.

In-Memory Speed, Database Persistence

By maintaining real-time factory state in memory across isolated actors, platforms can update metrics like OEE as events arrive, without a database round trip on every change. To fulfill historical requirements, actors asynchronously persist data to time-series databases (such as ClickHouse) in the background, ensuring database write-latencies do not block live stream processing. In Proxus, that store is the columnar historian on the hub.

Resilience Through Supervision Trees

Industrial networks are inherently hostile environments. Sensors lose power, gateways drop connections, and network switches fail.

In an Actor system, components are organized in a hierarchy known as a Supervision Tree. If a protocol actor (responsible for maintaining a TCP socket with a Siemens PLC) crashes due to a sudden network timeout, its "Parent Actor" detects the failure, restarts that specific child actor, and resumes data collection. This containment strategy isolates failures and prevents cascading system crashes.

Location Transparency and Horizontal Scaling

Some actor frameworks offer location transparency: an alarm actor can send to a machine actor without knowing whether it runs on the same server or on another node, and the framework routes the message across the network. That makes it possible to scale by adding nodes to a cluster, at the price of cluster membership, partition handling and remote failure modes.

Many industrial systems choose a simpler split. Actors stay local to each process (one per edge gateway or server), and the sites talk to each other through a durable message bus that can buffer when a link drops. Each process gets the concurrency benefits of actors, while the WAN boundary is handled by a component built for it, which matters for Edge Computing Patterns operating at scale.

Bypassing the Relational Bottleneck

Attempting to force high-velocity Industry 4.0 data through traditional relational database architectures often results in latency penalties and inflated cloud compute costs under heavy load. By leveraging actor-style concurrency, modern IIoT platforms can process massive volumes of industrial events while maintaining the low-latency guarantees required by operational teams.

Architecture Trade-offs: When this may not be suitable

• Low-frequency telemetry: Use cases monitoring ambient temperature every 15 minutes may not justify the architectural complexity of a fully distributed actor system.
• Single-line deployments: Small, isolated plants might achieve their goals faster with simpler, monolithic architectures.
• Safety-critical control: Hard real-time, safety-critical closed-loop control must permanently reside within the PLC/Safety PLC layer.

Performance metrics and outcomes will always vary based on specific workloads, physical hardware, and network topologies.

Frequently Asked Questions

What is the Actor Model in simple terms?

Each "actor" is an independent, lightweight computational entity with its own private state and mailbox. Actors communicate exclusively through asynchronous messages, which minimizes shared memory access. This strongly reduces common threading hazards (like deadlocks and race conditions), though engineers must still carefully design for message ordering, backpressure, and supervision.

How does the Actor Model compare to other approaches?

References

1. Carl Hewitt, Peter Bishop, and Richard Steiger, "A Universal Modular ACTOR Formalism for Artificial Intelligence" (1973) - The seminal paper defining the Actor Model of computation, indexed in the ACM Digital Library.
2. Microsoft Orleans Documentation - Official overview of the virtual actor pattern and distributed systems scalability for .NET.
3. Erlang/OTP Concurrent Programming Guide - Official reference for Erlang's industrial-grade implementation of actor-style concurrency.