SBC or Industrial Router for Edge Computing?

Quick answer: A single-board computer such as a Raspberry Pi provides a full Linux environment and flexible local compute, while an industrial cellular router combines networking, security, dual-SIM cellular connectivity, certified RF, and – increasingly – embedded edge computing in a single DIN rail unit rated for harsh environments. For many industrial IoT deployments in 2026, a modern programmable router or purpose-built edge gateway can replace what previously required a separate router, gateway, and SBC – reducing hardware count, certification risk, and ongoing maintenance overhead.

The Lines Between Router and Edge Computer Are Blurring

Industrial IoT deployments used to follow a predictable hardware pattern: a certified cellular router for connectivity, a separate IoT gateway for protocol translation, and an SBC or industrial PC for anything needing serious local compute. Three boxes, three power supplies, three things to mount, configure, and maintain. That architecture made sense when each device did one job. It is no longer the only option.

Industrial routers from Teltonika, Milesight, and Robustel now run Python, Node-RED, and Docker. The Robustel EG5200 ships with Debian 11, a 2.3 TOPS NPU, and explicitly supports ARMv8 Raspberry Pi-compatible applications – it is a certified cellular router and an industrial edge compute node in the same enclosure. The Teltonika RUTC41 runs Docker containers alongside a full 4G eSIM router stack. The Milesight UR75 runs Node-RED natively. The boundary between router and edge computer is becoming less clear with every product generation.

This does not make the choice easier – it makes it more nuanced. The right architecture still depends entirely on the workload: what compute is needed, what certifications are required, what the thermal and physical constraints are, and what the SIM management story looks like at fleet scale. This guide works through each option with those criteria in mind, and covers where the Raspberry Pi 6 fits in, which SBC alternatives are worth watching, and how 5G RedCap and SGP.32 eSIM change the picture for new designs.

Architecture One: SBC with Cellular Added

The case for building on a Raspberry Pi or similar SBC is straightforward: you get a full Linux environment, an active software ecosystem, Docker, GPIO, camera interfaces, and a HAT and carrier board market that has been building since 2012. For applications that need serious local compute – computer vision, ML inference, complex data aggregation, or custom protocol stacks – no industrial router comes close at the same price point.

The Raspberry Pi Compute Module 5 is the right platform for new industrial designs today. It brings a quad-core Cortex-A76 at 2.4 GHz, PCIe 3.0, up to 16 GB RAM, and dual camera connectors – a meaningful step up from CM4. Industrial carrier boards from Sfera Labs (Strato Pi Max), Seeed Studio (reComputer R series), and OnLogic (Factor 201) wrap the CM5 in DIN rail enclosures with RS-485, CAN bus, isolated digital I/O, wide-voltage DC inputs, and – critically – slots for cellular modems. The Raspberry Pi 6 will not arrive before early 2028, which removes the uncertainty: CM5 is the platform to design around now.

Adding cellular to an SBC: what it actually involves

Cellular on a Pi-based system typically arrives via one of three routes: a mini-PCIe modem on the carrier board, an M.2 modem (B-key, common on CM5 carrier boards), or a USB modem as a fallback. The modem choice matters more than most builders realise. A Quectel EC25, Sierra Wireless EM7455, or equivalent module needs the right antenna connections – not an afterthought. RF performance on a Pi-based gateway is only as good as the antennas and cable routing, and a poorly specified antenna on a DIN rail installation inside a metal cabinet will cost you signal you cannot recover in software. IoTPortal's antenna directory covers the relevant antenna types for cellular IoT enclosures.

SIM management on a Pi-based cellular deployment also requires thought. A standard SIM behind carrier-grade NAT will not accept inbound VPN connections. A fixed-IP SIM on a private APN is the standard approach for SCADA and remote monitoring applications – see the private vs public IP guide for the full breakdown. For larger fleets, this is also where SGP.32 eSIM provisioning starts to matter – more on that later.

What SBC-based edge compute is not good at

SBC platforms with added cellular modems are not certified as cellular routers. They have not been tested to PTCRB, RED Directive, or carrier acceptance standards in the way that a Teltonika RUT956 or Robustel R5020 has. For deployments that need to demonstrate regulatory compliance – utility infrastructure, medical monitoring, transport – this matters. Industrial router hardware ships certified, insured, and documented. A Pi with a modem HAT does not.

