Designing for a Site You Cannot Visit

There is a category of deployment where the ordinary rules of hardware design stop applying, and it is defined not by the technology but by the cost of standing next to the device. A pumping station four hours from the depot. A sensor on a wind turbine that needs a lift and two technicians. A monitoring unit in a mine, a substation on an island, a data logger in a field a farmer crosses twice a year. Once a site visit costs more than the equipment, the engineering has to be re-argued from a different starting assumption: nobody is coming.

That assumption changes what a bug is. On a bench, a device that hangs once a month and needs a power cycle is a minor defect to be fixed in the next firmware release. On an unreachable site it is a total failure, because the power cycle is the thing that cannot happen. Everything below follows from taking that seriously.

Power is where most remote designs are won or lost, and the mistake is almost always optimism in the average case. A battery budget calculated from typical current draw at room temperature will be wrong, because the field is not typical or room temperature. Lithium chemistry loses usable capacity in the cold, self-discharge continues whether the device is doing anything or not, and the transmit current spike that lasts two seconds is what actually determines whether the cell can deliver at all when it is at minus twenty. Budget against the worst month, not the mean, and measure the finished device rather than trusting the sum of datasheet numbers — the difference between the two is usually a sleeping peripheral somebody forgot to disable.

Communications need the same pessimism. The question is not whether the link works but what the device does during the hours or days when it does not. A design that transmits and forgets loses everything that happened during an outage, which is frequently the interesting part. A design that stores and forwards needs to decide how much history to keep, what to drop first when memory fills, and how to catch up without flooding the server when a hundred devices reconnect simultaneously after a regional outage. That last one has taken down more back ends than any attack.

Then there is diagnosis, which is the requirement people leave out. When something goes wrong on a site you cannot visit, the only evidence you will ever have is what the device chose to send before it stopped. That means a health message alongside the payload — battery voltage, temperature, uptime, reset reason, signal quality, memory headroom — and it means storing the reason for the last reset across the reset. A device that reboots silently is telling you nothing; a device that says "watchdog timeout, uptime 41 hours, temperature 68°C" has just saved somebody a helicopter.

Failure modes deserve a decision rather than a default. What should the device do when its sensor reads out of range: report the value, report a fault, or stop reporting? When its clock is lost? When flash write fails? These have right answers that depend on the application, and the wrong answer is whichever one the library did when nobody specified. The general rule that survives contact with the field is that a device should degrade to something useful rather than stopping: a unit that keeps reporting temperature after its humidity sensor dies is worth more than one that goes silent because part of it failed.

Updates over the air are where remote deployments get bricked, and the requirement is not that updates work but that a failed update cannot leave the device unbootable. That means two firmware slots, a bootloader that verifies before switching, and an automatic rollback if the new image does not check in. This costs flash and development time and it is the single feature most likely to save the deployment, because the first update that goes wrong is not a possibility, it is a schedule.

Physical design carries the same logic. Connectors corrode, glands leak, cable entries admit water on the axis nobody tested, and a desiccant pack has a service life. Anything that needs periodic attention — a filter, a battery, a calibration — has just become a site visit, so the design question is how to remove the need or extend the interval past the point where somebody would be going anyway for another reason.

Finally, plan the fleet rather than the device. Ten remote units and four hundred are different problems: at four hundred you need to know which firmware version each one runs, which ones have not reported since Tuesday, and which are drawing more current than their siblings. That comparison across identical devices is the most powerful diagnostic available in remote deployments and it is free once the health data is being collected, which is a good reason to collect it from the first unit rather than adding it when the fleet gets confusing.

None of this is exotic engineering. It is ordinary engineering done under one unusual constraint, held consistently: assume the device is alone, and design so that being alone is survivable.