Achieving Future-Proof, No Vendor-Lock-In IoT Connectivity with a Microvisor Architecture

April 17, 2023

Blog

IoT projects need reliable infrastructure that keeps your devices connected, secure, and ideally also perpetually accessible for over-the-air firmware updates to support ongoing maintenance and feature development – all as you scale from a few prototypes to possibly hundreds of thousands of units.

Yet building and maintaining this infrastructure is hard! Especially if your area of expertise isn’t connectivity and communications, but embedded systems. As companies turn to IoT platforms for help, they are faced with a conundrum: outsourcing the operation of the required IoT infrastructure promises a faster time to market, but at the high cost of locking oneself either into a whole vendor and tooling ecosystem, or, as a minimum, into their mandate of operating system(s) and programming language(s).   

Your Embedded Software Engineering team would probably tell you that the most important decision you have when it comes to your IoT software architecture is the choice you make around the OS and programming language to write your device side application in. This choice potentially influences the size and experience of the team that you need, the amount of new code that you have to write, the ease of hiring new engineers, and most importantly, the amount of time it takes to deliver your project or product. Historically, this decision has been a big one, as once you make it, you are essentially stuck with it forever more – or at least it can be very difficult to change the decision further down the road.

On top of OS and language, you may also want to consider third party code for integration, or perhaps you have pre-existing code and drivers for things like sensors that you want to reuse. You really want to be able to choose your development environment and not have it forced upon you.

In this article, we will explore the benefits of a new, open approach to IoT software architecture, called the microvisor-based approach. We will address why having the freedom to write code your way is so valuable, and why the flexibility of being able to change your approach further down the road leads to significant benefits to future-proofing your product and ultimately your team’s success.

This is the third in a series of articles covering the new microvisor-based approach to IoT connectivity. Read up on our prior articles:

• Achieving Unbrickable Remote Firmware Updates on MCUs with a Microvisor Architecture 
• Achieving Secure Live Remote Debugging of Connected Microcontrollers with a Microvisor Architecture

The Significance of Future-Proofing Your IoT Architecture 

It is probably fair to say that nobody wants to end up being the team left maintaining the old product, constantly running out of resources (e.g Flash and RAM), forever optimizing code to make it fit, repeatedly having to port patches back to a legacy product, all while the new product is on the more modern OS and gets all the new features. 

Sometimes you might even end up forced into making a bad choice to compromise a new product - “let’s use the same OS and code as the old product” to make it consistent even if you know it is not the right choice to make.  

As part of the decision around the architecture, OS, and programming language to use, you really want to make sure that you provide the “future you” with the best chance of success. This typically means making design decisions that don’t paint you into a corner and leave you with a lot of technical debt further down the line. You might feel that you need a crystal ball in order to work out the unknown unknowns and that you have to do this without knowing completely what the future holds:

• Will you discover an unforeseen problem that forces you to change your plans? 
• Will there be a next version of the product with significantly more requirements?
• Will you need to support a different hardware architecture when a V2 product gets defined?  

So given that the choice of OS and Programming language is a big one, what can you do to give the future you the widest set of options and to best future-proof your devices and protect your software team?

Wouldn’t it be great if you could make this choice more easily; If you could choose a device-side approach today that gives you the freedom to innovate quickly and immediately, based on the information that you currently have. Perhaps enabling you to get your Minimum Viable Product (MVP) or V1 product out of the door as quickly as possible, developing in the most efficient and agile manner along the way.

Wouldn’t it be even better if you could build the ability to change direction further down the line into your V1 product, ensuring that you never end up facing that situation of the legacy product running a different environment to the new one. 

This complete flexibility and control is what I mean by having an “open approach” to future-proofing your IoT software architecture running at the edge. 

Take the example of the advent of RUST as the embedded programming language of choice. You might not quite be ready to adopt a RUST environment on your edge devices today, but you are pretty sure that soon, it is something that you will probably want to do. With an open architecture on the edge device, you could choose to build an application written in C on something like FreeRTOS today, safe in the knowledge that you could easily switch it out for a RUST-based application in the future. You can now build in the ability for your devices to “move with the times”.

