Most embedded design starts from the happy path and adds error handling around it. Medical wearables need the opposite discipline: start from every plausible way the device can fail, decide what the safe behavior looks like in each case, and build the happy path as the case that doesn't need special handling. It's a mindset shift more than a specific technique, and it shows up in a handful of concrete design areas.
Graceful degradation over hard failure
A device that stops entirely on an unexpected error is easy to reason about but often the wrong choice — a total stop means no monitoring, no alerting, and no data at all during the failure window. Where possible, the better design degrades functionality in a defined, predictable way: falling back to a lower-power or reduced-feature mode, continuing to log locally even if a wireless link is down, or continuing core sensing while a non-critical subsystem (like a display or a secondary sensor) is disabled. The key discipline is defining what "degraded but still useful" means for the specific device up front, rather than discovering it by accident during an actual field failure.
Watchdogs and self-test as continuous verification
A hardware watchdog timer that resets the device if firmware stops responding within an expected interval is a baseline protection against firmware hangs — the kind of bug that's hard to fully eliminate through testing alone, especially as firmware grows in complexity over a product's life. Beyond the watchdog itself, periodic self-tests — confirming a sensor is still producing plausible readings, confirming battery and storage are in expected ranges, confirming the wireless stack hasn't silently wedged — turn "is the device actually working" from an assumption into something the device continuously checks and can report on.
Power-loss handling that doesn't lose critical state
Battery-powered medical wearables will experience unexpected power loss — a depleted battery, a dropped charging connection, a battery swap — and the design question is what happens to in-progress data and device state when that happens without warning. Writing critical state (the current session, the last N readings, calibration data) to non-volatile storage frequently enough that a sudden power loss doesn't lose meaningful data, and structuring those writes so a power loss mid-write doesn't corrupt the stored state either, are both necessary. This usually means treating power loss as a routine event to design around, not an edge case to tolerate occasionally failing.
Design for the failure case first
The single practice that separates reliable medical wearable firmware from firmware that merely works in testing is ordering: work through the failure modes and their required safe behaviors before writing the feature code, not after. It's slower up front and it's what prevents a design where safe-failure behavior has to be bolted onto an architecture that wasn't built to support it.
Practical takeaway
Reliability engineering for a medical wearable is a design discipline, not a checklist applied at the end — it has to shape the firmware architecture, the hardware's power and storage choices, and the test plan from the start. This is central to how we approach firmware work for devices where failure has real consequences.