Revolutionizing Embedded with WebAssembly-based Containerization
Born in the browser, WebAssembly (Wasm) has immense potential to revolutionize software development and deployment for embedded devices and systems.
Unlike traditional containerization technologies like Docker, Wasm-based application containers do not require Linux as a foundation and are portable across any silicon architecture – spanning CPUs to MPUs and MCUs. Applications can be developed in different languages (e.g. C, Rust, Golang) and executed on devices in isolated containers, providing greater security and IP protection. Individual containers can be fractionally updated on devices without requiring a reboot or impacting the overall code base.
These attributes enable software for resource-constrained devices to be developed, deployed, managed, and maintained using modern cloud-native methods. Benefits include greatly reduced development complexity and cost, improved security and uptime, fractional updates without requiring reboots, and simplified ecosystem collaboration – especially when implementing new technologies such as on-device AI/ML.
Join this session with Atym co-founder and CTO Stephen Berard to learn more about WebAssembly and key benefits and use cases in the embedded space. He will also walk through industry collaboration to facilitate standardization, including the WebAssembly Embedded Special Interest Group (eSIG) in the Bytecode Alliance (a collaboration between Amazon, Atym, Bosch, Emerson, Microsoft, Siemens, Sony Midokura, and more), and the Linux Foundation’s Ocre project.
The intent of the Ocre community is to codify output from the eSIG, and with a footprint of just 128KB, the Ocre runtime supports containers on MCUs with as little as 256KB of memory. Atym leverages Ocre as part of its commercial device edge orchestration solution.
What is the main reason WebAssembly (Wasm) enables container-like applications to run on microcontrollers and other non-Linux embedded platforms, according to the talk?
Thanks for attending the talk. As mentioned, our reference RTOS today is Zephyr which we can support on several hardware platforms and instruction sets. That said, our runtime is designed to be portable to other platforms as well. We already have a Linux port in progress and have received a few asks for other OSes as well. If there is a specific project and/or platform you'd like to see supported, please reach out to us. We'd love to learn more.
9:21 subtitles say "In this way, Oka extends to container model" but Oka→Ocre. Are the subtitles AI generated? (maybe by OpenAI whisper? or maybe something else... could try Tesseract OVR perhaps. Not sure what the WASM subtitles are generated by, probably JavaScript in this generation?)
Hey Peter! Yes, the subtitles were generated using an AI tool as part of an experiment we ran on a few talks. As you noticed, the transcripts aren’t perfect, and we appreciate your patience with the occasional error.
For now, please assume that “Oka” or “Okr” means “Ocre,” and “atom” refers to “atym.”
OCR?
To start with I skipped this presentation, thinking webAs... no that sounds like something for BIG embedded devices. But had some idle time and decided to give it a look, and am I glad I did that :-)
Even though it targets devices way smaller than I imagined, It's probably too big for my current project. But definitely within range for future ones.
I did take a look at atym.io, because I wanted to know more about the HW requirements, sorry to say that website is too much value selling marketing, for me to navigate. But maybe you can answer some of the questions. You mentioned memory requirements, but are there other requirements like memory manager or the like?
How is it delivered, do I get a binary that i have to flash, and only works on the CPU's you support or is it source or?
You also mention hardware abstraction. Will I depend on you to deliver drivers, or can i add/modify them myself. And where are they placed in the orcre architecture?
And last what is the licensing model?
Thank you for the interest in the solution. Here are the answers to your questions:
- A memory manager is not required. Since isolated containers can only address their assigned memory, a MMU is not needed to protect the entire memory space. In effect, our runtime provides a "soft MMU" and is one of the benefits of Ocre and its ability to extend to devices without MMU like MCUs. On platforms that have an MMU or other memory protection hardware we can take advantage of these.
- We offer ready to deploy binary runtimes for supported devices. We are working to expand our supported device list to include common platforms that are readily available. For other platforms and custom hardware, we can work with you to implement a runtime for a specific requirement, or you can license the source and implement yourself.
- The starting point for drivers is what comes with the OS in the runtime - for Ocre that would be what comes with Zephyr. Custom drivers can be added in the OS layer of the runtime.
- The licensing model for the Atym solution is based on a subscription to the Atym Hub (platform).
Would be happy to discuss any of this in more detail if you would like to reach our directly.
Excellent presentation!
Intriguing!
Really interesting. I have used webassembly to port tricky C code into browsers, but have never considered it for runtime. Supported platforms might be challenging (x86 on vxworks), but definitely intertesting