The Attraction of WebAssembly for Embedded Industrial Software

Keywords: Atym, Bytecode Alliance, Containers, Docker, Embedded, Firmware, Industrial Devices, Linux, Wasm, WebAssembly, W3C

Summary

Originating 10 years ago as a technology for portable executable code in web browsers, WebAssembly has been attracting greater attention not only within the cloud native software community for its portability and speed, but also for its scalability. WebAssembly can serve an extremely wide range of applications from the largest distributed hybrid cloud apps to tiny embedded devices.

Developers of industrial software are interested in WebAssembly for these same reasons, in addition to its immense potential to enable resource-constrained industrial devices to be deployed, managed, and maintained using modern cloud native software methods that have previously been impossible.

What Is WebAssembly?

WebAssembly (abbreviated as Wasm) is a binary instruction format for a virtual machine that was initially designed to operate efficiently within web browsers to augment JavaScript. Wasm enables execution of compiled code from a wide range of programming languages, such as C, C++, and Rust. In 2015, major suppliers of web browsers including Apple, Google, and Microsoft collaborated to standardize WebAssembly as a common executable format that could run within any browser. Today, all major web browsers support WebAssembly.

In the past 4-5 years, Wasm has attracted significant developer attention for applications outside of the browser. Many industries that are adopting cloud-native computing are now considering where and how to leverage WebAssembly. Key features of Wasm such as code portability, high performance, sandboxed security, compatibility with containers and Kubernetes, and resource efficiency make it attractive to software developers.

Wasm vs. Java

The mantra of “write once run anywhere" will ring familiar to readers who are old enough to recall the launch of Java 30 years ago. How is WebAssembly different? There are several important aspects that represent significant improvement over Java and make Wasm more suitable for small footprint applications, especially those served by embedded systems. Some of these are:

Multiple language support – software tooling is available now to compile WebAssembly from the most popular programming languages such as C, C++, Rust, GoLang, and others. Much of the existing code in embedded systems (and many other areas) is written in C or C++. This opens the door to WebAssembly implementations of most existing code bases and applications.

Performance – Wasm runs at near-native performance levels, usually faster than Java applications. Besides that, Wasm executables are more compact and have faster startup times compared to Java. Further, Wasm is more scalable in the downward direction – to microcontroller-based devices with under 1MB of available memory.

Security – Wasm’s smaller size and security-focused design give it a stronger execution sandbox than Java applications.  This sandboxing value extends to microcontroller architectures that don’t include Memory Management Units (MMUs).

Wasm Beyond the Web Browser

There are many ways in which Wasm has potential value beyond the web browser. Today’s hybrid cloud is composed of heterogeneous sets of compute architectures, runtimes, operating systems, and constraints. Key properties of Wasm such as its ability to be portable, fast, sandboxed, and easily distributed give it value as a distributable unit of code for the hybrid cloud. Developers want to build applications for different execution environments, but with minimal complexity and performance impact. Wasm removes some of the complexity of VMs or even containers while enabling portability to any Wasm-compliant software runtime. This includes browsers, systems for web services, Linux servers, edge devices, and RTOS-based runtimes optimized for highly constrained devices powered by microcontrollers with limited memory and compute power.

Governance and Standardization

Because it began as a web browser technology, Wasm has been standardized by the World Wide Web Consortium (W3C) which maintains and updates the standard. Version 2.0 is the current version (2022) but a draft Version 3.0 of the standard was published in November 2024. The work is divided into two main groups; 1) The WebAssembly Community Group (CG) maintains the standard for Core WebAssembly which includes in-browser use, supporting toolchains, and runtimes for browser use, and 2) the WebAssembly System Interface (WASI) sub-group supports non-browser runtimes and develops tools and other technologies for use of WebAssembly outside of the browser.

A third important organization is the Bytecode Alliance (BA). This is a commercial non-profit organization supported primarily by major firms including Amazon, ARM, Intel, Microsoft, Red Hat, and Siemens. The BA also actively supports four open source projects for WebAssembly tooling and runtimes. The recently-formed Embedded/Industrial Special Interest Group (eSIG) includes members from firms such as Atym, Bosch, Emerson, Siemens and Sony Midokura and is focused on developing standards and best practices for Wasm on embedded devices.

Members of the Linux Foundation’s Cloud Native Computing Foundation (CNCF) and LF Edge organizations are working intensively with WebAssembly for non-browser applications.  Wasm has been a very hot topic at recent KubeCon conferences, with most sessions on Wasm drawing standing room only crowds. LF Edge - an arm of the Linux Foundation curating 17 edge software projects - is hosting the Ocre project, which is developing a Wasm-based runtime to enable lightweight application containers on resource-constrained edge devices. A key goal for Ocre is to serve as a open source reference implementation of the standards work done by the eSIG in the Bytecode Alliance.

Industrial R&D for Wasm

There are commercial implementations of Wasm such as Amazon’s Fire TV. There are no Wasm-based industrial products released yet, but WebAssembly is now a very active R&D area within several leading industrial automation suppliers. For example:

Bosch  – Bosch Research has experimented with WebAssembly in two major areas. First in automotive networks, Bosch has evaluated Wasm to decouple hardware and software even for small on-car devices like Engine Control Modules (ECMs).  Second, Bosch has prototyped a means for running and orchestrating Wasm apps for motion control alongside conventional PLC apps in its cntrlX factory automation product line. This work includes successful pilot implementation of hot standby capability for the Wasm apps. Bosch also sponsors the WebAssembly Research Center at Carnegie Mellon University.

Emerson – Through Emerson Ventures, Emerson has invested in the start-up firm Atym, whose mission is to bring Wasm to resource-constrained embedded devices such as industrial systems. Emerson is also on the Governing Board of LF Edge. Ocre was initially contributed to LF Edge by Atym.