Thermal management is another real constraint. The Raspberry Pi 5 is rated to 85 degrees Celsius junction temperature, and active cooling is required for sustained load. Industrial carrier boards add heatspreaders and managed fan control, but this adds cost and complexity. Compare that to a Teltonika RUT956, rated to operate passively from -40 to +75 degrees Celsius in a sealed aluminium enclosure with no moving parts.

Architecture Two: The Programmable Industrial Router

The middle tier that is frequently overlooked by engineers coming from either a Linux compute background or a traditional networking background is the programmable industrial router. These are not general-purpose computers, but they are not dumb connectivity boxes either. They run embedded Linux, expose a scripting environment, and handle the cellular connectivity, dual SIM failover, serial interfaces, and certified RF – all in a DIN rail unit with a ten-year supply assurance.

Before looking at specific products, the table below sets out why a programmable industrial router is often a better fit than an SBC-plus-modem combination for the majority of industrial IoT applications – even where the SBC wins on raw compute.

Milesight UR32 with Python SDK

The Milesight UR32 is a compact 4G LTE Cat 4 router with an NXP industrial-grade processor, IP30 enclosure, -40 to +70 degree Celsius operating range, dual SIM, RS-232/RS-485 serial, and digital I/O. The Python 3.7 SDK runs directly on the router, enabling custom scripts for Modbus polling, data formatting, threshold alerting, and protocol bridging without a separate compute node. This is not a full Python environment – storage is constrained and there is no Docker – but for the class of applications that most industrial IoT deployments actually need, it is more than sufficient. The UR35 and higher models add further compute and the Milesight Development Platform with Node-RED integration and the Beaver IoT open-source application layer.

Teltonika RUT956 with Python and RutOS

The Teltonika RUT956 is the direct successor to the widely-deployed RUT955, running RutOS (OpenWrt-based) with Python 3.9 available as an installable package from the package manager. It carries dual Mini SIM plus an integrated eSIM, RS-232 and RS-485 serial ports, a dedicated GNSS receiver, four configurable I/O lines including a 4-20 mA analogue input and relay output, and the full Modbus TCP/RTU, DNP3, OPC UA, and MQTT protocol stack. The I/O capability means the RUT956 can connect directly to PLCs, energy meters, and field instruments and forward data over 4G without additional hardware. Python scripts handle custom logic at the edge. Teltonika RMS provides centralised fleet management, remote access, and FOTA updates across deployed units. The RUT956 also supports eSIM profile management through RMS – a practical implementation of remote SIM switching that works for the majority of router deployments even if it does not implement the full SGP.32 architecture. The RUTC41 takes this further still, adding Docker container support and dedicated edge compute resources alongside the cellular and eSIM stack – covered in more detail on euicc.co.uk's RUTC41 guide.

Robustel R5020 with RobustOS SDK

The Robustel R5020 is the brand's flagship 5G industrial router, supporting global 5G/4G/3G bands with dual SIM, four Gigabit Ethernet ports, RS-232/RS-485, DI/DO, optional GNSS, and Wi-Fi 5. It runs RobustOS with a well-documented SDK supporting C, C++, Python, and Node.js for custom application development. Where it extends beyond a traditional router is in the additional CPU headroom the 5G platform provides – enough for meaningful edge logic beyond simple data forwarding. Robustel RCMS provides centralised cloud management. The R5020-Lite offers the same 5G connectivity in a more compact, lower-cost format for deployments where serial and analogue I/O are less critical.

Architecture Three: Purpose-Built Edge Computing Gateways

The most interesting development in industrial edge hardware over the past two years is the emergence of devices that are neither router nor SBC, but genuinely both. These are purpose-built edge computing gateways that integrate cellular backhaul directly with a serious compute platform – certified, ruggedised, and managed as a single unit.

Robustel EG5200

The Robustel EG5200 is the clearest example of this category. It pairs a quad-core Cortex-A53 at 1.6 GHz with a dedicated 2.3 TOPS NPU for machine learning inference, 32 GB eMMC storage, five Gigabit Ethernet ports, HDMI output, USB 3.0, dual-SIM 4G/5G cellular backhaul, RS-232/422/485, and dry-contact DI and relay outputs. The operating system is RobustOS Pro – a full Debian 11 (Bullseye) environment. It supports Docker containers and the entire Debian package repository (50,000+ packages), and is explicitly described as supporting ARMv8 Raspberry Pi-compatible applications. The SDK covers C, C++, Java, Python, and Node.js. This is, functionally, an industrial-grade Pi-class compute node with certified cellular connectivity built in. For deployments that would otherwise need a cellular router plus a CM5 carrier board plus integration, the EG5200 consolidates them into one certified, managed unit.

