PaperlayerView exact revision on arXiv

Source-linked AI summary

A Kafka-Centric Communication Fabric for Near-Real-Time, Cloud-Replicated Closed-Loop Manufacturing Process Control

Zhengyang, Gu, John Burtenshaw, Joseph E. Hernandez, Chris Couch

arXiv:2610.00258v1cs.NI

TL;DR

PLCs provide deterministic actuation but are not designed for the scalable data and analytics functions increasingly used in manufacturing. This paper presents a production communication fabric built from standard components, combining a shared Kafka stream, an OPC-UA bridge, timestamped sample arrays, and edge-to-cloud replication. It reports millisecond-scale broker transport latency and soft near-real-time behavior, without hard-real-time guarantees.

  • Problem

    PLCs handle deterministic actuation but are not designed for higher-level functions such as predictive maintenance, machine-learning inference, and cross-facility analytics, which need a scalable, durable, observable communication substrate.

    Source: §I · p. 1

  • Method

    The production architecture uses one Kafka stream per line, a timestamp-aligning OPC-UA bridge, packed timestamped samples, and edge-authoritative cloud replication.

    Source: §I · p. 2, §III · p. 2

  • Results

    Broker transport latency is on the order of milliseconds, two to three orders of magnitude below the one-second sampling cadence, and the system runs on production lines for closed-loop correction, defect detection, and virtual sensing.

    Source: A. Measured Kafka transport latency · p. 6, D. In production · p. 7

  • Takeaways & Limitations

    The production experience supports a reusable architectural pattern for closed-loop industrial communication using standard components, with the edge continuing local control during WAN outages.

    Source: §XII · p. 8

    The system does not bound worst-case latency, and its direct measurement covers broker transport rather than the full sense-to-actuate loop.

    Source: §XI · p. 8

Abstract

from arXiv · show

Smart manufacturing needs to move sensor data off the plant floor, react to it, and feed decisions back to actuators within bounded time. Programmable logic controllers (PLCs) handle fast, deterministic, safety-critical actuation, but they are not designed for the higher-level functions required by Industry 4.0, such as predictive maintenance, machine learning inference, and cross-facility analytics. These functions need a scalable, durable, and observable communication substrate. We present the communication architecture of a production system that provides this substrate and closes the loop back to the plant in near real time. The design is built from industry-standard components: Apache Kafka as the streaming backbone, OPC-UA for PLC connectivity, a relational time-series database for persistence, and JSON for serialization. The novelty is architectural. We show how these standards are integrated for closed-loop industrial control through four design choices: a single event stream per production line serves control, monitoring, machine learning, and durable recording, allowing one producer to serve many independent consumers; a protocol bridge converts polled OPC-UA traffic into publish/subscribe streams, aligns per-signal timestamps to a common time base to remove cross-signal jitter, and provides a symmetric actuation path; a transport technique carries sub-second process dynamics at a coarser publication cadence by packing timestamped samples into fixed-order arrays; and an edge-to-cloud replication scheme keeps the edge authoritative, so local control continues during wide-area network outages while cloud analytics operate on replicated data. We describe the loop latency budget, report measured broker transport latency, and discuss operational experience. The system provides soft, near-real-time behavior rather than hard real-time guarantees.

I. INTRODUCTION

PLCs provide deterministic, safety-critical actuation but lack the scalable, durable, observable substrate needed for higher-level manufacturing analytics and control. This paper composes standard components into a production communication fabric for near-real-time closed-loop control.

I. INTRODUCTION

  • The fabric addresses PLC limitations in aggregating line data, retaining history, running models, and supporting functions such as predictive maintenance and closed-loop optimization.These higher-level functions motivate a communication substrate beyond the PLC network.Source: §I · p. 1
  • A production system lifts equipment data from PLCs through OPC-UA to Kafka, where control, monitoring, ML inference, and durable recorders consume the stream; data is also replicated to cloud analytics.The architecture is deployed across multiple manufacturing facilities.Source: §I · p. 2
  • One shared event stream per production line serves control, monitoring, machine learning, and recording, letting one published stream serve many consumers.This is an architectural contribution built from standard protocols and brokers, not a new wire format.Source: §I · p. 2
  • The protocol bridge turns polled OPC-UA traffic into publish/subscribe streams, aligns per-signal timestamps to a common time base, and provides a symmetric actuation path.The design targets jitter-free multi-signal snapshots.Source: §I · p. 2
  • Timestamped samples packed into fixed-order arrays carry sub-second process dynamics over a coarser one-second publication cadence.Consumers can select an aggregate or the full-resolution series.Source: §I · p. 2
  • Edge-to-cloud replication keeps the edge authoritative so local control continues during WAN outages while cloud analytics use replicated data.The system targets a one-to-two-second soft-real-time loop, not hard-real-time guarantees; hard-real-time interlocks remain in the PLC.Source: §I · p. 2

