Firmware Questions for Every IoT Developer

From smart forks monitoring your eating speed to autonomous industrial farming equipment analyzing soil and crop conditions, it’s hard to find an industry where forward-thinking makers haven’t yet staked a claim with connected devices. Now that connectivity has paved the way for such applications from the whimsical to the consequential, IoT developers need to prioritize their firmware architecture to launch a successful product with happy, loyal customers.

While IoT devices' benefits range from comfortable to life-saving, their sheer ubiquity demands that they function well. It sounds obvious, but it doesn’t take long to uncover stories proving it’s not. Consider Nike and its Adapt shoes with a $350 price tag and smart shoelaces that couldn’t be tightened without a firmware update. Or the Vowerk robot vacuum that malfunctioned and, due to cloud-related complications, could only be updated offline by sending users USB sticks to update. Convenience, novelty, and innovation mean little when functionality is compromised and the repair process is onerous.

Connectivity

Connectivity has allowed for the development and use of smart technology to impact beyond what we imagined even a decade ago. But these developments require a major shift in how hardware developers approach products and how to keep them functional. Gone are the days of writing static firmware for specific device Applications or commoditized products released into the world with which developers have no further interaction or engagement. To launch a successful product, IoT device manufacturers need to invest just as much in firmware development as they do in design.

Connectivity changes everything for hardware developers. Whether through BLE on phones or LTE or mesh networks like Zigby, devices are connected and to the cloud and often carry personally identifiable information (PII) or other sensitive data. This connectivity, the high price point of many IoT devices, and the essential function they serve across all audiences, both consumer and industrial, mean that device manufacturers must be more intentional about firmware.

Three questions that IoT hardware developers must consider:

How Will You Monitor Devices?

The traditional model of waiting for the end-user to discover and report the problem and then require the device’s return for evaluation, servicing, and repair, is inefficient and costly. And in a saturated IoT market, the risk of releasing a product that effectively uses its customers as testers can and will greatly impact demand. A better alternative is to account for potential bugs and issues by baking in diagnostic capabilities that monitor, record, and alert you to potential problems without requiring customer action. Building such capabilities into embedded systems enables better monitoring of performance, stability, and the overall health of a single device or an entire fleet and the ability to correct issues before they become noticeable problems that threaten brand reputation.

How Are You Going to Fix Problems?

Hardware manufacturers will ship products that require an update or patch – that’s inevitable. Knowing about fleet-wide issues and proactively resolving them before customer discovery can strengthen security and functionality without disrupting the user’s experience. Real-time monitoring of mission-critical metrics can allow you to understand issues, the affected versions, and the prevalence and frequency of those issues across your feet. Performance data like battery life, connectivity state, or memory use can be monitored and used to trigger debugging and resolution before users notice the issue. As users can be remarkably lax about maintaining and updating products, IoT device makers who can preemptively discover and repair issues offer a superior customer experience and more robust security by shifting the responsibility away from device users.

How Are You Treating Security?

IoT security is growing more and more in importance due to customer demand and regulatory requirements. I’d argue that these four developments are fast becoming non-negotiable for smart device manufacturers:

• Devices must be updateable.
• The trusted boot is no longer optional. It would help if you had a chain of trust to control the firmware running on your device.
• There has to be a way to rotate secrets. Whether that means a set of encryption keys or other secrets to make devices functional, they must be dynamically changed to avoid situations whereby a compromise of one device leads to others' compromise.
• Avoid using a master secret. This is certainly a high bar that requires infrastructure – but companies that get caught with one master secret compromising every device have no future.

As connected devices continue to mature, the industry will continue to see a virtuous cycle of creating value for customers as hardware improves. By approaching IoT development and firmware updates with the same kind of iterative and responsive processes ingrained within software development, device manufacturers can eliminate customer frustration while delivering a more reliable, valuable, and stickier product.