- Select Language
R366-S 5.5-inch Industrial PDA | Qualcomm Octa-cor...
RS51 4G Rugged Handheld Terminal | 6.3" FHD+ ...
The F505 Handheld PDA is a compact, high-performan...
RT80 5G Rugged Tablet | 10.1" FHD 400nit | Un...
R350C 4-inch Industrial Handheld PDA | Qualcom...
The PM158-1 is a 15.6-inch portable touchscreen mo...
The conversation about factory computing spent years stuck on one question: push everything to the cloud or keep it local. Watching plant teams over the last eighteen months, I think that framing has outlived its usefulness. Real deployments are not binary. They settle into three distinct places to put computing power, and the deciding factor is rarely ideology — it is latency tolerance, how much data crosses a wire, and where a human has to stand to do the work. This is a look at how that split is settling out, and what each layer needs from its hardware.
The shift started with arithmetic rather than architecture. A single vibration sensor array on a press line can generate more data in a shift than a plant's uplink can move cheaply, and nobody is going to pay to ship waveform samples across a continent so a dashboard can colour a tile green. Once finance saw the recurring line item, the default answer quietly changed from "send it all up" to "send up what matters." That single change created the need for local capacity at more than one level, which is why industrial edge hardware now appears in procurement plans that never mentioned it two years ago.
What followed was not one device replacing another. It was work sorting itself by how fast an answer had to come back.
Closest to the process sits a machine-adjacent gateway. Its job is unglamorous: collect from sensors, speak whatever protocol the controller insists on, normalise the stream, and forward a fraction of it. It lives in a cabinet that was never designed to hold a computer, often next to equipment that vibrates and runs warm, and it cannot be large.
The Palm-sized miniPC fits that cabinet because the constraint is physical before it is computational. A unit that mounts on a DIN rail or behind a panel needs no fan, no service aisle, and no second thought about clearance. The payoff is placement: putting acquisition right beside the asset removes the long analog runs and protocol translators that used to eat the budget.
A Palm-sized miniPC mounted inside a machine-side control cabinet.
The trade is capacity. A gateway of this class handles acquisition and light filtering, not model training. Teams that ask it to do more end up rebuilding the cabinet anyway.
One level up sits the box that several gateways report into. Here the questions change from "can I reach the sensor" to "how much history do I keep, and do I run inference locally." That is a storage problem as much as a compute problem, and it is where a four-bay design stops being a nice-to-have.
The WTR PRO AMD lands in this position because it pairs Windows software compatibility with drive bays that make retention a local decision. Plants running quality records, vision captures, or audit trails want those on disk they control, not in a metered bucket. Running inference here also means the line keeps its anomaly detection when the uplink drops, which is precisely when operators most need it.
A WTR PRO AMD unit serving as the local aggregation and retention point.
In practice this layer absorbs the surprises. When a new camera gets added or a retention policy doubles, the box with spare bays and headroom is the one that does not need a capital request.
The third place computing lands is in a technician's hands, and it is the layer most often specified last and regretted first. A maintenance engineer walking to a fault needs the same local data the aggregation box holds, plus the ability to log what they found before walking back. Screen quality under plant lighting and a radio that works through steel matter more here than raw benchmark scores.
The RT81 Rugged Tablet is built for that walk: a 10.1-inch FHD panel at 400 nits that stays legible under high-bay lighting, an octa-core Qualcomm platform for the maintenance client, Android 13 for the app catalog plants actually deploy, and 4G so the device is useful between Wi-Fi cells. Sealing and drop rating are not marketing on this layer — they are the difference between a tool that survives a year and a replacement line item.
An RT81 Rugged Tablet used for a maintenance walk on the plant floor.
Where teams get this wrong is buying a consumer tablet and adding a case. The case fixes the drop; it does nothing for glove operation, sunlight legibility, or a radio that holds up next to a running press.
A simple test sorts most decisions. If a delayed answer stops production or risks a part, the computation belongs at the gateway or the aggregation box, never upstream. If the answer feeds a weekly report, the cloud is fine and cheaper. Most plants discovered they had been treating everything as urgent, which is why their uplink bill looked the way it did.
The second test is blast radius. A gateway that serves one asset can fail without stopping the plant. An aggregation box serving twelve lines cannot, which is why it gets the storage redundancy and the maintenance window. Assigning by consequence rather than by convenience is what keeps an outage small.
An under-discussed driver is compliance. Quality records, operator identifiers, and vision captures increasingly fall under rules about where they may be stored and for how long. That pushes retention local by default and makes the aggregation layer a governance decision rather than a performance one. Teams that ignored this found themselves retrofitting storage under a deadline, which is the most expensive way to buy disk.
The pattern I expect to hold through the year is retention moving inward first, then inference following it, because once the data is local the cost of running a model against it drops to nearly nothing.
| Layer | Primary constraint | What it runs | Failure impact |
|---|---|---|---|
| Machine gateway | Physical space, heat | Acquisition, protocol conversion, filtering | One asset |
| Aggregation box | Storage depth, headroom | Retention, local inference, reporting | Multiple lines |
| Mobile interface | Legibility, sealing, radio | Maintenance client, inspection logging | One technician's shift |
Read that table as a procurement argument. Buying one class of device and stretching it across all three rows is the most common way these projects run over, because the constraint that governs each row is different and no single box satisfies all of them.
Two failures repeat. The first is under-specifying the middle: teams buy gateways generously and then ask one of them to hold retention, which fails the first time a retention policy grows. The second is over-specifying the handheld — a ruggedised slab bought for its processor when the operator only needed a legible screen and a reliable radio. Both come from specifying the fleet as a single purchase instead of three jobs.
The fix is boring and it works: write down the three jobs, the constraint that governs each, and the consequence if each one stops. The hardware choice becomes obvious once those are on paper.
Start with one line, not the whole plant. Instrument it, place a gateway, add an aggregation box sized with bays to spare, and give the maintenance team a handheld they will actually carry. Run that for a quarter and the uplink bill, the fault response time, and the retention question will all answer themselves with local numbers instead of vendor slides.
The broader resilience discussion for rugged tablets and smart glasses covers how the mobile layer pairs with head-worn devices for hands-free inspection, and the rugged tablet range lists the sealing and display options for the maintenance layer.
Three jobs, three constraints, three classes of hardware. Once a team stops shopping for one device that does everything, the architecture usually falls into place within a quarter.