Milesight UR75 and UF51 with Node-RED

The Milesight UR75 sits at the higher end of the Milesight router range with Node-RED running natively on the device. This changes the application development model significantly: Node-RED flows handle protocol translation, data transformation, cloud forwarding, and event logic with a visual editor rather than raw Python. The UF51 adds LoRaWAN gateway capability alongside the cellular backhaul. For deployments that need a managed, supportable edge platform with visual logic tooling and cellular connectivity, the UR75 is a strong choice that does not require Linux expertise to deploy and maintain.

The SBC Landscape Beyond Raspberry Pi

The Raspberry Pi's advantage in industrial IoT is not its raw specifications – it is the ecosystem. The combination of long-term supply commitment, Compute Module form factor, extensive carrier board availability, and deep software support from the Foundation means that building on Pi is a lower-risk choice than building on a cheaper or more powerful alternative. That said, the competitive SBC landscape is developing quickly, and some alternatives are genuinely worth evaluating for new designs.

Allwinner A733 (A7Z): an emerging challenger

The Allwinner A733 is a hybrid octa-core SoC combining two Cortex-A76 performance cores with six Cortex-A55 efficiency cores, an Imagination BXM-4-64 GPU with Vulkan 1.3 and OpenCL 3.0, a dedicated 3 TOPS NPU for inference workloads, and a RISC-V E902 coprocessor for real-time tasks. It has appeared in the Radxa Cubie A7A and A7Z boards, the Orange Pi Zero 3W, and the Orange Pi 4 Pro, with ArmSoM and others sampling. At up to 16 GB LPDDR5 and PCIe 3.0, the spec sheet is compelling – and the NPU is a direct answer to the Raspberry Pi 5's lack of on-board AI acceleration. It is also the main reason Raspberry Pi Foundation's decision not to include an NPU in the Pi 6 is notable: the competitive landscape is moving in that direction even if Pi is not.

The caveat for industrial deployment is significant: mainline Linux kernel support for the Allwinner A733 has not landed as of Linux 7.0, and the carrier board ecosystem around these SBCs is nascent compared to the CM5. For evaluation and prototype work, the Allwinner A733 boards are interesting. For a production industrial deployment that needs long-term OS patching and supply assurance, the CM5 remains the more defensible choice in 2026.

Rockchip RK3588 class

The Rockchip RK3588 (and RK3576) platform appears in boards from Radxa, Orange Pi, and Khadas, offering eight CPU cores, substantial NPU compute (6 TOPS on RK3588), and PCIe 3.0. These boards are used in industrial edge compute deployments, particularly for computer vision workloads where the NPU makes a meaningful difference. The software support picture has improved considerably over the past two years, with Radxa and Armbian both providing maintained images. They do not have the CM form factor or the breadth of industrial carrier boards that Pi has, which limits them in more rigidly constrained installations.

Raspberry Pi 6: What the 2028 Timeline Actually Means

In May 2026, Raspberry Pi CEO Eben Upton confirmed in a public AMA that the Pi 6 will not arrive before early 2028. The delay is driven by DRAM cost inflation – memory component costs more than doubled in the year to early 2026, and launching a new board that would need to carry more RAM than the current Pi 5 would push it well above the price point that made Pi competitive.

The Pi Foundation also clarified what Pi 6 will and will not do. The focus is on more of the same: a faster CPU core and faster IO throughput, built on an evolved version of the RP1 I/O controller introduced with Pi 5. There will be no dedicated NPU – Eben's stated position is that the CPU is the right venue for AI compute on Pi. GPIO compatibility is expected to continue. This is a deliberately conservative roadmap that prioritises software ecosystem continuity over specification chasing.

For industrial IoT designers, the practical implication is clear: the Compute Module 5 has a confirmed runway of at least two years before a successor arrives, and the Pi Foundation's software commitment – 95% of engineering resource on drivers, kernels, and OS support per Gordon Hollingworth – provides the long-term patching assurance that production deployments need. The edge computing and cellular resilience guide on IoTPortal covers how CM5-based gateways fit into industrial cellular architectures in more detail.

