Twilio Microvisor in Public Beta – Unbrickable Firmware OTA and Secure Remote Debugging at Scale, Available Now

When it comes to building IoT products, especially in the industrial sector, there are several key items that need to be taken into consideration:

1. Reliable connectivity
   How do I make sure my devices remain connected and accessible from the cloud?
2. Trustworthy security
   How do I make sure my devices don’t get compromised ever, on hardware or at application level?
3. Predictability of cost
   How do I make sure the cost for keeping things running and secure for 10+ years won’t destroy my business case?

Now, solving these problems is something that we at Twilio know what it takes to do – as we have already been doing so for over 10 years with the Electric Imp Platform as a Service that Twilio acquired in 2019.

All the platform learnings, customer needs, and our experience from being responsible for millions of production devices resulted in a brand new approach to enabling connected device builders / hardware and embedded software developers to build IoT devices – in a way that has never been possible before. But why is a new approach necessary?

What we learned from deploying our first generation IoT platform

Many customers love the convenience of a platform approach – whether it’s managed security, reliable over-the-air (OTA) firmware updates, or device lifecycle management. Many IoT platforms, however, are quite opinionated and non-agnostic; they prescribe the way the developer has to go about their work, from choice of programming language, to operating system, sometimes even the development tools. For some end users, this is acceptable – especially if hardware and firmware engineering is not what they do. For others, who have been designing hardware and writing firmware for years but are now looking to add connectivity, this is more likely than not a showstopper.

Industry analyst Arnal Dayaratna, IDC, calls this requirement of openness out in a recent market note on edge application development, saying:

"Prioritize portability: Developing for the edge requires digital solutions to be fundamentally portable and compatible with a multitude of infrastructures."

~Arnal Dayaratna, IDC, "Developing for the Edge: Notes Toward a Definition of Edge Application Development", Published September 2022, ID US47198921

We agree, and this is exactly why a new approach was needed. One that provides the advantages of a platform, without suffering from the common disadvantages of being locked in to the platform’s particular ecosystem. We are proposing an architecture we call “microvisor”.

What is a microvisor?

A microvisor is a hypervisor for microcontrollers, allowing for failsafe remote firmware updates and similar remote operations on Internet-connected devices. Architecturally, a microvisor makes use of the Arm Trustzone™ component within a microcontroller – such as the STM32U585 from ST – to divide it into two sections at boot time. Peripherals are assigned to either the microvisor zone or the customer application zone at boot time and the two sections run code independently of each other. This allows for complete security on the one hand, and complete agnosticity on the other.

What does this separation mean for your application and your application development?

This separation of application and microvisor space is significant in a number of ways, but the most significant for you as a developer is that the application gets to be anything you want it to be. Because the microvisor operates independently of your application code and you interact with it across the secure interface through a series of simple system calls, your application essentially has full access to the chip and the hardware interfaces on it just as it would if the microvisor wasn’t there.

• For example, If you want to use Azure RTOS (fka ThreadX), and some existing code that you already have, you can. If you want to use Amazon FreeRTOS and the many examples and drivers that are available online, you can. Same for Zephyr, or any other OS you might want to use.
• Alternatively, If you want to roll your own bare-metal code in whatever language / environment you like, you can, be it C, uPython, RUST, or even Assembler.
• Similarly, you have free choice over your cloud backend application, If you want to use Azure IoT, you can. If you want to use AWS IoT, you can, If you want to use any existing or new middleware / custom application, you can.
• This choice also applies to your development tools and toolchain; the IDE and environment you choose to use - pushing an application to a microvisor enabled device can be integrated into your CI/CD process very easily.

This complete freedom of choice as a developer is a major difference between a microvisor approach and pretty much every other IoT platform that is out there today. The risk to you as a developer is pretty low. If you build an application and want to use a microvisor-based platform to push it to your devices, you can. If you later decide that this is not for you, then you haven’t really lost anything because all the code you have written for the target device is still yours and will still work for you and your use case.

"We value the openness that the Twilio Microvisor architecture brings, while giving us concrete reference examples to expedite adoption, e.g. using FreeRTOS"

~AWS

Separating the connectivity stack from the application code guarantees device reachability

This split in responsibility also means that the microvisor takes care of everything needed for your IoT device to remain connected. It is responsible for the IP stack itself, as well as the Wi-Fi and/or cellular modem firmware and drivers. The microvisor architecture enables the reliable connectivity that all IoT devices require.

Even in the worst case scenario of the application having died in some horrible unpredictable way (e.g. a flailing pointer on startup), the device itself remains connected and reachable, as the microvisor component is connected and reachable.

This includes all the pieces in red in the above diagram.

Twilio Microvisor is the first large-scale implementation of the microvisor approach – now available in Public Beta

Twilio Microvisor is a fully managed implementation of the microvisor architecture. In a comprehensive whitepaper that you can find here, we have laid out our design philosophy and details of our implementation.

Twilio Microvisor has now reached Public Beta status. Our documentation is now fully accessible online, and the microvisor software for your firmware development is available through dev boards.

The Public Beta status at Twilio also implies a level of stability and maturity that allows you to start designing production-grade products based on Microvisor.