Ultimately, being able to change your approach when the time comes will lead to better overall team and device performance as well as a more agile and efficient development process. This in turn will help significantly reduce legacy product maintenance costs and decrease your time to market. It also means that you can optimize for now without agonizing too much about the future – whether it is optimizing your code for features, performance, reliability, or security as you develop your application. What is good today isn’t going to be good forever. 

How a Microvisor Architecture Enables Freedom of Choice

If you have read the prior articles in this series, you will know that a microvisor is an IoT approach that makes use of a hypervisor for microcontrollers, which enables reliable and secure remote operations, such as failsafe over-the-air firmware updates and secure live remote debugging, on Internet-connected devices. It does this by making use of hardware separation within a microcontroller – such as the STM32U585 from ST – to divide it into two sections at boot time, e.g. by leveraging Arm® Trustzone®. 

 

This microvisor separates not just the security components of your device (typically what the TrustZone might traditionally be used for) but also the connectivity components, meaning that everything your device needs to get online and stay online is a property of the microvisor itself. 

This split within a microvisor architecture means that the challenge of future-proofing your software team’s requirements and your product’s software architecture can now be met simply by using a microvisor-based approach on your device, as this approach essentially separates the permanence of the device side code architecture decision in order to prevent vendor or architecture lock-in. 

In a microvisor-based architecture, there are no limitations imposed on the operating system or programming language used in embedded development. As long as the OS or environment you want to use can run on your MCU (which initially, in the case of Twilio Microvisor, is the STM32U585), then you can deploy it in a microvisor world. This adapts to any approach in embedded development, whether it is a custom bare-metal approach, or built on top of an “off the shelf” operating system, e.g FreeRTOS or Azure RTOS.

Compared to the approach of traditional IoT platforms, this freedom and flexibility is new. It is very rare to have a completely free choice in what operating system and programming language to use. And with a microvisor approach, application developers and firmware engineers are not locked into any specific software platform. Developers can choose the tools that work best for them, rather than being forced to use a particular platform approach because it's the only one that's supported. 

This lack of platform “lock in” is probably the biggest help when it comes to creating a future-proof IoT solution. Even in the worst-case scenario, where one of your providers perhaps goes out of business, the fact that the code has been written using a microvisor-based approach means that developers won't have wasted any time in platform-specific work. You could easily port your code to another OS or environment without too much trouble, use the microvisor FOTA capability to push this “completely new image” to your existing devices in the field, and the end users need not even know that a potential disaster has been averted.

But arguably the biggest benefit is that this really does help to ensure that your IoT solutions remain adaptable and future-proof over time, even as technologies and market conditions change.

How Can I Learn More About Twilio Microvisor?

Microvisors provide a powerful and flexible approach to IoT that enables developers to build secure, reliable, and efficient IoT applications. By leveraging hardware separation, microvisors can provide an added layer of security to IoT devices, while enabling remote debugging, OTA firmware updates, and crucially support for multiple operating systems and multiple programming languages with native code execution. With their many advantages and benefits, microvisors are poised to play an increasingly important role in the development and deployment of IoT applications.

If you’re interested in diving deeper into the microvisor architecture, consider reading the Twilio whitepaper “Architecture and Design Considerations for Modern IoT Infrastructure”, which is organized into two parts: 

• Part I addresses a broader audience, such as IoT product managers, project managers, and engineering managers. It lays out a typical device-side IoT architecture and describes the traditional approach of implementation. It details the associated challenges and develops an argument for a different approach, now made possible through the hardware advancements described above.  
• Part II addresses the experienced embedded engineer and explains Twilio’s thinking with regard to how the above-mentioned challenges can be effectively addressed with a new architecture.

If you would like to explore Twilio Microvisor hands-on and potentially receive a free dev board with an STM32U585, you can join the Twilio Microvisor Beta Program.

Read up on our prior articles:

• Achieving Unbrickable Remote Firmware Updates on MCUs with a Microvisor Architecture 
• Achieving Secure Live Remote Debugging of Connected Microcontrollers with a Microvisor Architecture