[ad_1]
One of the key capabilities that a microvisor-based architecture allows is over-the-air (OTA) firmware updates, but in a way that does away with requiring 2 versions of the firmware on the device in case of failures.
Guaranteeing device reachability for firmware updates
The division of responsibilities in the microvisor architecture ensures reliable and consistent connectivity for IoT devices. The microvisor takes care of maintaining the IP stack, as well as the firmware and drivers for Wi-Fi and/or cellular modems. I.e. everything your device needs to get connected and stay connected.
This means that even in the event of unexpected application failure, the device remains connected and reachable thanks to the microvisor component remaining connected and reachable. This includes all the components highlighted in the diagram.
The reliability of the connectivity, which eliminates the risk of “bricking” the device, opens up new opportunities for firmware development. This allows for decoupling the process of hardware manufacturing from the firmware development process. With the ability to perform frequent and reliable firmware updates, hardware manufacturers can produce devices even before the firmware has undergone complete testing. (It remains to be seen, however, if this level of agility, previously only seen in web and cloud development, will be adopted by device builders.)
As with any approach to FOTA (firmware updates over-the-air), saving bandwidth is critical, especially for cellular-connected devices that incur cost for data usage. The update service must be aware of the device’s current operational manifest, which defines what code/data should be stored in each defined memory area—either within on-die flash or in QSPI flash. Accordingly, when a new package is queued for FOTA, only areas which do not match would be deployed to the device.
A microvisor-based approach is no different, and the microvisor takes care of moving data required to apply an update from the cloud to a staging area in device QSPI storage, where it remains encrypted. Once the device has all the changed parts of the application stored safely in the staging area, it applies the upgrade in a fail-safe and restartable way, to ensure the upgrade appears atomic from the application’s point of view.
The application can be notified during the upgrade staging process, as it may want to indicate progress to an end user. Once the staging process is complete, the application is notified and can pick a convenient time to perform the upgrade. If required, the customer can force the upgrade to be applied at any time after staging; this may be used if the old code is behaving badly, for example.
How can I learn more about microvisors?
If you are interested in getting your hands on an STM32U585-based dev board with Twilio Microvisor pre-loaded, you can join the Twilio Microvisor Beta Program free of charge. Joining the Beta Program will also ensure that you are staying up to date as new capabilities keep being added to Twilio Microvisor.
[ad_2]
