{"id":94855,"date":"2023-06-15T12:00:00","date_gmt":"2023-06-15T12:00:00","guid":{"rendered":"https:\/\/industry-science.com\/?post_type=article&p=94855"},"modified":"2024-04-23T07:50:56","modified_gmt":"2024-04-23T05:50:56","slug":"webassembly-for-the-industrial-internet-of-things","status":"publish","type":"article","link":"https:\/\/industry-science.com\/en\/articles\/webassembly-for-the-industrial-internet-of-things\/","title":{"rendered":"WebAssembly for the Industrial Internet-of-Things"},"content":{"rendered":"\n

Die sichere Separierung von verschiedenen Software-Modulen auf Rechnersystemen ist inzwischen auch in eingebetteten Ger\u00e4ten ein wichtiges Thema. Nicht nur aus Gr\u00fcnden der funktionalen Sicherheit, sondern auch der Cybersicherheit sollen verschiedene Software-Module separiert werden, da sie zum Beispiel aus verschiedenen Quellen kommen oder die Resilienz erh\u00f6ht werden soll.<\/p>\n\n

Um eine strenge Isolation zu erreichen und gleichzeitig ein hohes Ma\u00df an Portabilit\u00e4t zu erm\u00f6glichen, hat sich das Prinzip der Virtualisierung durchgesetzt. System-Virtualisierung mit Hypervisoren teilt eine Rechnerplattform zwischen mehreren Instanzen von Betriebssystemen. Container-Virtualisierung innerhalb eines Betriebssystems hat sich im Umfeld der Cloud in Form von Docker und \u00e4hnlichen L\u00f6sungen durchgesetzt.<\/p>\n\n

Bei der Applikations-Virtualisierung wird nicht ein Rechner selbst, sondern ausschlie\u00dflich die Laufzeitumgebung virtualisiert. Die Verwendung von Bytecode erlaubt dabei eine gute Portierbarkeit und hohe Effizienz. Hier wird ein Maschinenmodell definiert und Bytecode f\u00fcr diese Virtuelle Maschine \u00fcbersetzt. Der Bytecode kann interpretiert, bin\u00e4r in die Zielarchitektur \u00fcbersetzt oder Just-in-Time \u00fcbersetzt werden. Die Java Virtual Machine ist dabei die am weitesten verbreitete Bytecode-basierte Virtualisierung.<\/p>\n\n

Im Bereich der Embedded Systems, insbesondere Industrial IoT und Automotive, spielen Virtualisierungsl\u00f6sungen zunehmend eine Rolle. Hypervisoren adressieren dabei die Bed\u00fcrfnisse dieser spezialisierten, ressourcenbeschr\u00e4nkten Systeme. Diese haben jedoch Nachteile in der Portierbarkeit, da sie sehr spezifisch zugeschnitten sind und zwischen Ger\u00e4ten nicht immer direkt \u00fcbertragbar sind.<\/p>\n\n

Bytecode-basierte Virtuelle Maschinen, bei denen Anwendungen in Modulen gekapselt auf beliebigen Plattformen ausgef\u00fchrt werden k\u00f6nnen, haben hier den Vorteil einer Separierung zwischen der Portierung einer Laufzeitumgebung und der Anwendung. So lassen sich Applikationen ohne weitere Anpassung unmittelbar auf unterst\u00fctzten Ger\u00e4ten ausf\u00fchren.<\/p>\n\n

In den letzten Jahren ist dabei WebAssembly, das urspr\u00fcnglich f\u00fcr die schnellere Ausf\u00fchrung von Applikationen in Browsern entwickelt wurde, immer st\u00e4rker in den Fokus von Anwendungen jenseits des Browsers ger\u00fcckt. Im Gegensatz zur Java Virtual Machine ist die virtuelle Maschine von WebAssembly maschinenn\u00e4her und unterst\u00fctzt sehr viele verschiedene Programmiersprachen als Ausgangspunkt. Mit diesen Eigenschaften ist es auch interessant f\u00fcr Embedded Systems.<\/p>\n\n

Im Folgenden werden die technischen Grundlagen von WebAssembly kurz pr\u00e4sentiert und der Einsatz von WebAssembly in industriellen IoT-Anwendungen diskutiert.<\/p>\n\n

Grundlagen von WebAssembly<\/h2>\n\n

WebAssembly wurde im Jahr 2014 als ein gemeinsamer Standard der gro\u00dfen Browser-Hersteller vorgestellt [1]. Die Motivation daf\u00fcr bestand unter anderem in der zunehmenden Komplexit\u00e4t von Web-Anwendungen, die durch JavaScript nicht effizient adressiert werden, konnte. Insbesondere ist das bei rechenaufwendigen Aufgaben, wie zum Beispiel im Bereich Computer Vision oder der Echtzeitvisualisierung von Daten der Fall. <\/p>\n\n

W\u00e4hrend es zu diesem Zeitpunkt bereits Ans\u00e4tze wie asm.js gab [2], war hier das Ziel von vornherein ein portables, standardisiertes Format zu unterst\u00fctzen, mit dem sich Applikationen im Client-Browser ausf\u00fchren lassen.Dabei sollte weiterhin eine Interaktion mit dem Document Object Model (DOM) sowie JavaScript m\u00f6glich sein. Gegen\u00fcber dem Ansatz, JavaScript zur Beschleunigung Just-in-Time zu \u00fcbersetzen, hat WebAssembly den Vorteil, dass beliebige Programmiersprachen nach WebAssembly \u00fcbersetzt werden k\u00f6nnen. Als Beispiel sei der Game-Boy-Emulator WasmBoy [3] genannt, der es erlaubt, im Browser Game-Boy-Spiele zu spielen.<\/p>\n\n

WebAssembly wird als Standard des W3C-Konsortiums gepflegt und weiterentwickelt [4]. Basierend darauf ist die Bytecode Alliance als Non-Profit-Organisation entstanden, die Software f\u00fcr die Ausf\u00fchrung au\u00dferhalb des Browsers pflegt und Standards jenseits des Webs definiert [5]. Daneben ist ein extrem reichhaltiges Open-Source-\u00d6kosystem entstanden.<\/p>\n\n

Technisch handelt es sich bei WebAssembly um eine Stack-basierte virtuelle Maschine. Bytecode operiert auf diesem Stack, Operanden zu Operationen sind wie in Java immer oben auf dem Stack. Im Gegensatz zu Java gibt es (aktuell) keine Objekte und Garbage Collection, sondern ein flaches Speichermodell wie in C oder Rust.<\/p>\n\n

\"WebAssembly
Bild 1: WebAssembly \u00dcbersetzung und Ausf\u00fchrung.<\/em><\/figcaption><\/figure>\n\n

Die \u00dcbersetzung und Ausf\u00fchrung von WebAssembly sind exemplarisch in Bild 1 dargestellt. Ausgangspunkt ist in diesem Beispiel ein einfaches Embedded Programm in C. Ebenso kann eine gro\u00dfe Reihe weiterer Programmiersprachen genutzt werden. Dies ist besonders interessant, weil es Firmen mit gro\u00dfen Embedded-System-Projekten erlaubt, neue Programmiersprachen wie Rust einzuf\u00fchren, auch wenn die Plattform selbst von keinem Rust-Compiler unterst\u00fctzt wird.<\/p>\n\n

Aus der Quell-Programmiersprache wird ein Bytecode in bin\u00e4rer Form (wasm) erstellt. Neben der bin\u00e4ren Form existiert auch eine Textdarstellung (wat), die in Bild 1 dem bin\u00e4ren Format gegen\u00fcbergestellt ist. Ohne auf die genauen Kommandos einzugehen, ist das Format einer Stack-basierten virtuellen Maschine hier klar erkennbar.<\/p>\n\n

Ein WebAssembly-Modul in bin\u00e4rem Format kann in einer beliebigen WebAssembly Lauf\u00adzeitumgebung ausgef\u00fchrt werden. Verbreitet sind dabei i) Interpreter, ii) Interpreter mit Just-in-Time Compilern, und iii) Ahead-of-Time Laufzeitumgebungen. Aufgrund der Ressourcenbeschr\u00e4nkungen von Embedded Systems fallen Just-in-Time-Ans\u00e4tze weg, sodass Embedded-fokussierte Laufzeitumgebungen meist Interpreter sind, die gelegentlich auch \u00fcbersetzte Module erlauben.<\/p>\n\n

