IoT Product Design in India: From Idea to a Manufacturable Device
Most IoT projects do not fail because the idea was wrong. They fail in the gap between a working prototype and a device that can be built, certified, installed and supported by the hundred or the thousand. This article walks through how that gap is crossed in a product design project, and calls out the decisions that are expensive to reverse.
The stages of an IoT product design project
Requirements and constraints. Start with the environment and the economics: where the device is installed, how it is powered, how long it must last, what it may cost at volume, and which approvals it needs. A one-page spec that hardware, firmware and the customer all agree on prevents most later arguments.
Architecture. Decide how the device senses, computes, communicates and is powered, and what runs on the device versus in the cloud. This is where connectivity, processor class and memory headroom are chosen.
Hardware design. Schematic, component selection, PCB layout, power design, antenna placement and test points. Good layout and good test access save weeks during bring-up.
Firmware. Bootloader, drivers, power states, communication stack and update mechanism. Plan the update path now, not after the first field failure.
Prototype and bring-up. Build a small number of boards, power them up in a controlled order, and prove each subsystem before integrating them.
Validation. Test for temperature, humidity, vibration, battery behaviour and radio performance. Run EMC pre-compliance checks before the formal lab visit.
Design for manufacturing and a pilot run. Review the design with the manufacturer, build a pilot batch, and fix what the line reveals.
Production and field support. Add production test, traceability and a monitored update process.
Decisions that are hard to change later
Connectivity. Radio technology, antenna type and certification path shape the board, the enclosure and the cost.
Processor and memory headroom. Leave room for firmware growth, security features and update images. Running out of flash late in a project is a classic mistake.
Power architecture. The sleep current of every component, not just the microcontroller, decides battery life. See Battery Life Claims vs Reality.
Enclosure and ingress protection. Dust, water and heat requirements drive materials, seals and thermal design.
Security. Secure boot, unique device credentials and signed updates are far cheaper to design in than to retrofit. See Zero-Trust IoT.
Designing for Indian operating conditions
Heat, dust and humidity. Plan for wide temperature ranges, sealed enclosures and conformal coating where moisture is a risk.
Power quality. Surges, brown-outs and noisy supplies are common, so input protection and brown-out handling belong in the design.
Patchy connectivity. Rural and industrial sites often have weak coverage. Store data locally and send it when the link returns.
Component supply. Many parts are imported, so choose components that have alternates and check lead times before the design is frozen.
Questions to ask a design partner
Who owns the hardware design files and the firmware source code at the end of the project?
How do you test power loss during updates, and what happens to a device that fails one?
Which approvals does this product need in India, and who manages them?
Can you show a product that has been through pilot and production, not just a prototype?
What does the handover to manufacturing include: BOM, assembly drawings, test procedures and fixtures?
Where to start
Begin with the one-page requirements spec, then review the connectivity, power and security decisions before any board is drawn. For more on what goes wrong after the prototype, read Why Most IoT Products Fail After the Prototype and Designing for Manufacturing Reality.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see www.eurthtech.com/solutions.
Comments