Twilio Microvisor offers functionality that goes beyond what a barebones microvisor would provide.

Connectivity is a must for our energy-as-a-service technology solutions, but not a key differentiator in itself. Twilio Microvisor will give us managed connectivity with the real-time processing capability that we need for our “virtual power plant” products.

~Kiwi Powered

Twilio Microvisor provides your device with industry-leading security

Twilio also provides you with an industry-leading approach to trustworthy IoT device security for the complete lifecycle of your device, starting with a secure factory provisioning process built with Secure Boot at the heart of it. Guaranteeing only your code runs on your devices, through to regular in-the-field security patches and updates to the connectivity drivers and the IP stack itself for the lifetime of your device, Twilio ensures constant ongoing improvement and protection for your devices without you having to invest any additional engineering effort yourself. Essentially, Twilio offers security as a managed service; this helps you manage the predictability of ongoing cost – something that has often stood in the way of successful deployments of IoT projects.

Note: while the above diagram shows the data path to go directly from your edge device to your cloud, Twilio offers (and recommends to use) a secure path through the Twilio cloud, which would benefit from the same managed security measures as the operational device management connectivity path. Furthermore, it saves you the work of adding and maintaining your own connectivity stack, which is a big part of Twilio Microvisor’s value proposition.

Twilio Microvisor brings you unbrickable over-the-air firmware updates

As a result of a simple API call to the Twilio Microvisor endpoint, you now have a way to reliably update the firmware on your device or fleet of devices. Again, the architectural split of the microvisor approach guarantees that whatever happens to the application itself, the Microvisor will ensure that your device(s) will be able to connect and upgrade the application and file system.

This capability of not being able to lose connectivity (“bricking” the device) also supports a whole new approach to firmware development; it essentially allows the decoupling of the hardware manufacturing process from the firmware development process. If firmware updates become so reliable that you needn’t worry about doing these weekly or even daily, you might as well go ahead and manufacture your hardware before your firmware is tested and complete. Time will tell if device builders will adopt this new level of agility, which was previously only seen in pure Web/cloud development.

Twilio Microvisor now lets you securely debug individual devices

On top of the previously mentioned capabilities, Twilio Microvisor also provides the ability for you to securely remotely debug the application itself on your devices.

IDC's Arnal Dayaratna calls this out as a critical skill for edge developers to develop:

"Acquire proficiency with remote debugging: Remote debugging is an essential skill for edge developers because of the need to debug a digital solution on the hardware and infrastructure on which it is deployed. Defined as the practice of debugging applications that run in an environment that is different from the local environment on which a developer works, remote debugging has achieved increased adoption in recent years because of the proliferation of both cloud-native and edge-native infrastructures. Given that remote debugging requires sifting through voluminous amounts of log files or attempting to replicate the issue in question in another environment (preproduction, staging, etc.), edge developers would do well to leverage data-driven remote debugging tools that simplify and streamline remote debugging by providing developers with live data from an application or digital solution that can be used to debug relevant issues."

~Arnal Dayaratna, IDC, "Developing for the Edge: Notes Toward a Definition of Edge Application Development", Published September 2022, ID US47198921

Secure Remote Debugging takes the super power of separately managed secure connectivity to the next level when it comes to debugging the issue at hand. Everyone loves being able to fix a bug in real time, single-stepping through code, changing variable values on the fly, inspecting the register contents, and having that Eureka moment of figuring out what the bug is that is making your application do something unexpected. But doing all that on cellular-connected devices deployed across the world? That has now become possible. If you want to learn more about how we enable secure remote debugging with Microvisor, take a look at this recent blog post.

"Twilio brings the necessary expertise to implement security for connected MCUs, and the ability to support any software/firmware development approach an embedded engineer might already have selected ensures a speedy Go-To-Market and makes them the perfect partner for us."

~ST Microelectronics

Seeing it all in action

The following (silent) video shows how firmware updates and secure remote debugging looks like in action:

How do I get my hands on a Microvisor Development Board and get started?

The Twilio Microvisor is initially available for use on the STMicroelectronics STM32U585 which comes with 2 MBytes of Flash memory and in a variety of packages (from 48- to 169-pin).

"We have been standardizing on ST Microelectronics chips for our pipeline pig tracking and signaling equipment, so getting managed connectivity from Microvisor on the new STM32U585 MCU fits our needs perfectly."

~CDI Pigging

Twilio offers a “Nucleo form factor” development board which contains the STM32U585 IC, a cellular modem, and a Wi-Fi, Ethernet, Bluetooth comms co-processor enabling multiple connectivity use cases. With this development board in your hands, you can easily get started deploying your code to your new Microvisor enabled edge device.

If you have questions and would like to chat with someone on the Twilio IoT team, or Jonathan directly, please let us know here.

If you would like to understand pricing, please review this page.

We know the brand new Twilio Microvisor approach will enable innovators to get to market faster, lower the total cost of device ownership, and reduce the business risk of deploying IoT devices.

Start exploring what Twilio Microvisor can do for you – now! We can’t wait to see what you build.

Jonathan Williams is a Product Manager for IoT and Wireless at Twilio. Having worked in both the semiconductor industry as well as in cloud video communications, he has a focus on building developer-friendly platforms that solve real world problems.