II. BACKGROUND AND RELATED WORK

The background contrasts PLC-facing industrial protocols with the needs of analytics consumers and plant-to-cloud operation. It motivates a durable streaming layer and an edge-authoritative design that keeps control available during cloud-link outages.

A. How machines speak: OPC-UA and the fieldbus

  • OPC-UA provides a common, vendor-neutral industrial language, but its client-server shape is not designed to feed many changing analytics consumers; TSN-based protocols instead provide complementary hard-real-time determinism.Studies report that a single OPC-UA server slows as concurrent clients increase.Source: A. How machines speak: OPC-UA and the… · p. 2

B. Why a streaming layer: the durable log

  • Kafka’s durable, replayable log lets many consumers read independently at their own pace, unlike message buses typically lacking replayable history.The cited comparisons of RabbitMQ/AMQP and MQTT with Kafka address latency, throughput, and fan-out –.Source: B. Why a streaming layer: the durable… · p. 2

C. How the pieces fit a plant: edge, cloud, and consistency

  • The plant-to-cloud design chooses local availability over global consistency during a network partition, keeping the edge available to the control loop.The passage frames this as the CAP trade-off [24].Source: C. How the pieces fit a plant: edge,… · p. 2

III. SYSTEM ARCHITECTURE

The manufacturing line is the deployment and communication unit: its edge services share a Kafka stream, while the Protocol Bridge alone connects to PLCs through OPC-UA. Publishing once lets independent services consume the same durable stream at their own pace.

III. SYSTEM ARCHITECTURE

  • Each line runs cooperating microservices on an edge node, with Kafka as their shared communication substrate and the manufacturing line as the deployment unit.The Protocol Bridge is the only service that speaks OPC-UA directly; the line also includes recording, monitoring, virtual-sensor, and controller services.Source: §III · p. 2, Figure 1 · p. 3

A. One stream, many consumers

  • Independent services use the shared stream for control, monitoring, machine-learning predictions, and durable recording.Each consumer reads at its own pace, so a latency-sensitive controller and a throughput-oriented recorder can use the same data.Source: §III · pp. 2–3, A. One stream, many consumers · p. 3
  • The bridge publishes equipment data once to Kafka, allowing independent consumers to read and replay the log without coupling producers to consumers.New or recovering services can warm their working buffers from history before going live.Source: A. One stream, many consumers · p. 3, Figure 2 · p. 3

B. Data model and serialization

The system serializes readings as JSON and uses one Protocol Bridge for OPC-UA acquisition and control write-back. On the read path, the bridge republishes source-timestamped readings to Kafka, where consumers can read without adding PLC load.

B. Data model and serialization

  • JSON readings carry a millisecond timestamp, a numeric or structured value, and an explicit data-quality flag.A shared data-model library keeps producers and consumers aligned; JSON was chosen for readability and tooling despite its size cost at the system's message rates.Source: B. Data model and serialization · p. 3

IV. DATA ACQUISITION AND ACTUATION

  • The Protocol Bridge is the sole component connecting to PLCs through OPC-UA; on its other side it acts as a Kafka client.It maintains an OPC-UA session with encryption and certificate- or password-based authentication.Source: §IV · p. 3
  • The bridge rounds signals with slightly different source times onto a common tick, giving consumers a jitter-free, co-timed snapshot.The figure depicts the bridge's timestamp alignment on the read path.Source: Figure 4 · p. 4

A. Read path: plant to stream

  • The bridge samples or subscribes to OPC-UA nodes and republishes readings with their source timestamps and quality, turning polled traffic into a stream consumers can read independently.This avoids adding consumer load to the PLC; a foreign OPC server can forward data through a push-based gateway, which may add up to about one second.Source: A. Read path: plant to stream · pp. 3–4

B. Write path: stream to plant

The bridge carries controller setpoints from Kafka to PLCs while keeping hard-real-time interlocks inside the PLC. Timestamp alignment and timestamped FIFO arrays preserve coherent snapshots and sub-second signal detail despite coarser transport cadence.

