Prototypes can look convincing: sensors report, phones control devices and the cloud draws charts. Field failures often come from conditions absent on the bench: sudden power loss, router restarts, invalid sensor readings, duplicate messages or a half-written firmware image.
What separates a prototype from a product
A prototype tests whether an approach works. A product must run across device batches in real conditions, with a way to diagnose, recover and assign responsibility when it fails. Productization establishes reliable boundaries as well as adding features.
Define supported hardware, degraded behavior for peripheral failures, configuration storage, device identity, offline buffering, firmware updates and rollback, production checks, logs and fault codes.
Fix the hardware and interface baseline
Before firmware development, confirm the MCU, Flash, RAM, peripheral interfaces, power supply, sensor accuracy, communication module and operating environment. Track PCB, BOM, peripheral and pin changes so behavior across hardware revisions can be explained.
If documentation is incomplete, assemble an interface list, protocol notes, firmware versions, essential control logic and reproducible test steps. Record unknowns as risks rather than deferring them to integration.
Design firmware for failures
Plan watchdog handling, task timeouts, disconnected sensors, storage failures, corrupt configuration, low voltage and unexpected resets. Validate critical settings, provide safe defaults and retain the last valid configuration where appropriate. Logs and fault codes should explain what happened before a restart.
For an RTOS, define task responsibilities, priorities, queue sizes, shared resources and maximum blocking time. Resource-limited MCUs need protection against uncontrolled allocation, full log storage and a peripheral task blocking the system.
Test more than a healthy network
Wi-Fi, cellular, Bluetooth, serial and fieldbus links fail differently. Distinguish sent, received and processed messages; track command delivery, receipt, execution and failure separately. A single success flag makes diagnosis ambiguous.
Define whether to buffer offline, how much to retain, how to replay and how to deduplicate. Messages usually need device ID, sequence, device time, protocol version and quality flags. The platform also needs a policy for whether late data can trigger business actions.
Give OTA a recovery path
OTA needs recovery when downloads stop, validation fails or a new image cannot boot. Depending on hardware constraints, use A/B partitions or safe rollback, signed packages, compatibility checks, staged releases, progress tracking, timeouts and result acknowledgments.
For control or safety-relevant devices, avoid fleet-wide upgrades in one step. Validate internal units and a small field cohort, observe reboots, connections, operating parameters and faults, then expand the rollout.
Production testing and version control
Engineers can debug prototypes individually; production needs repeatable flashing, configuration and tests. Record serial number, hardware version, firmware, key settings and test results. Detect duplicate serials and incomplete tests.
Test startup, long runs, repeated reboots, network changes, sensor faults, edge inputs, storage endurance and rollback. Include temperature, vibration or electromagnetic testing where the target environment requires it.
Handover and field diagnostics
A usable handover includes source code, dependencies, build instructions, hardware/firmware compatibility, protocols, configuration, flashing and production tests, OTA and rollback, fault codes, log access and known limits.
Support cannot depend on attaching a debugger every time. Expose essential logs, versions and runtime status; show last connection, reset cause, network quality and command history on the platform. Make diagnostics part of normal operations.
Engineering judgment · context matters
Design how the device recovers before adding more features
An hour on a desk tests the main path. Field devices encounter power loss, full storage, unstable networks, failed sensors, duplicate commands and interrupted upgrades. Leave recovery paths and diagnostic evidence for each condition.
Before a pilot batch, freeze hardware, firmware, flashing settings and production test steps. Complete soak, temperature, power disturbance, communication failure and interrupted-update tests. An occasional freeze without reproducible logs is not resolved by restarting.
Prepare these materials for kickoff
- Sample devices, MCU and peripheral list
- Schematics, interface list or confirmed pin definitions
- Existing firmware, build environment and known issues
- Protocols, platform goals and reporting frequency
- Site networking, power and environmental conditions
- Required remote support, OTA and production test scope
- The highest-risk path to validate first