Siemens – Siemens sponsors and helped found the WebAssembly Research Center at Carnegie Mellon. According to one researcher, Siemens “has been looking at WebAssembly for about 4-5 years.” Siemens is also active in the Bytecode Alliance’s eSIG and has done research with Stanford University on minimizing the size of an embedded Wasm runtime.

Wasm for Embedded Systems and Devices

The last 20 to 25 years have brought multiple important advances in server side software development and deployment. Server software technology has advanced from monolithic server applications, through virtualization, then to cloud deployments, containerized applications, to orchestrated distributed containerized applications.

Today's challenges with regard to cloud native applications involve the integration of GPUs and specialized accelerators into distributed systems. Wasm introduces both opportunities and challenges by shifting from an OS/container model to a runtime/module approach.

By contrast, over the same 25 year timespan, software for embedded systems and embedded system development has changed very little. While development and debugging software tools have improved, the core development process remains largely the same, and the problems associated with that process persist to this day. Some examples of the challenges are:

• The development process still involves integration only at the source code level, which becomes increasingly complex when code from different internal groups or suppliers must be integrated.  Because source code sharing is necessary, partners are unable to protect their intellectual property with assurance.
• Hardware independence is limited, and there are few skilled developers with the requisite knowledge of both the hardware and software environments. Tight coupling of firmware to hardware can require months to change silicon on the BOM.
• It remains difficult to develop a single product if multiple programming languages or tool chains are required.
• Lower level device drivers and services are typically provided by different board and module suppliers, often with little or no software provenance or software bill of materials (SBOM).
• The monolithic nature of the embedded system software deliverable makes it difficult or impossible to manage deployments and field upgrades. Related tools are proprietary, unreliable, and challenging to scale.
• If upgrades are possible, they are not incremental but rather involve wholesale recompilation, retesting and replacement of installed software, which requires a reboot that impacts uptime and creates risk.

In short, technology for embedded devices and systems – especially resource-constrained ones - has been “stuck in time” for decades. While devices have become more capable, they are not truly smart until they can securely and simultaneously run portable code programmed in any language and can be managed over their full lifecycle with fractional updates.

The “Linux Barrier” for Devices

Embedded system developers have tried to address some of these issues by deploying Linux operating systems, and in some cases containerized applications. These provide a solution for some cases, but they do not address most of the embedded system space. Most embedded systems are deployed at what the Linux Foundation calls the “Constrained Device Edge” (see figure next page). Devices based on microcontrollers are not able to support Linux at all, and Linux with traditional container support software such as Docker consumes a considerable share of valuable resources on CPU-based devices that have less than 1GB of memory.

As such, Linux and traditional container technologies cannot address the devices in the embedded system space that have limited memory resources but very high unit volumes. Therefore, much of the embedded system community continues to employ technologies and processes that are archaic, and they are suffering the consequences.

What Wasm Brings to Embedded

The Wasm community and academic researchers have learned how to shrink a Wasm runtime to a footprint of less than 256KB of memory – over 1000X smaller than the typical footprint of Linux with Docker.  This enables support for extremely small and constrained devices while retaining the advantages of containers for management, deployment, and scalability. Commercial startup firms like Atym have taken this a step further by integrating the open-source embedded Wasm runtime from the LF Edge’s Ocre project into a full container management solution.

The era of Wasm is set to enable traditional embedded devices and systems to take advantage of an array of features that we now take for granted in larger systems:

• Containerized applications are portable from CPU to MPU and MCU-based devices with as little as 1MB of memory, spanning any silicon and instruction-set architecture.
• Multiple applications (e.g. connectivity, data normalization, AI/ML, security) can be developed in different languages (e.g. C, Rust, Golang) and execute on devices in isolated containers with policy-based intercommunication, providing greater security as well as protection for intellectual property. Previously this required hardware support such as an MMU.
• Individual containers can be fractionally updated on devices without requiring a reboot and without impacting the overall code base.
• CI/CD functionality can be automated for application development, deployment and management.
• Reduced memory requirements on Linux-capable devices when used as an alternative to traditional container technologies such as Docker, enabling additional functionality, lower BOM cost, and/or extended life for existing hardware.

The application containerization enabled by Wasm provides extended security benefits such as sandboxing, secure communication between applications and protection from malware attacks such as buffer overruns. These types of protections are increasingly required of embedded devices as regulators seek to prevent the hijacking of large numbers of insecure Internet-connected devices. Also, device suppliers are now facing a December 11, 2027 deadline for the European Union Cyber Resilience Act (CRA), which imposes mandatory cybersecurity requirements for digital hardware and software products. For manufacturers these include mandatory cybersecurity rules and the obligation to provide software updates and ongoing security support.

In summary, Wasm has the potential to bring the manageability, deployability, upgradeability, and observability of cloud native software to the smallest intelligent devices for both OEMs and end users.

One researcher from Siemens stated this quite well:

“WebAssembly has the potential to be the defacto standard for small form factor portable, distributable, software components running on everything from embedded systems like the ESP32 through to Intel x64-based servers in the cloud.”

Recommendations

Based on ARC research and analysis, we recommend the following actions for technology users:

• Developers of distributed software systems should evaluate how Wasm might simplify the development and deployment challenges they face from hybrid or heterogeneous environments.
• Industrial device manufacturers should evaluate the potential of Wasm to both extend the useful life of existing products and/or enable new functionality and services.
• End users of industrial devices should understand how their suppliers plan to achieve CRA regulatory compliance in the longer term, and what improvements in manageability and observability they plan.
   

ARC Advisory Group clients can view the complete report at the ARC Client Portal.

Contact Us if you would like to speak with the author.

Obtain more ARC In-depth Research Market Analysis.