B. Write path: stream to plant

  • Controllers publish setpoints to Kafka, and the bridge consumes them and issues OPC-UA writes to PLCs; hard-real-time interlocks and limits remain inside the PLC.The bridge provides a single auditable actuation path, and commanded setpoints are durably logged for replay.Source: B. Write path: stream to plant · p. 4

C. Timestamp alignment and jitter management

  • The bridge aligns readings to a common rounded time base so a controller can act on a coherent multi-signal snapshot rather than mutually misaligned values.Correct timing depends on OPC-layer source stamping; for foreign OPC servers, bridge rounding bounds residual skew when source-layer fidelity is absent.Source: C. Timestamp alignment and jitter… · p. 4

V. TRANSPORTING HIGH-RATE SIGNALS

  • Timestamped FIFO arrays preserve 250 ms samples at a one-second publication cadence, avoiding the loss of faster events from down-sampling.Consumers may use an aggregate scalar or the full-resolution series; source timestamps and FIFO order preserve sample timing across slower delivery.Source: §V · p. 4, Figure 5 · p. 4

VI. EDGE-TO-CLOUD REPLICATION

An edge-authoritative Kafka cluster is mirrored to the cloud, keeping control local during WAN interruptions while cloud analytics use replicated data. The loop is engineered for a one-to-two-second round trip, with batching and prompt reads balancing throughput and control responsiveness.

VI. EDGE-TO-CLOUD REPLICATION

  • The edge owns job identifiers and line state, while a mirror replicates its Kafka cluster to the cloud for additional recording and analytics.During WAN interruptions, replication lags and catches up on reconnection, leaving the local control loop unaffected; the cloud is eventually consistent with the edge.Source: §VI · p. 5, Figure 6 · p. 5

VII. LATENCY AND THROUGHPUT

  • The closed-loop round trip is engineered to 1–2 s, rather than the sum of hops, because stages pipeline and are paced by the one-second cadence.Table I identifies the values as engineered targets, not measured distributions; the recorder reads the same stream off the control path and is allowed more latency for write throughput.Source: Figure 7 · p. 5, Table I · p. 5

A. The end-to-end timing budget

The loop budget centers on one-second sampling and publication, with processing allowances at the bridge and consumers. Producer and consumer buffering, immediate actuation writes, and background recording shape how services use the stream.

A. The end-to-end timing budget

  • The loop budget is dominated by one-second sampling and publication, roughly half-second bridge and consumer processing allowances, and up to one second for foreign OPC-server ingress.The governing rule is not to act on data more than about two seconds old.Source: A. The end-to-end timing budget · p. 5

B. Producers, consumers, and the recorder

  • Consumers use bounded buffers and time-boxed reads, so slow downstream stages apply back-pressure and quiet upstreams do not stall controllers.The bridge producer batches and compresses messages to favor network and broker efficiency at some latency cost.Source: B. Producers, consumers, and the… · p. 5
  • Kafka transport adds only milliseconds, negligible against the one-second sampling cadence and not the latency-limiting stage.The latency values are representative of production operation.Source: Figure 8 · p. 6
  • Controllers publish setpoints to Kafka immediately, while the recorder batches database writes in the background so persistence does not block stream consumption.Low-latency dashboards use a metrics store, while the full record goes to a relational time-series database.Source: B. Producers, consumers, and the… · p. 6

VIII. EVALUATION

The evaluation separates a production measurement of Kafka transport from a configuration-derived loop budget and literature-based bounds for unmeasured components. It also identifies several measurements needed for a fuller study.

A. Measured Kafka transport latency

  • Kafka transport latency is on the order of milliseconds, two to three orders of magnitude below the one-second sampling cadence; the broker is not the bottleneck.The end-to-end budget is governed by physical sampling and controller schedules, not the messaging fabric.Source: A. Measured Kafka transport latency · p. 6

B. Literature-grounded component latency

  • Independent benchmarks place Kafka latency in the single- to low-tens-of-milliseconds range at moderate throughput, while third-party component measurements are used only to bound unmeasured stages.The cited literature also characterizes OPC-UA and PubSub latency and compares broker and protocol behavior.Source: B. Literature-grounded component latency · p. 6

