Every so often, someone in a technical community asks how to choose an industrial PC. The people asking come from different places: a production line that needs one more workstation, a control-room retrofit, a new plant shopping for edge nodes. The requirements differ, but the bottleneck is usually the same — whether the SCADA screens, HMI projects, and configuration software already running in the factory can be carried over as-is. That answer, more than clock speed, power draw, or price, decides whether the embedded industrial computer in question should be an x86 platform or an ARM platform.
The question resurfaces more often than it used to. ARM gateways have pushed down both the price and the power draw of industrial computing, so the choice is no longer a foregone conclusion — and neither is the mistake of assuming every new device can simply take over an old role. A capable-looking ARM box can end up unable to open a single existing project file. Sorting this out before purchase, not after, is what keeps a retrofit on schedule.
The difference between the two platform families is not how fast they compute, but what systems they can run. x86 shares its architecture with ordinary PCs, so both Windows and x86 versions of Linux install directly. Software the plant has already licensed and tuned for years — HMI runtimes, Ignition Edge, and similar stacks built for x86 environments — runs on it without rework. ARM platforms usually ship with Ubuntu, Node-RED, and Docker, which are handy for data acquisition and forwarding. What they cannot do is run a Windows-based configuration project directly. Moving such a project over means rebuilding screens and rewriting the communication tag tables, an effort that often outweighs the cost of the hardware change itself.
The selection order should be turned around: before touching hardware, list every piece of software to be deployed on site — which packages exist only in a Windows version, which can run on Linux, and whether screen refresh, reporting, and alarm logic are baked into the existing project. Once the list is done, the architecture largely settles itself. As long as one or two core packages must stay on Windows, the whole device goes to the x86 platform. Conversely, when there is no legacy software and the job is purely protocol acquisition, edge computing, and cloud reporting, an ARM gateway wins on cost and power.
It is worth going through the exercise in writing rather than from memory. Vendor support pages and license agreements answer the two questions that matter: which OS versions the package officially supports, and whether the license can be moved to a new machine at all. Fifteen minutes with that information prevents a purchase that looks right on paper and fails on delivery day.
"Edge computing" now covers both kinds of devices, which makes it easy to assume one box is enough. In practice, a plant floor splits into two halves. One half is acquisition and cloud upload: pulling data from PLCs, meters, and instruments, performing local preprocessing, then forwarding it to a platform. The other half is human-machine interaction and station control: engineers watching live screens, operating controls, checking alarms and reports. The second half depends on the software ecosystem far more than the first.
For the first half, ARM boxes are genuinely strong. Devices in this class bundle 4G, Wi-Fi, and Ethernet with automatic failover, integrate VPN and firewall, and speak a long list of fieldbus protocols out of the box. That is exactly the profile of a protocol gateway sitting between a machine and the cloud.
ARM devices can also provide a local monitoring interface. Take the USR-EG528 as an example. It runs a quad-core RK3562 processor with Ubuntu 24.04, ships with the WukongEdge engine and Node-RED, and its product page explicitly lists built-in local SCADA/HMI capability, so a data dashboard can be assembled quickly on top of protocol acquisition. There is a distinction worth keeping in mind: this is a set of tools provided by the vendor's Linux engine, not a way to install third-party Windows configuration software. When a site has already settled on a configuration package and its licenses, this half of the demand still calls for an x86 platform.
When an x86 industrial PC comes down to a final choice, the decisive factor is I/O: how many serial devices to connect, how many Ethernet ports are needed, whether multiple displays are required. PUSR's EC series is divided into three tiers along exactly this dimension.
Choosing between the tiers is a counting exercise: total up the serial and Ethernet ports, then add headroom for devices expected to join within the next two years. Industrial PCs normally run for years in one position, so provisioning all ports up front beats bolting on expansion later. Sizing from the budget backward is the shortest route to a machine that cannot fit the job.
The same logic applies to the rest of the environment. A unit bound for a control cabinet benefits from wide-range DC input that tolerates a fluctuating plant bus, and a fanless or rugged enclosure matters more in a dusty shop floor than in an air-conditioned server room. Matching the machine to where it physically sits is as much part of the selection as matching it to the software.
Broken down this way, the conclusion is direct. When Windows-based SCADA/HMI and configuration software must run on site, the embedded industrial computer should be an x86 platform — first make sure the existing project runs as-is, then pick the tier by port count. When the job is pure acquisition, forwarding, and cloud reporting, an ARM gateway saves cost and power. x86 here is not about being conservative; it refl
