A device mounted in a working plant lives a different life than the computer on your desk. It runs around the clock. It often has no keyboard. It sits on a wall, in a warehouse, in a cold store or by a loading door, in the draught and the dust. Above all, nobody is standing in front of it to restart it when it freezes.
Anyone building hardware for places like that learns quickly that the hard questions are not about features. The features usually take two weeks. The remaining months go into what happens when something breaks.
The network is never there when you need it
Wireless coverage in a production hall is a fiction that looks very convincing on a network plan. In reality a stack of steel sits between the access point and the device, a forklift drives past, and the connection is gone for forty seconds. A terminal that responds with an error message and leaves the worker standing there is worthless.
So the device has to keep working without a network. Bookings, scans, times: everything is accepted locally, stored locally and pushed later once the connection comes back. That sounds like a detail and is in fact the hardest requirement in the whole project, because it immediately hands you questions you would rather not have. What happens when two offline devices book the same pallet?
Remote maintenance is not an add on
Once more than three devices are out in the world, updatability decides everything. A device that somebody has to visit with a USB stick is a prototype, however much it looks like a product. With thirty devices across six sites that is a travel cost problem. With three hundred it is the end of the business case.
Remote updates therefore belong in the design from day one, built so that they still hold when the update itself was faulty. A device that breaks halfway through an update and is then unreachable is a brick on a wall. Two system images and an automatic fallback to the old one when the new one fails to start cleanly: not elegant, but it saves weekends.
Coming back on its own after a power cut
Power goes down. A fuse blows, somebody pulls the wrong plug, the cleaning crew comes through at night. Afterwards the device has to return by itself, with the right application full screen, logged in, no mouse cursor, no login prompt and no system service pushing a notice into the picture.
This is unglamorous work. It also decides whether the workforce trusts the thing. A terminal that has to be touched after every power cut gets worked around within a month, and then people go back to paper.
Operation that needs no training
The device must not force anyone to operate it. Someone wearing gloves with a pallet in front of them has no free hand for a four level menu. Scan, tap one large field, done. If the screen is too small or the button too fiddly, the device does not get used incorrectly. It simply does not get used.
We build devices like this in our IoT research lab in the Tegernsee valley, usually in small batches and for one specific job. What stands out every time is that the demands on the electronics are modest. The demands on how the thing behaves when something fails never are. More on that under IoT.
Frequently asked questions
Is custom hardware worth it, or will a tablet do?
For a trial a tablet will do. In continuous operation it usually fails on the battery, the mount and the fact that it cannot be locked down and updated centrally. Where you want to switch a device on and then forget about it, custom hardware pays off.
How small can a production run be?
Small batches in the low tens are workable. The effort sits in the software and the setup anyway, not in the unit count.
What if a component goes out of stock?
That is exactly why we stay with components that are widely available and write the software so it survives a swap.
If you have a device in mind that has to survive daily operation, we will come and look at the conditions on site, with no obligation and no sales pressure.
More on our work with devices and small batches: custom hardware development.