Start with actual operating conditions

Before selecting an MCU or designing an API, document where the device will operate. Power, temperature, humidity, electrical noise, network availability and maintenance access shape the architecture. A workbench with a stable power supply and Wi-Fi does not reproduce an industrial installation.

Turn these conditions into verifiable requirements. What happens during a prolonged network outage? How does the product recover after a power failure? Which functions must remain local? The answers inform memory, storage, isolation, connectivity and firmware behavior.

Design for manufacturing and service

A bill of materials must account for availability, alternative components and assembly processes. Test points, factory programming, version identification and traceability make it easier to investigate a unit that behaves differently from the rest.

Define acceptance tests for each unit and keep hardware and firmware versions identifiable. Support teams need to connect a device to its circuit revision, configuration and running software.

From concept to field operation

  1. 01

    Requirements

    Environment, interfaces and failure behavior.

  2. 02

    Prototype

    Circuit and firmware to validate the solution.

  3. 03

    Validation

    Recovery, integration and manufacturing tests.

  4. 04

    Operation

    Deployment, diagnostics, updates and maintenance.

Throughout the lifecycle: identifiable versions, documentation and acceptance criteria.

The transition to production includes manufacturing, diagnostics and support, alongside prototype validation.

Make failure behavior part of the design

Watchdogs, storage recovery, persistent queues and message retries need explicit rules. Retrying a read request is different from retrying a command that authorizes a sale or operates an actuator. Consider idempotency, acknowledgment and safe states.

Remote updates need a recovery path as well. Verify integrity, compatibility and behavior when interrupted. Depending on the product’s resources and requirements, the strategy may include alternate partitions and rollback.

Account for the target market

For US product teams, make requirements, acceptance criteria and responsibilities across manufacturing, firmware and platform engineering explicit. English technical documentation and reproducible handoff packages support review, procurement and ongoing development. Identify testing and approval requirements for the specific product and intended use.

For Brazilian operations, account for replacement costs, sourcing lead times, field service availability and integration with installed equipment. Brazilian Portuguese documentation and clear diagnostic procedures help local teams operate independently.

What the transition should deliver

Before moving beyond the prototype, establish documented architecture, identifiable versions, manufacturing tests, acceptance criteria and an update and support plan. The goal is repeatable manufacturing and predictable operation, with understood risks and clear priorities.