Ein Interpreter durchl\u00e4uft den Bytecode dabei als Daten und f\u00fchrt f\u00fcr jeden Befehl eine Funktion aus. Wenn der Bytecode vorab (Ahead-of-Time) \u00fcbersetzt wird, werden hingegen direkt Maschinenprogramme ausgef\u00fchrt. Die g\u00e4ngigsten Interpreter f\u00fcr Embedded Systems sind aktuell die WebAssembly Micro Runtime der Bytecode Alliance [6] und WASM3 [7]. Diese Laufzeitumgebungen k\u00f6nnen entweder direkt auf der Hardware instanziiert oder in Betriebssysteme integriert werden.<\/p>\n\n

Sichere Vernetzung von WebAssembly-Modulen<\/h2>\n\n

Ausgehend von den einzelnen Modulen ist interessant, wie man gr\u00f6\u00dfere IoT-Systeme aufbauen kann. Ausgangspunkt ist dabei eine einzelne Laufzeitumgebung. Module k\u00f6nnen \u00fcber ein generisches Interface-Format namens Wasm Interface Type (WIT) [8] untereinander oder mit der Au\u00dfenwelt kommunizieren. \u00c4hnlich wie POSIX definiert das WebAssembly-System Interface (WASI) [9] grundlegende Systemfunktionen. Weitere Interfaces werden \u00fcber die Zeit spezifiziert.<\/p>\n\n

