Trends in Real Time OT Compute Technologies

EXECUTIVE BRIEF: We examine trends in real time control compute hardware

Executive Summary

For seventy years, the question “what controls the machine” had one answer: a ruggedized, single-purpose box on a DIN rail, programmed in a language that looked like a relay schematic. That answer is no longer singular. Market data through mid-2026 shows the traditional PLC market still growing at a healthy 4–11% compound annual rate depending on the research house consulted — but growing alongside, not instead of, a faster-growing tier of virtualized soft-PLC runtimes, industrial single-board computers, and edge controllers built on Raspberry Pi and comparable ARM-based platforms.

This is not a displacement story. It is a fragmentation story. The compute layer that used to be one box is becoming a stack: hard real-time control on certified hardware at the bottom, soft real-time coordination in the middle, and data, analytics, and AI inference at the top — each layer increasingly running its own hardware, its own programming language, and its own connectivity model. For OT executives, the operating question is no longer “which vendor” but “which layer, and what does each layer actually guarantee.”

A distinct and easily-missed thread inside the SBC story is where the volume is actually landing: not primarily plant engineers retrofitting single machines, but machine builders engineering the Raspberry Pi Compute Module directly into purpose-built equipment as a fixed, non-reconfigurable component — trading the PLC's openness for a cost basis that only pencils out at production volume. Section 3 covers that pattern and its lifecycle-support implications directly; Section 4 works through the total-cost-of-ownership math on both sides.

The Structural Shift: From Fixed Hardware to a Layered Compute

Market research on the PLC segment is unusually dispersed for a mature category. Estimates for 2026 alone range from roughly $12.9 billion to $17.6 billion depending on methodology and scope, with forecast CAGRs through the early 2030s clustering between 4.2% and 11.4% across major research houses. That spread is itself a signal worth flagging to leadership: when five reputable firms can't agree within a factor of nearly 1.4x on the size of a mature, well-instrumented hardware category, it usually means the category's boundaries are shifting faster than the analysts' taxonomies — in this case, because “PLC” increasingly includes software-only control running on general-purpose industrial PCs, which some firms count and others don't.

The clearer indicator sits inside the segment breakdowns. Modular hardware PLCs remain the largest single product type, but soft-PLC and virtualized control — control logic hosted in a hypervisor on standard industrial PCs rather than dedicated hardware — is the fastest-growing sub-segment in several forecasts, expanding at roughly 7% CAGR against a low-single-digit rate for hardware overall. Audi's publicly discussed virtual PLC rollout, which reportedly cut commissioning time meaningfully while improving real-time optimization, is frequently cited as the proof point that software-defined control has moved past pilot stage into production automotive lines.

The architectural driver underneath this is IEC 61499, the distributed automation standard that formalizes control logic as portable function blocks decoupled from any specific hardware target. It is not yet the default in most plants, but it is the reference architecture vendors point to when explaining why control logic can now move between a DIN-rail PLC, an industrial PC, and an edge server without a rewrite.

Hardware Platform Trends: The Traditional PLC vs Industrial SBC

Where the traditional PLC still wins

Certified hardware PLCs remain the only credible choice wherever the application combines hard real-time cycle times (single-digit milliseconds and below), functional safety certification (IEC 61508, IEC 62443, machine safety categories), and environmental ruggedization (temperature extremes, vibration, EMI) in one package. Vendors are not standing still within this tier — Siemens, Rockwell, and others have shipped AI-assisted engineering tools and edge-analytics-capable controllers over the past year — but the core value proposition (a qualified, single-vendor-supported, deterministic execution environment) is unchanged and, for safety-instrumented systems in particular, not something the market is likely to replace.

Where single-board computers are actually being deployed

The Raspberry Pi ecosystem — and to a lesser extent Arduino-class microcontrollers — has moved well past hobbyist status into commercial industrial products. Compute Module 4 and 5-based hardware from vendors including Revolution Pi, Sfera Labs (Strato Pi, Iono Pi), and Seeed Studio (reComputer Industrial) now ships in DIN-rail and fanless enclosures with industrial I/O, isolated RS-485/CAN, PoE, and hardware watchdogs — the physical packaging of a PLC, built on consumer-derived silicon.

