A cabinet beside a bottling line has to run three pieces of software. A SCADA project bought years ago only runs on one particular Windows version. Energy metering added later is written in Python. The inspection program that came after depends on yet another runtime library. All three live on one machine, touching one risks breaking the other two, and the arrangement that survives is the one where nothing ever gets upgraded. The idea of sealing each one into its own virtual machine and getting three machines out of one box usually surfaces right there.
Whether an Embedded Industrial PC can run virtual machines is not a question with a plain yes or no. It depends on where three separate costs land: memory stays resident, storage has to absorb continuous writes, and the processor layer also depends on whether the firmware was built to match.
Someone once built a small form factor case around a low profile graphics card and a 500 W power supply, sizing the internal space and the power budget around those two parts. Virtualization runs into the same kind of problem. It is easy to calculate from whether one environment can start, while what actually has to hold is those few minutes when every environment is busy at once.
The line between virtual machines and containers sits here: each virtual machine runs a complete operating system, so beyond the resident share the host holds, every guest takes a share of its own. The way to size it is to run the several software sets together on a development machine under real workload, record the steady processor and memory figures, add 30 percent, and take the peak where all of them are busy together.
Models separate cleanly at this layer. The USR-EG228 comes with 512 MB of DDR3 and 8 GB of eMMC, suited to single point acquisition and reporting. The USR-EG628 runs an RK3562J quad core Cortex-A53 at 2.0 GHz with 4 GB of memory and 32 GB of eMMC, brings out 2 RS485 ports, 1 RS232, 1 CAN, 2 Ethernet ports and 2 USB ports, and allows Docker installation, enough for several containers side by side. Multiple heavy workloads in parallel call for the USR-EG928A: RK3588J with eight cores, a 6 TOPS NPU, 8 GB of LPDDR4 plus 128 GB of eMMC and TF card expansion. The x86 line carries the most headroom: the USR-EC300 runs an i5-7200U with 8 GB expandable to 32 GB, and the USR-EC100 runs a J6412 with 8 GB and 128 GB.
Beyond the image files, snapshots, logs and paging write all the time. eMMC and SD cards have a finite number of write cycles and slower random performance than solid state drives, so several guests reading and writing together show it first as an occasional stall. The way through is to separate what writes often from what runs the system: the system image stays on board storage, logs and historical data go onto a replaceable SD card or a second drive, and the card is stocked as a consumable.
The USR-EC300 leaves the most room here. Beyond the 128 GB wide temperature solid state drive, an mSATA slot and a 2.5 inch bay each take another drive, and the fanless metal enclosure, the 255 level programmable watchdog and the -20 to 60 degrees Celsius rating belong to this one as well. One point belongs on the order early: pages for x86 models only state Windows preinstalled with Linux optional, so the edition and licensing have to go into the quotation request, and where Windows runs inside a virtual machine, how licensing counts per instance belongs in the same question.
Cortex-A53 and A76 both belong to ARMv8 and carry virtualization extensions in silicon. Whether those extensions can actually be used comes down to two things: whether the kernel shipped by the vendor has KVM enabled, meaning the matching kernel module and /dev/kvm are present, and whether the guest image to be installed ships in an arm64 build. Both belong in writing before the order goes in. Finding their absence after unboxing means building a kernel from source, work that rarely appears in a project plan.
Running Windows guests on ARM hardware is another matter, since ARM editions of Windows do not go through ordinary retail channels. That brings the discussion back to the most common requirement: an Ubuntu environment that also has to run legacy software existing only in a Windows build. Such requirements land on x86, where the processors in the USR-EC100, EC300 and EC500 all carry VT-x and virtualization works out of the box.
What needs separating frequently stops short of the operating system layer. Of the common requests, conflicting dependencies are covered by containers or by the virtual environments built into a language; coming back to a last known good state is covered by exporting container images together with configuration files; capping resources for one workload is covered by container quotas. The PUSR ARM line already runs on that road: Ubuntu underneath, Docker, WukongEdge and Node-RED inside, acquisition, protocol conversion and reporting finished on one machine, each workload in its own container.
Cases that do need virtual machines cluster in a few places: two different operating systems have to coexist; the whole environment with its configuration has to move to a standby machine or be copied to another site; or customer IT accepts isolation only at the operating system level and does not count containers.
Explainer pages on fanless industrial PCs run along a different axis: the fan as the only moving part, heat carried out passively through the metal enclosure, five categories of environments that benefit, five self test questions, a comparison table stating outright that fanless models sit lower on processing headroom, and finally IP65 and NEMA 4X. What such pages answer is whether the machine will survive out on site, a necessary half of the question.
Nowhere in that account does it touch how many software environments go onto this machine, how much memory to leave spare, or how many write cycles storage has to absorb. The PUSR contribution covers that other half by splitting the cost into three layers that can be checked against numbers: the ARM side offers the container route first with memory and storage ceilings stated, the x86 side offers full virtual machines while putting editions and licensing onto the quotation request early, and interfaces follow the site list with enough serial ports, Ethernet ports and CAN.
Back to the opening question, the answer lands on what this machine has left when several environments are busy at once. Running one pass of the real workload on a development machine produces those numbers, and the three layers can be checked against them one by one. Where an Embedded Industrial PC differs is not in whether a hypervisor can be installed, but in whether those numbers can be asked for in advance.
1. How is an embedded industrial PC different from a desktop or a commercial mini PC?
The difference concentrates on long term continuous running: fanless aluminium enclosures with passive cooling, wide range input with reverse polarity protection, a wide operating temperature range, hardware and software watchdogs, a 7x24 operating rating, and supply periods running well past consumer cycles. Commercial mini PCs compete on clock speed and price with fast model turnover, and each new generation tends to change connector types and system versions along the way, sending the acquisition logic written into the machine back to rework.
2. Can an embedded industrial PC run Windows?
It depends on the platform. x86 models ship with Windows preinstalled and Linux available as an option, which is how far the official pages go, so the exact edition and licensing have to be written into the order. ARM models ship with Ubuntu and cannot take the standard Windows builds. One question settles it: is there a legacy Windows project file that has to open, or a runtime and dongle driver that only exists in a Windows version?
3. Containers or virtual machines at the edge?
Start from what needs isolating, the operating system or only the dependencies. Conflicting library versions, a quick return to a last known good state, and resource caps on one workload are all covered by containers, at lower overhead and faster startup. Virtual machines take over in two cases: two different operating systems must coexist, or the entire environment with its configuration has to lift onto a standby machine or be copied to another site. On ARM platforms containers are the realistic tier, while on x86 platforms virtual machines are always available.
4. What are the minimum memory and storage requirements for virtual machines?
Each guest runs a complete operating system and takes a resident share beyond the host share. The safer method is to run several environments together under real workload on a development machine, record the steady processor and memory figures, and add 30 percent headroom. Storage is judged on write endurance and random performance rather than capacity: keep the system image on onboard eMMC or a wide temperature solid state drive, put logs and frequently written data on a replaceable SD card or a second drive, and stock SD cards as consumables.
5. Is a fanless embedded industrial PC fast enough?
Fanless designs hand their heat to the metal enclosure, and how much power a given volume can shed continuously has a ceiling, which is why high compute models usually win through a larger chassis or external fins. Local visualization, SCADA nodes, data acquisition and protocol conversion sit inside the comfort zone. Only multi channel video analytics and local model inference need the compute pushed upward, and volume, power draw and case temperature rise together with it.
6. How long does one machine last, and what happens when the model is discontinued?
Seven or eight years of service from the machine itself is not unusual, and storage media together with the power supply section usually reach end of life first. Writing the supply period into the quotation request at order time and keeping two or three interchangeable tiers inside the same series covers most of the risk. The standby unit gets flashed with the same image version on acceptance day, and one real swap gets rehearsed, since an untested image counts as no image at all. Images, parameters and firmware versions are archived by site number and date, and filling in the same fields covers a later model change.
7. What if the interfaces fall short, and can more be added later?
The least troublesome move is copying the interface list straight from the site equipment inventory and keeping one tier of headroom. Where serial standards are still undecided, models switchable between RS232, RS485 and RS422 come first. Finding out after installation leaves common remedies such as an external serial device server or USB expansion, at the cost of a DIN rail section, another power feed, one more network cable and another round of acceptance testing. Sites with a high I/O count can choose models that accept expansion IO modules, and short Ethernet ports are handled by higher port count tiers.
8. Which certifications matter for export?
Check against the delivery market: 3C for the domestic Chinese market, CE together with RoHS and WEEE for the European Union, FCC for North America, RCM for Australia and New Zealand, ANATEL for Brazil, NBTC for Thailand, and MTC for Peru. Connected devices sold into the European Union also often face cybersecurity requirements such as EN 18031, and this information tends to arrive as a list covering several models, so confirming that the target model itself appears on it belongs before the order.