\n
\n
\"Schnittstellen
Bild 2: Schnittstellen zur Vernetzung von WebAssembly-Modulen.<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n

WebAssembly-Schnittstellen verfolgen das Konzept der berechtigungsbasierten Sicherheit (capability-based security). Neben statischen Berechtigungen, die zum Start eines Moduls importiert werden k\u00f6nnen, spielen insbesondere dynamische Berechtigungen eine zunehmend wichtige Rolle. Diese Berechtigungen werden dann zur Laufzeit von einem Modul ben\u00f6tigt, um bestimmte Operationen durchzuf\u00fchren. Nicht-ver\u00e4nderbare Referenzen erh\u00f6hen dabei die Sicherheit.<\/p>\n<\/div>\n<\/div>\n\n

Beispielhaft f\u00fcr Anwendungen im Umfeld von Industrial IoT ist dabei in Bild 2 dargestellt, wie ein WebAssembly-Modul mit nativen Funktionen interagiert. Wir erwarten in den n\u00e4chsten Jahren standardisierte Schnittstellen f\u00fcr die Interaktion von WebAssembly-Modulen, die auf Berechtigungen basieren. Im Bild sind Schnittstellen f\u00fcr die Sensor-Konfiguration (hier: Kamera) und die Kommunikation dargestellt. Solche Kommunikationsschnittstellen werden aufgrund der angestrebten Portabilit\u00e4t sicher abstrahiert und transparent \u00fcber darunterliegende physikalische Kommunikation \u00fcber Wifi, MQTT etc. durchgef\u00fchrt.<\/p>\n\n

Die Sicherheit der Kommunikation von WebAssembly-Modulen untereinander und mit der Au\u00dfenwelt ist besonders wichtig. Hier arbeiten wir aktuell an sicheren Schnittstellen auf Basis von authentifizierten Kommunikationskan\u00e4len mit SPIFFE [10]. SPIFFE ist ein Protokoll, dass es Containern, also in unserem Fall Webassembly-Modulen, erlaubt, miteinander sicher zu kommunizieren. Das umfasst sowohl Authentifizierung als auch Transportsicherheit. Das Protokoll wird aktuell im Docker-Umfeld eingesetzt, wir arbeiten jedoch an einer Portierung f\u00fcr WebAssembly, die sich dann mit den Docker-Containern integriert. Gegen\u00fcber anderen Standards, bietet SPIFFE eine Integration \u00fcber verschiedene Container-Formate hinweg.<\/p>\n\n

