Boston, MA. When it comes to the IoT, success is simple but not easy, according to Jan Niewiadomski, lead product developer at Intelligent Product Solutions. Speaking at the collocated BIOMEDevice and Embedded Systems Conference this week, he described his company as having an integrated team of 100-plus engineers skilled in electrical engineering, embedded software development, mechanical engineering, user-interface design, and production transition.
Any IoT project, he said, will involve technical challenges as well as external dependencies, security issues, and project constraints, including budgets, unit price, and schedules. A common problem, he said, involves feature-overthinking and trying to do too much. Don’t try to attack every single market need but rather focus on MVP—the minimum viable product.
Further, he said, it’s important to keep in mind product evolution. Is the next generation software-defined, with over-the-air updates necessary? Risk management is also necessary—beware a new feature that could torpedo your whole project.
Niewiadomski noted that an IoT product is likely to be developed simultaneously with app necessary to support it, so be mindful of potential interdependencies that could require considerable rework late in the development cycle. Also be prepared to add unexpected features—what you should expect are “TBDs,” he said, with an architecture capable of handling them.
He described several external dependencies. Engineers want to jump right into the technology side, but need to contend with “large immovable objects that they must navigate around and accommodate.” The external dependencies involve the supply chain, third-party software developers, tooling cycles, contract manufacturers, and last but not least, regulatory issues. If your device has wireless connectivity, you can facilitate regulation issues through the use of FCC-certified modules, for example. If your device employs cellular functionality, you can expect to spend a big chunk of time getting carrier approval. If you are building a class II medical device, you can expect to spend time submitting and amending a 510(k) filing to the FDA.
Niewiadomski noted drawbacks to using precertified modules: they may provide shorter time to market but will drive up BOM costs and device size. A wearable fitness device, he said, can’t be made up of modules but will require a highly integrated hybrid design, likely based on a custom chip.
He also touched on security issues, including device identification and authentication, device serialization, credentials management through a contract manufacturer, and safeguards against reverse engineering and counterfeiting.
Finally, Niewiadomski discussed transfer to manufacturing. Design engineers, he said, might consider a product ready, but production engineers may see a need for an additional six months of work. Handoff is often not well understood, he said, leading to potential yield problems. It’s important to understand up front what to do to avoid to fix something after handoff. “Build in manufacturing support capabilities,” he advised. “It costs almost nothing at the frontend and saves a lot at the backend.”
Throughout his presentation, Niewiadomski described several products his company has worked on, including the iKeyp smartphone-enabled personal safe that locks up prescription medications and the AdhereTech next-generation smart pill bottle.