Decision Framework: Which Architecture for Which Job

The following table maps the four architectures against the criteria that matter for industrial deployments. It is not a ranking – each column has use cases where it is the right answer.

The Connectivity Future: RedCap, eRedCap, and SGP.32

The hardware platform decision does not exist in isolation from the connectivity technology it will carry. Two developments in the cellular IoT standards space are relevant to anyone specifying edge compute hardware today for deployments with multi-year lifecycles.

5G RedCap and eRedCap

5G RedCap (Reduced Capability, 3GPP Release 17) defines a simplified 5G device category targeting the mid-tier IoT space – up to 226 Mbps downlink, significantly lower power and cost than full 5G NR, but far more capable than NB-IoT or LTE-M. Enhanced RedCap (eRedCap, Release 18) reduces peak rates further to 10 Mbps, targeting the LTE Cat-1 and Cat-1bis replacement market. Commercial RedCap modules from Quectel, Fibocom, and Telit Cinterion are available now. EE and Vodafone are live with RedCap in the UK. Module pricing is moving toward LTE parity through 2026.

For edge gateway and SBC-based deployments that will run for five to ten years, the modem module choice made in 2026 will still be in service when LTE Cat-4 networks begin to be refarmered. Designing for RedCap or at minimum ensuring the carrier board has an M.2 slot that can accept a future RedCap module is a reasonable hedge. The full UK RedCap picture is covered at 5gredcap.co.uk.

SGP.32 and eSIM fleet management

The physical SIM card is a practical problem at scale. When you have 50 or 500 Pi-based edge gateways deployed across remote sites, changing carrier or updating APN configuration requires either physical site visits or manual remote console work. eUICC-based eSIM has been the hardware answer for years, but the provisioning standards above it have been slow to mature. SGP.32 – the GSMA's IoT-specific eSIM provisioning specification – changes this. It is designed for headless devices, constrained networks including NB-IoT, and server-driven profile management at fleet scale. The eIM (eSIM IoT Manager) pushes profile changes to devices without requiring user interaction or a persistent IP connection.

Commercial SGP.32 deployments are beginning in 2026, with the ecosystem accelerating through 2027. For industrial SBC and gateway deployments being designed today, specifying an eUICC-capable module and designing for SGP.32 management is the correct architectural decision even if the provisioning platform is not fully in place at launch. The full specification breakdown is at sgp32.co.uk. Teltonika's eSIM implementation on hardware like the RUT956 and RUTC41 – while SGP.22 rather than native SGP.32 – demonstrates the practical operational benefits that eSIM delivers for router fleet management today.

Summary: Matching Platform to Deployment

For protocol gateways, Modbus-to-MQTT bridges, SCADA backhaul nodes, and remote monitoring applications where the logic fits comfortably in Python scripts or Node-RED flows: a programmable industrial router – Teltonika RUT956, Milesight UR32 or UR75, Robustel R5020 – is the lowest-risk, most maintainable choice. It ships certified, operates across the full industrial temperature range, and is manageable at fleet scale from day one.

For applications that need Docker, a full Debian environment, computer vision, ML inference, or compute workloads that exceed what a router CPU can handle: an SBC-based platform on CM5 with an industrial carrier board is the right architecture. Accept the integration work, specify the modem and antenna properly, and plan the SIM strategy before deployment rather than after.

For deployments that want both in a single certified unit: the Robustel EG5200 – Debian 11, Docker, 2.3 TOPS NPU, dual-SIM 5G cellular, five Gigabit Ethernet, RS-485, DIN rail – consolidates what would otherwise be two separate devices. It costs more than either individually, but less than the engineering overhead of integrating and certifying the two-unit approach for a production deployment.

For the highest-compute applications where you need both a full-spec Pi-class board and certified cellular connectivity as independent components: a CM5 carrier board alongside a dedicated cellular router is the architecturally cleanest solution, at the cost of two power supplies, two units, and integration work between them. This is the right answer for applications where the Pi's software ecosystem and the router's certification both have non-negotiable requirements that the integrated options cannot meet simultaneously.

The Raspberry Pi 6, when it arrives in 2028, will not change this framework materially – it will offer more CPU speed and faster IO on the same architectural lines. The programmability of industrial routers will have continued to improve. The edge gateway category will have matured further. The decision logic will look similar to what it does today, applied to faster hardware on all sides.