The deployments that are actually in production cluster around a consistent pattern, and it is not replacing the PLC for motion control. The dominant use cases are:

•        Edge data acquisition and protocol translation — bridging legacy PLCs that speak Modbus or proprietary serial protocols into MQTT or OPC UA without the cost of a full gateway appliance — a use case whose scale is driven by decades of installed legacy hardware rather than any greenfield architecture decision.

•        Local AI inference — vision-based quality inspection, predictive-maintenance vibration analysis, and anomaly detection running on-device, reducing both latency and cloud bandwidth cost.

•        HMI and lightweight SCADA front-ends — leveraging the full Linux stack and commodity display hardware at a fraction of proprietary panel-PC cost.

•        Distributed monitoring at scale — applications where the cost and footprint of a full PLC per monitoring point is not justified by the control requirement.

What should be understood but vendor literature may not state is that a stock Raspberry Pi running a standard Linux kernel is not deterministic. Real-time behavior on this class of hardware is only achievable with a tuned PREEMPT_RT kernel, and even then the achievable range is roughly 20–200 microseconds of jitter under well-controlled, isolated-core conditions, which is soft real-time performance, not hard real-time. NASA's own technical assessment of PREEMPT_RT is blunt on this point: the patched kernel favors throughput over latency and does not guarantee deadlines the way a certified RTOS does. That said, this "soft real time" jitter is acceptable for many real world OT applications. Commercial platforms like Phoenix Contact's PLCnext address this by layering a dedicated execution and synchronization runtime on top of a PREEMPT_RT kernel — the determinism comes from that runtime, not from Linux or the SBC alone. Any SBC-based system positioned as a PLC replacement should be evaluated on that distinction specifically: what is providing the timing guarantee, and has it been measured under the actual application's worst-case load, not a bench test.

Arduino-class microcontrollers sit in a lower, distinct tier below both the certified PLC and the Linux-based SBC and are easy to mis-file alongside Raspberry Pi even though the underlying architecture is unrelated. These are bare-metal parts with no operating system, so the PREEMPT_RT determinism question above does not apply to them — a well-written single-loop control program on an MCU can be genuinely hard real-time at a hardware cost of a few dollars. What that tier does not offer is a path to the Linux ecosystem, containerized analytics, or AI inference workloads that are driving most of the rest of this paper; it is the right platform for simple, fixed, single-purpose control loops, not for the data and edge-intelligence layer.

The OEM embedding pattern: purpose-built, not user-reconfigurable

A second, distinct SBC pattern is easy to conflate with the edge-gateway trend above but runs on different economics: machine builders designing the Raspberry Pi Compute Module directly into a product as a fixed System-on-Module, not deploying a general-purpose flexible controller. This is the pattern behind NEC and Sharp embedding the CM4 into digital-signage display architecture, Revolution Pi's CM5-based RevPi Connect 5 industrial platform, and a growing list of OEM appliances — rack servers, vision systems, monitoring units — where the compute module is a line item in the bill of materials, not a component the end customer is expected to reprogram.

The distinction matters because it inverts the traditional PLC value proposition. A PLC's premium is substantially a premium for openness: any certified integrator can reprogram it, multiple vendors' peripherals plug into its standardized fieldbus ports, and the end customer retains the flexibility to modify control logic over the machine's service life. The OEM-embedded Compute Module pattern trades that flexibility away deliberately. The machine builder owns the firmware, the carrier-board design, and the application logic; the end customer receives a purpose-built, typically closed appliance tuned to one job. In exchange, the machine builder gets Compute Module pricing that ranges roughly $25 to $90 per unit depending on RAM and eMMC configuration at volume — a cost basis a certified-PLC-plus-licensed-software bill of materials cannot approach at the same production quantities — plus a Raspberry Pi Foundation production-lifecycle guarantee (CM4 through at least January 2034, CM5 through at least January 2036) that addresses the obsolescence risk that has historically been the strongest objection to building industrial products on consumer-derived silicon.

