Why is productising an IoT device design so difficult?

Why productising an IoT device design is so difficult – and how to make it easier, by Mike Scott, Principal Engineer, Qualcomm Innovation Center, Member of Foundries.io team and Louis Moreau, Engineer, Staff/Manager, Qualcomm France S.A.R.L.

We live in a Raspberry Pi world.

For developers of connected embedded and IoT devices, it has never been easier or cheaper to configure a hardware platform based on a capable microcontroller or microprocessor, to plug in shield boards for input and output devices like sensors and touchscreens and then to start writing code.

Thanks to developer-friendly hardware manufacturers such as Raspberry Pi, Arduino and MIKROE, tools and languages such as VS Code and Python and libraries of open-source software including the Linux operating system, anyone with some engineering know-how and a bright product idea can build a viable prototype more quickly and cheaply than ever before.

This means that the world is unlikely, any time soon, to be suffering from a shortage of well-designed IoT device prototypes.

But does it mean that we will also see a rising tide of IoT products hitting the market?

It’s unlikely, and that is in part because productisation – turning a prototype into a product which is manufactured in volume and operates effectively in its intended application – is hard, complex, expensive and fraught with risk.

And this is why developers might benefit from becoming as familiar with tools and frameworks for productisation as they are with Raspberry Pi and other tools and frameworks for product development.

The challenges in IoT device productisation

The leap from prototype to product requires proficiency of various types of challenge – financial, technical, organisational and legal.

Perhaps the biggest barrier to IoT device productisation is money.

Because of the ready availability of the tools and resources described, a prototype can be created with little expense on top of the pay of the development engineers.

Productisation, by contrast, requires capital to fund investments such as the tooling and machinery required to assemble the product, as well as to pay for up-front expenses such as compliance certification services.

Assuming that the capital is available to fund productisation, the developer then faces the technical challenge of transforming a laboratory experiment into a repeatable, scalable production model.

There are various features of a prototype which, in bootstrap development mode, are normally implemented manually on a one-time-only basis.

With the move from IoT prototype to production, these processes need to be automated and streamlined to make them suitable for high-volume assembly operations.

For instance, in the development laboratory, the engineer can take as long as necessary to load device firmware to prototype hardware. In production, however, the process for flashing a golden image of the device firmware to each production unit has a complex set of requirements, including:

• Reliability and error handling – the system must reliably transfer and verify the firmware to avoid bricking devices. Robust error detection, logging and recovery mechanisms are crucial to ensure production efficiency and to minimise waste caused by the creation of faulty production units
• Speed and throughput – high-volume production operations require the flashing process to be fast. This calls for efficient data transfer protocols and the ability to flash multiple devices concurrently
• Security and integrity – the production process is itself an attack surface for malware and cyber-attacks. The system must protect the golden image from unauthorised access or modification and verify the integrity of the flashed firmware on the device. This involves secure boot mechanisms, cryptographic checks and tight control of access to the programming system itself

Security is in fact one of the biggest challenges in productisation: The biggest mistake that IoT product developers make is to neglect the need for IoT device security until the prototype design is locked down.

After-the-fact implementation of security functions such as secure boot, secure key and data storage, over-the-air (OTA) update capability and secure connectivity can be incredibly disruptive to a working product design.

We have often seen late development of essential security capabilities lead to catastrophic delays and cost, because it forced the developers to undo and rework aspects of a working system design that were rendered inoperative after building in secure boot or other security functions.

But let’s assume that the device has been made secure: Before a prototype design can be deemed ready for release to market, it needs to be certified for compliance with relevant standards and regulations, such as the European Union’s Radio Equipment Directive, the CE mark and the Regulation on Hazardous Substances (RoHS) rules.

Equivalent rules and regulations apply in most other markets worldwide.

The compliance and testing effort for new products can surprise new IoT device developers who have not previously learned how expensive and time-consuming it can be. 

And it should be remembered that productisation is not just about making a product ready for volume production: The manufacturer’s responsibility for the product continues long after shipment.

Some manufacturers have always taken responsibility for the customer’s user experience after shipment, often because of their recognition of its effect on the manufacturer’s brand.

But post-shipment maintenance has become a matter of necessity now for any companies that make or market products in Europe, with the enactment of the European Union’s Cyber Resilience Act.

This makes manufacturers of IoT devices responsible for the prompt delivery of patches to devices in the field that are exposed to known cyber-threats.

This calls not only for OTA updating, but for additional capabilities including device fleet management and automatic generation of a software bill-of-materials (SBOM).

Productisation tools and frameworks move into the spotlight

Developers have access to a very broad set of tools and environments to support the hardware and application development processes.

Productisation, by contrast, has attracted far less attention from the developer community, and has not seen the emergence of a similar ecosystem for productisation tools, despite the complexity of the processes described above.

In fairness, some manufacturers and suppliers do provide support for discrete parts of the productisation process.

MCU and MPU manufacturers in particular back their products with documentation and guidance to support processes such as firmware flashing and fusing, but this guidance is specific to their products rather than generalised for the entire category of IoT devices.

Chip manufacturers have also started to provide turnkey security services which enable IoT device makers to, for instance, outsource the provisioning of products with private keys – the Infineon OPTIGA Trust service is an example of this.

Likewise, Qualcomm wireless edge services (WES) secure provisioning capability enables the generation and use of cryptographic keys that are applied OR engaged using unique device keys.

These keys are used to: Provision data to the device post-sale and over-the-air in a security focused way; sign data on the device.

The range of productisation challenges described above, however, calls for a wider environment to provide a framework for managing the transition of a product idea through development to production and on to device management and updating – and through to secure decommissioning.

This overarching framework needs a wider scope than a single point tool or service can provide: This was the ambition behind the creation of the FoundriesFactory platform from Foundries.io for Linux OS-based embedded devices.

The platform orchestrates a suite of open-source tools, such as Docker for container development and The Update Framework (TUF) for OTA updating, around a comprehensive and granular database for code and device identities, enabling a Continuous Integration/Continuous Development (CI/CD) process backed by rollback capabilities and automatic generation of SBOMs unique to each production unit.

At every step of the way between prototype development and decommissioning, the product’s codebase, security and update status are automatically recorded.

The information is readily available to support the automation of processes such as firmware flashing, exposure checking and OTA updating.

And a convenient interface between the FoundriesFactory software and the Edge Impulse platform for edge AI model development, compilation and installation ensures that the growing number of AI-enabled IoT products can benefit equally from productisation support.

The existence of a platform to support cradle-to-grave productisation does not negate the difficulties described above: Productisation is challenging and always will be.

But a framework for device data integrated with a coherent set of tools for the essential security, device management and production functions enables automation, security to be built in from the beginning of the development process, so that the prototype – the expression of the developer’s bright idea – can get to market as smoothly and quickly as possible.

Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries. Linux® is the registered trademark of Linus Torvalds in the US and other countries.