C. Toward a fuller study

  • A fuller evaluation still needs a clock-synchronized end-to-end latency histogram, recording-throughput and scaling characterization, and cloud-replica catch-up measurements after WAN partitions.The paper avoids a head-to-head comparison with the plant historian because it cannot be instrumented fairly.Source: C. Toward a fuller study · p. 6

IX. DEPLOYMENT AND OPERATION

The deployed services combine job-aware recording and per-line containerized deployment with data-quality gates that disengage controls when readings are stale or missing. The fabric operates on production lines for auto-correction, defect detection, and virtual sensing.

A. The recorder

  • The recorder tracks job lifecycles, labels data with job identifiers, records value-change and defect events, and triggers cloud automation on job completion.Its HTTP endpoints support service discovery, health, status, and soft configuration reset.Source: A. The recorder · p. 6

B. Packaging and delivery

  • Services are deployed per line in isolated development, QA, and production environments, giving fault containment and a natural unit for horizontal scaling.Docker containers are built through a cloud CI/CD pipeline; line identifiers select streams and configuration.Source: B. Packaging and delivery · p. 6

C. Safety and data-quality gating

  • When readings become too old, values go missing, or heartbeats lapse, the affected control disengages and the process falls back to PLC safe behavior.The streaming loop is an optimizing layer that cannot override hard-real-time interlocks.Source: C. Safety and data-quality gating · pp. 6–7

D. In production

  • Production deployments include closed-loop machine-setting auto-correction, online defect detection, and ML-driven virtual sensing.Shared, versioned communication libraries let teams build new consumers against a stable contract.Source: D. In production · p. 7

E. Lessons learned

Operational experience highlights the value of source timestamps and durable replay, while the discussion distinguishes standard components from the novel architecture that combines them for industrial control.

E. Lessons learned

  • Source timestamps let the pipeline batch, replay, and reorder data without corrupting meaning; durable replay supports offline controller debugging and audit of commanded setpoints.The paper reports that debugging was the most important operational use of rewinding the stream.Source: E. Lessons learned · p. 7

F. Security and access

  • OPC-UA encrypted sessions, identity-aware edge access, per-line isolation, and a single auditable PLC-write component are the security-relevant properties described.Security is not the paper's focus.Source: F. Security and access · p. 7

X. DISCUSSION

  • The discussion frames the paper's central claim as architectural: standard pieces are composed to meet closed-loop industrial-control needs.The comparison table is scoped to messaging substrates and properties relevant to a single-stream, many-consumer control fabric.Source: §X · p. 7, Table II · p. 7

A. Standard components, novel composition

  • The composition combines one per-line stream for control, monitoring, ML, and recording with a shared sensing-and-actuation bridge, high-rate transport, and edge-authoritative cloud replication.The paper identifies Kafka, OPC-UA, JSON, a relational time-series database, and a metrics store as mainstream components.Source: A. Standard components, novel… · p. 7

B. Why Kafka rather than OPC-UA fan-out, RabbitMQ, or MQTT

Kafka provides a durable, independently consumed fan-out layer, while the control loop remains soft real time and the deterministic safety-critical work stays in the PLC. The paper presents this production architecture as a reusable pattern, while noting limits in its timing guarantees and measurements.

B. Why Kafka rather than OPC-UA fan-out, RabbitMQ, or MQTT

  • Kafka’s pull-based durable log decouples consumers and supports replay, unlike OPC-UA fan-out, RabbitMQ’s push model, or MQTT’s lack of a durable log.Kafka lets each service read at its own pace; ingress still uses push to deliver fresh data when it changes.Source: B. Why Kafka rather than OPC-UA… · p. 7

C. Soft, not hard, real time

  • The Kafka loop operates at sub-second-to-seconds granularity without hard timing guarantees; safety-critical deterministic control remains in the PLC.The authors position this softer tier for supervisory, optimizing control.Source: C. Soft, not hard, real time · p. 8

XI. LIMITATIONS AND FUTURE WORK

  • The system does not bound worst-case latency, and direct measurement covers broker transport rather than the full sense-to-actuate loop.JSON’s size cost may constrain very high-frequency signals, while per-line brokers add operational surface area; future work includes end-to-end latency and batching studies.Source: §XI · p. 8

XII. CONCLUSION

  • The production fabric combines standard components for near-real-time closed-loop control, with edge-authoritative replication supporting autonomy during WAN outages.The authors frame the contribution as an architectural pattern and experience report, not a hard-real-time guarantee.Source: §XII · p. 8
Loading 2610.00258v1…