For OT, evaluating a new machine purchase, this pattern changes the right diligence questions. The question is no longer just what controller is inside this machine but who can service the control logic, and under what terms. A machine built around an embedded Compute Module typically means the machine builder — not a broad integrator ecosystem — is the only party who can modify the control logic, which is a materially different support and lifecycle-risk profile than a machine built on an open, multi-vendor PLC platform, even when the sticker price favors the embedded design.

Cost and Application Fit: Where the Economics Fit for Each Platform

Raw hardware price comparisons between PLCs and SBCs are close to meaningless on their own — both categories span more than two orders of magnitude — but the total-cost-of-ownership pattern underneath them is consistent enough to be useful for capital planning.

The PLC Cost Stack

Entry-level micro PLCs (Siemens LOGO!, AutomationDirect CLICK, Allen-Bradley Micro800-class, Omron CP-series) price between roughly $100 and $500 bare, which is where most informal PLC-versus-Pi comparisons stop. The realistic total cost is higher and increasingly dominated by software rather than hardware: premium-platform engineering software has been shifting to per-seat annual subscriptions in the $800–$6,500 range, certified PLC programming labor is quoted in 2026 industry pricing guides at roughly $110–$170 per hour, and annual maintenance — cybersecurity firmware updates and system audits in particular — is commonly budgeted at 5–10% of initial capital cost per year. A representative illustration cited in current industry pricing references: a $1,500 controller carrying a $200-per-year software subscription totals roughly $3,500 over a 10-year service life, a premium of well over 100% on top of the sticker price. That software, labor, and maintenance stack is what an OT executive should be comparing against, not the bare controller price. The hardware is rarely the biggest line item - the supporting software is along with associated licensing commitments.

The SBC/Compute Module

Compute Module hardware itself is inexpensive at volume — roughly $25–$90 per unit — and the software stack (Linux, Python, C/C++, OpenPLC) carries no recurring per-seat licensing, which is the headline economic argument for SBC-based control. What that framing leaves out is that the engineering cost historically absorbed by a PLC vendor's certified, supported toolchain doesn't disappear; it moves in-house. Carrier-board design, industrial hardening (thermal management, power-supply robustness, EMI compliance), and validating a non-certified software stack for a specific application are all real, one-time engineering costs that a machine builder amortizes across a production run — which is precisely why the economics favor volume OEM production far more than they favor a single end-user retrofitting one line. A plant engineer replacing one PLC on one machine rarely has a production run large enough to amortize that engineering investment; a machine builder shipping hundreds or thousands of units of a purpose-built product does.

This is the practical resolution to what can look like a contradiction in the market data: Raspberry Pi's own 2026 financial disclosures point to industrial and commercial demand — not hobbyist sales — as the primary driver of its revenue growth, which is consistent with OEM embedding at volume rather than widespread plant-floor retrofitting by end users.

A simplified application-fit framework for capital planning:

•        High-volume, purpose-built OEM equipment with a fixed function — Compute Module or comparable SBC embedded by the machine builder, amortizing engineering cost across the production run.

•        Low-to-moderate volume, field-reconfigurable, multi-vendor service ecosystem required — traditional certified PLC; the software-licensing and labor premium buys openness and third-party serviceability the embedded pattern does not.

•        Safety-instrumented systems or hard real-time motion, at any volume — certified PLC or safety controller; no SBC-based platform available today substitutes for this without redoing certification work from scratch.

•        Data acquisition, protocol translation, or edge analytics layered onto either of the above — SBC-class edge device, regardless of what platform is doing the underlying control — this layer's economics favor the SBC approach almost universally.

Nexus Engineering Partners can help you determine what is the best fit for your applications needs as well as architect the ideal system.