Low power IoT design is challenging because a connected product comprises of hardware, firmware, software, and network. Add in power requirements, data message size, and data timeliness - it is clear that design must be carefully considered and optimized not only at the point of manufacture but also with consideration of field maintenance. I’m happy to share with you my perspective on how to get products quickly to market while reducing IoT design risk and maintaining maximum flexibility.
When the device is initialized by being powered up or restarted (button on the device) the program counter jumps to the Bootloader section of ROM memory and waits there for instructions. If there is no Bootloader the program counter will go to the start position of the flash memory (0000H) and start executing the instructions which are written - typically the main program flashed to the device.
The key to reducing IoT design risk is a well-designed Bootloader that updates functionality and configurations once the device is in the field. Tweet this
Most all devices will come with some stock device firmware update (DFU) capability. The following design elements will reduce your update risk factors substantially:
Make bootloader updates as part of your DevOps process reducing human error of ongoing management and maintenance. Tweet this
As the IoT market consolidates only the paranoid will survive. Due diligence starts by considering how exposed you are if someone were to hack the actual device itself. This is because although you try to limit physical access to the device, if someone is determined enough they will gain access.
An IoT solution should utilize Advanced Encryption Standard (AES) 128-bit encryption to secure the transfer of firmware to the unit and use device specific encryption keys to further reduce the security footprint.
Device updates should be managed through a central application. This is typically a cloud solution as part of an overall IoT platform.
This device operations management app needs to identify and group devices based off of their type, purpose, etc. most solutions do so through the use of metadata tags that will allow you to capture the various attributes of a specific device. The use of tags this makes feature management a lot easier, as you can define business rules through a combination of tag values.
The device operations management app should also have the capability to employ staggered rollouts which will reduce the risk of systematic failure due to a faulty update.
Especially in the case of over-the-air(OTA) it is important to minimize the size and time of an update. This can be accomplished through what is called differential updating. A differential update contains only the changed parts of the firm wire and not the entire image itself.
A differential update can vary in its scope requiring anything from and entire library update or something as simple as a single line of code. This change management process can save as much is 80% efficiency versus monolithic firmware updates.
A key element good design includes building in a failsafe. By adding logic into your Bootloader DFU you can add a checksum on the update and verify it was transmitted successfully before you ever update or write over the existing firmware image.
Is part of the failsafe process a copy of the original firmware is moved into that double buffer while the device reboots. If for some reason the firmware fails to boot successfully then the boot loader will swap out firmware images as part of a rollback strategy. Alerts and notification logic should be incorporated to notify the device operations management application when an issue occurs.
The failsafe process will need to be thoroughly tested to ensure that you’re not stuck in an infinite update loop.
If you need any help with the architecture or engineering of your IoT solutions, feel free to reach out to me.