Quick verdict by scenario
"Industrial PC" and "embedded industrial computer" are not two performance tiers of the same machine — they are two ways of packaging and deploying industrial computing, and each carries different implications for real-time behaviour. In practice:
- Soft real-time loops of roughly 1–10 ms (SCADA polling, PLC data collection, HMI plus logging, most packaging and assembly sequencing): either form factor can meet the deadline if the software stack is configured for it. Choose on I/O, mounting and service access rather than on the label.
- Hard real-time loops at hundreds of microseconds, or multi-axis motion with sub-microsecond synchronisation: the deciding factors are the real-time operating system or runtime, the network master stack, and the isolation of the control task from other software running on the same box. A general-purpose industrial PC with an unmodified operating system is the wrong starting point regardless of its CPU; an embedded platform with a pre-emptible kernel and a dedicated fieldbus master is the right one.
- Mixed workloads (control plus vision or analytics on one machine): an embedded industrial computer whose CPU cores are explicitly partitioned between the real-time task and the general-purpose workload is usually easier to validate than a box-style industrial PC where the kernel treats every process equally.
Everything below explains why those verdicts hold, and where they break.
Comparison basis: what "real-time" means in this comparison
Real-time processing is not about average speed. It is about whether a task always finishes before its deadline, and how much that completion time varies. Three measurements matter, and they should be asked for in the same units when comparing any two platforms:
- Cycle time — the period at which the control task must run (for example 1 ms).
- Worst-case latency — the longest observed time from input to output under loaded conditions, not on an idle bench.
- Jitter — the spread of that latency. A controller that is fast on average but occasionally late by 3 ms is worse for a servo loop than one that is consistently 200 µs slower.
Two further criteria decide whether a platform can be trusted with those numbers: task isolation (can system housekeeping, network drivers or a second application starve the control task?) and time synchronisation across distributed devices. As a reference point for how tight synchronisation gets, ODVA's CIP Sync service, built on IEEE-1588, is specified to synchronise devices to better than 100 nanoseconds, and ODVA notes that jitter below 1 µs for cyclic data is needed for precise speed or position control — which is why its CIP Motion profile reworks the transport approach rather than relying on ordinary Ethernet contention behaviour. Numbers of that order are an architecture property, not a CPU-frequency property.
Side-by-side comparison
| Criterion | Industrial PC (box / rack / panel form) | Embedded industrial computer (board, DIN-rail or slot-in unit) |
|---|---|---|
| Typical deployment | Standalone cabinet build, cell controller, vision station, edge node bolted into an enclosure | Inside the machine, inside a control cabinet, or as part of an OEM skid |
| Expansion for real-time I/O | PCIe slots for fieldbus master cards, motion cards, frame grabbers | Soldered-down or stackable I/O, fewer slots; expansion via one or two mini-PCIe/M.2 or proprietary interfaces |
| Thermal headroom | Active or passive cooling sized for bursty loads; higher sustained TDP possible | Often fanless and power-capped, so sustained all-core loads can trigger throttling — which directly shows up as jitter |
| Determinism enablers | Depends on OS and configuration; real-time extensions are optional add-ons | Frequently shipped with, or validated for, a real-time kernel or RTOS image, and with a fixed BSP |
| Software freedom | Broad: any OS, any hypervisor, easy to install drivers and tooling | Vendor BSP and image; fewer surprises but also less room for ad-hoc additions |
| Service access | Front-accessible ports, drive bays, easy to swap a card | Requires opening the machine or cabinet; some units are effectively sealed once installed |
| Lifecycle control | Component-level changes possible but configuration drift is common | Longer fixed BOM and image control, which supports re-validation and fleet rollouts |
| Where latency risk comes from | The operator-added software and drivers on the same OS | The thermal and power envelope, plus limited ability to add a dedicated master card |
Note that a box can be fanless and an embedded computer can have a fan. "Fanless" describes cooling; "embedded" describes integration. They are orthogonal, and many projects end up specifying a fanless embedded unit — a point vendor guidance also makes when comparing fanless industrial PCs with embedded industrial PCs for factory automation.
Industrial PC: where the real-time strength actually is
The case for a box-style industrial PC in real-time work is not raw performance — it is the ability to add dedicated hardware and keep the software stack visible.
- A dedicated fieldbus or motion card removes the network timing problem from the CPU and the general-purpose kernel entirely. The card owns the cycle; the host only exchanges process data. This is often the cheapest route to a hard deadline and it is the one expansion slot that an embedded unit may not offer.
- Multi-core partitioning is straightforward when you control the BIOS, the hypervisor and the OS image. Pinning a real-time task to isolated cores and leaving the rest for vision or logging is a well-trodden pattern on PC hardware.
- Replaceable parts matter for a machine that will be re-tooled: swapping a NIC, adding a capture card or doubling RAM does not require a new platform qualification.
The corresponding risk is drift. Every field technician who installs an antivirus agent, a remote-desktop tool or a consumer update service on that box is adding an interrupt source that can push worst-case latency out by milliseconds. An industrial PC does not protect its own determinism; you have to.
Embedded industrial computer: where the real-time strength actually is
- Fixed image, fixed BSP. Because the vendor controls boot, drivers and firmware, a validated real-time configuration can be reproduced across a fleet. That repeatability is worth more than a faster CPU when you are shipping hundreds of identical machines.
- Boot and recovery behaviour is designed in. Read-only root filesystems, watchdog-driven restarts and short boot times let a machine return to a safe control state predictably — a property that is hard to retrofit onto a general-purpose PC image.
- Lower idle power and passive cooling suit sealed enclosures and cabinet interiors where an active fan would draw in dust or oil mist.
The corresponding risk is the thermal budget. A passively cooled embedded unit sized for a 1 kHz control loop may throttle when the same CPU is also asked to run a vision model. Throttling is not a crash — it is a slow, load-dependent change in cycle behaviour, exactly the kind of effect that produces intermittent, hard-to-reproduce faults on the line.
Trade-offs and exceptions
- "Embedded" does not guarantee determinism. A compact computer running a stock desktop distribution with default power management is no more real-time than a box. Ask for the measured worst-case figure with the same workload you intend to run.
- Linux with real-time preemption is the common middle path. The PREEMPT_RT work is merged into the mainline kernel, so a pre-emptible kernel plus a fieldbus master (for example an IgH EtherCAT master) is a widely used route to sub-millisecond cycles on both form factors. The differentiator becomes who validates and freezes that configuration, not which chassis it sits in.
- Cycle time claims need a stated load. A 250 µs cycle demonstrated with the fieldbus as the only running task tells you little about a machine that also streams camera frames. Treat idle-condition numbers as an upper bound on capability, not a prediction.
- Virtualisation shifts the question. Running the real-time runtime in a dedicated partition or on a hypervisor-managed core can restore isolation on a busy industrial PC — at the cost of needing someone who understands the partitioning, and of losing some of the platform's raw headroom.
- Small-scale exceptions. For a one-off test rig with a single axis and no distributed clocks, a standard industrial PC with a modest real-time setup is usually adequate and far easier to debug; specifying an embedded platform for it adds integration cost without adding capability.
How to decide next
- Write the deadline down in numbers: cycle time, acceptable worst-case latency, acceptable jitter, and how many axes or nodes must stay synchronised.
- Decide whether timing is owned by hardware or by software. If a dedicated motion or fieldbus card can own the cycle, an industrial PC is a natural fit. If the cycle must be owned by software on the CPU, the OS image and the isolation story become the main selection criteria.
- Ask both candidates for the same evidence: worst-case latency and jitter under a representative mixed load, thermal behaviour at the cabinet's ambient temperature, boot and recovery time, and the process by which the configuration is frozen and re-validated.
- Weigh service and lifecycle against the timing result. A slightly worse jitter figure with front-accessible service may be the better whole-of-life choice for a cell that will be re-tooled; a fixed, reproducible image may win for a fleet of OEM machines.
- Only then size the CPU. Real-time capability is largely an architecture question; compute capacity is a separate, later decision driven by the non-real-time workload.
Sources
- ODVA, CIP Sync™ — IEEE-1588-based synchronisation accuracy better than 100 ns between devices: odva.org
- ODVA, CIP Motion™ — requirement for sub-1 µs cyclic jitter in precise speed/position control: odva.org
- SINSMART, Fanless Industrial PC vs Embedded Industrial PC for Factory Automation — definitional distinction between fanless (cooling) and embedded (deployment): sinsmarts.com
- CNFX technical reference, Control computer for real-time machine control — worst-case latency, control-task isolation and jitter as the three questions to ask: cnfx.com