Programmierung von Skalierbaren WebAssembly-Anwendungen<\/h2>\n\n

Wie einleitend motiviert, ist eines der Ziele f\u00fcr moderne IoT-Systeme, komplexe Applikationen auf eine heterogene Ger\u00e4telandschaft abzubilden, und dabei dynamisch in Bezug auf die Performance-Anspr\u00fcche zu reagieren. Dar\u00fcber hinaus ist eine Resilienz gegen Ausf\u00e4lle dringend notwendig. Mit den bisher beschriebenen Elementen ergibt sich eine solide technische Grundlage, auf der Frameworks f\u00fcr die Entwicklung, Verteilung und \u00dcberwachung von IoT-System aufbauen k\u00f6nnen. Ausgangspunkt ist heutzutage h\u00e4ufig die modellbasierte Software-Entwicklung, die es erlaubt, aus Modellierungssprachen Quellcode zu generieren.<\/p>\n\n

F\u00fcr den Einsatz im industriellen Umfeld k\u00f6nnte zum Beispiel ein Framework wie Simulink f\u00fcr Kontrollaufgaben oder eine Stream Processing Software wie KNIME [11] f\u00fcr Data-Science-Anwendungen genutzt werden. Durch die Generierung von WebAssembly-Modulen aus diesen Frameworks lassen sich damit portierbare und interoperable Applikationen erstellen, die sich leicht auf gro\u00dfe IoT-Systeme abbilden lassen.<\/p>\n\n

In Bild 3 ist beispielhaft ein Datenflussmodell dargestellt, welches in einer nicht n\u00e4her spezifizierten Modellierungssprache entworfen wurde. Jeder der Knoten kann in ein WebAssembly-Modul \u00fcbersetzt werden und auf IoT-Ger\u00e4te, Edge-Ger\u00e4te und Cloud-Server verteilt werden. Die Kommunikationskan\u00e4le m\u00fcssen auf die darunterliegenden Systeme und Standards abgebildet werden, sodass eine transparente Umsetzung erm\u00f6glicht werden kann.<\/p>\n\n

Die Verf\u00fcgbarkeit sicherer Kommunikationsinfrastruktur, zum Beispiel basierend auf SPIFFE, ist dabei essenziell. F\u00fcr das einfache Debugging k\u00f6nnten einzelne WebAssembly-Module auch vor\u00fcbergehend im Browser instanziiert werden. Performance-Tuning kann aufgrund der Auslastung der Ger\u00e4te erfolgen. Auf etwaige Flaschenh\u00e4lse oder Ausf\u00e4lle kann durch Migration der WebAssembly-Module reagiert werden. Durch die bestehende Hardwareabstraktion ist es so m\u00f6glich, flexibel auch gro\u00dfe Systeme zu entwickeln.<\/p>\n\n

\"Vision
Bild 3: Vision des Mappings von WebAssembly Stream Processing auf eine IoT-Flotte.<\/em><\/figcaption><\/figure>\n\n

Eine Herausforderung der n\u00e4chsten Jahre wird sein, dass die Performance von interpretiertem WebAssembly Bytecode leicht um den Faktor 10 schlechter sein kann als nativer, optimierter Code. Dieses Problem ist im Umfeld leistungsf\u00e4higer Plattformen mit verh\u00e4ltnism\u00e4\u00dfig viel Speicher (z. B. Browser oder Server) weniger signifikant, da Methoden wie Just-in-Time-\u00dcbersetzung in Maschinencode dies weitestgehend abmildern k\u00f6nnen.<\/p>\n\n

Die alternative Ahead-of-Time-\u00dcbersetzung scheint da besser geeignet f\u00fcr den Einsatz in Embedded-Ger\u00e4ten, erfordert aber tiefergehende Schutzmechanismen bei der Ausf\u00fchrung von Benutzercode, wie zum Beispiel \u00fcber Code-Signierung. Gerade in \u00fcberschaubaren Umgebungen kommt man damit auf bedeutend weniger Einfluss auf die Performance in der Gr\u00f6\u00dfenordnung von ca. 30 % [12].<\/p>\n\n

Fazit und Ausblick<\/h2>\n\n

WebAssembly ist eine \u00e4u\u00dferst interessante Virtualisierungsl\u00f6sung. Im Vergleich zu anderen Formen der Virtualisierung, die aktuell in Embedded Systems Verbreitung finden, ist es bedeutend portierbarer und im Vergleich zu anderen Bytecode Virtuellen Maschinen wie Java n\u00e4her an den Speichermodellen von C und der darunterliegenden Hardware. Durch das reichhaltige Open-Source-\u00d6kosystem sehen wir viele Potenziale \u2212 insbesondere auch als Ausf\u00fchrungsformat f\u00fcr die modellbasierte Software-Entwicklung. Die Entwicklung von WebAssembly ist aktuell noch im Fluss, wie die Verwendung von wiederverwendbaren Komponenten und Objekte im Bytecode. Einige konzeptuelle Ver\u00e4nderungen scheinen dabei \u00e4u\u00dferst hilfreich f\u00fcr die Adaption in Embedded Systems.<\/p>\n\n

Auch sind standardisierte Schnittstellen noch nicht in der Breite vorhanden \u2212 ein gro\u00dfes Potenzial, sich zu engagieren. Interessant wird dabei insbesondere sein, wie standardisierte Schnittstellen f\u00fcr den Zugriff auf native Funktionen von Spezialhardware (z. B. GPUs) geschaffen werden k\u00f6nnen. Diese w\u00e4ren sicher Schl\u00fcsselkomponenten f\u00fcr die effiziente Ausf\u00fchrung von rechenintensiven Algorithmen (z. B. aus der Computer Vision) in WebAssembly-basierten Implementierungen. Vorbilder gibt es hier bereits mit WebGPU [13] und WebNN [14].<\/p>\n

Bibliography <\/h2>[1] Haas, A. u. a.: Bringing the web up to speed with WebAssembly. In: Proceedings of the 38th ACM SIGPLAN Conference on Program- ming Language Design and Implementation (2017), S. 185-200.\r
[2] Herman, D. u. a.: asm.js. URL: https:\/\/asmjs.org, Abrufdatum 10.3.2023.\r
[3] Turner, A.: WasmBoy. URL: https:\/\/wasmboy.app\/, Abrufdatum\r
10.3.2023.\r
[4] Schuff, D. u. a.: WebAssembly Working Group. URL: www.w3.org\/wasm\/, Abrufdatum 10.3.2023.\r
[5] Bytecode Alliance: About the Bytecode Alliance. URL: https:\/\/bytecodealliance.org\/, Abrufdatum\r
10.3.2023.\r
[6] Bytecode Alliance: WebAssembly Micro Runtime. URL: https:\/\/github.com\/bytecodealliance\/wasm-micro-runtime, Abrufdatum 10.3.2023.\r
[7] Volodymyr Shymanskyy: WASM3. URL: https:\/\/github.com\/wasm3\/wasm3, Abrufdatum 10.3.2023.\r
[8] Wagner, L. u. a.: The wit format. URL: https:\/\/github.com\/WebAssembly\/component-model\/blob\/main\/ design\/mvp\/WIT.md, Abrufdatum 10.3.2023.\r
[9] Hickey, P. u. a.: WebAssembly System Interface. URL: https:\/\/github.com\/WebAssembly\/WASI, Abrufdatum 10.3.2023.\r
[10] Cloud Native Computing Foundation. URL: https:\/\/spiffe.io\/, Abrufdatum 10.3.2023.\r
[11] KNIME AG. URL: www.knime.com\/, Abrufdatum 10.3.2023.\r
[12] Wallentowitz, S. u. a.: Potential of WebAssembly for Embedded Systems. 11th Mediterranean Conference on Embedded Computing (2022), S. 1-4.\r
[13] Ninomiya, K. u. a.: WebGPU. URL: www.w3.org\/TR\/webgpu\/, Abrufdatum 10.3.2023.\r
[14] Hu, N. u. a.: WebNN. URL: www.w3.org\/TR\/webnn\/, Abrufdatum 10.3.2023.<\/div>

Your downloads<\/h2>