 So folks, they say that hindsight is always 20-20, but foresight never is. But there's probably another phrase that you guys know, too. And that's one of all historians and history teachers will tell you. History has a habit of repeating itself. So I'm an industrial researcher, and my day job involves peering through the crystal ball. What's coming next? What technologies are about to arrive that will impact what we do on a daily basis? Sometimes, just sometimes, you get a little spark of what's about to come. This talk is all about embedding WebAssembly in the future. And I've just told you all about the future and how murky it is. But I want to talk to you also about what we mean by embedding. I don't know if anybody here is a researcher. Yes? Awesome. You probably know. Never rely on Wikipedia for your answers. So I apologize. Here comes a quote from Wikipedia. So, an embedded system. It's a computer processor, computer memory, and an input-output. And that's really interesting. Because if you look at what WebAssembly in a runtime is outside of the web browser, it has a runtime. It looks a bit like a processor. I can control it. I can execute code. It has some memory. In this case, I've just depicted the byte array. Of course, it has some input and output, which is via Waze or another system interface. And overall, that looks very much like a tiny little embedded system all by itself. Now, we can map that embedded system to a traditional piece of hardware, to our traditional embedded environment. But we can also embed software inside software. And if you saw Luke's talk earlier, you'll have seen the component model version of that. And that, even in an embedded system, is a very powerful thing. Now, WebAssembly has already a lot of success in the embedded space. And there's perhaps two really good examples that we should all cover. Obviously, Amazon Prime Video and Disney Plus Streaming. Amazon Prime Video, you know, famously, they support thousands of devices in the field, or with a common runtime, and all with interchangeable business logic in WebAssembly. And if you go and visit Disney Plus's website, you see them talk about how they went from file new to a fully working product in about 18 months. But there's more. You've probably seen Midecura's work. There's some fantastic work that our colleagues from Bosch were talking about earlier, and even some really exciting work from Carnegie Mellon on orchestration and factory automation. And they all give great views on what could come, just enormous, that direct to embedded space. But before we go any further, let's have a look at what we mean by embedding software inside software and why it's so important. And there's perhaps one really good example of that in production today. And that is not relying on the component model. It predates it. And it's RLBox from the University of San Diego. So just as Luke pointed out earlier, in, again, normal operating system, if we load a library, that library assumes the rights and privileges of the process it was loaded inside. I've done prior research at Intel where I've used the library to decompile the running executable and do lots of analysis on the instruction sets it's using. But, you know, this application could be your bank account, your banking app, and it has access to all the memory, including your bank account numbers. And if that banking app talks to the internet, it has access to a socket too, which is perhaps not the best thing you'd want. So how do we solve this without using the component model? Well, RLBox takes your library, compiles it to WebAssembly, and in doing so, make sure that all memory accesses access to linear memory that it's provided. This translation enforces the sandboxing. It's then translated again with Wasm2C back to C code and compiled back to native. This restores some of the performance hits. Of course, this means that WebAssembly, when you do this compilation step, now only has access to the memory that you give it and the functions you allow it to call and nothing else. So it no longer has access to a network socket and it no longer has access to all of the executables memory. And this we refer to as micro-isolation. But before we go further, I talked about peering into the past and I think it would be a great time to do so. This is a parallel, I think, that's quite interesting to explore. And I want to talk to you about a really old computer from the 1980s, the early 90s, and it's this one. So back in the 80s, there was a really successful UK computer company that had sold a lot of 8-bit machines to UK schools. But technology advanced. The Atari ST, the Amiga, and the IBM PC were in people's homes and offices. There was a need to move on from an 8-bit computer to something a bit more powerful. And they went searching for a replacement processor to base the machine around. They looked at the 68000 in the ST and the Amiga and they looked at the 80286 from Intel in the PC, none of which quite fit the bill. So they decided to go ahead and design their own processor and they made this machine the Archimedes around it. We don't see the Archimedes today, but the company behind the Archimedes was called Acorn and the chip they designed was called the Acorn Risk Machine, or the ARM processor. And we know that today from the Raspberry Pi, your mobile phone, and if you're fortunate enough to have one, you're an M1 or M2 Mac. Now that chip, that processor was hugely successful, but not in the original desktop format that it was created, but in the embedded space. And we think about why. Why did it succeed? It was low power, low footprint, and 32-bit. It brought to the embedded world capabilities that had previously only been available in a desktop. Programming structures that were used in a desktop in the 32-bit world could now be used in an embedded system with a really low power draw. Not only that, but the way they sold their processors allowed you to customize them. Now, we don't customize the instruction set of WebAssembly, but we can customize how it talks to the rest of the world. WebAssembly is also really lightweight. And it's this combination of the two things that points us towards WebAssembly's success in the embedded world. There's a fair chance it could replicate what ARM did. Wouldn't that be amazing? It's not there yet. So the next question really is, what does success look like? Well, I'm a Siemens employee, so I'll give you an overview of what we do and where WebAssembly could have a big impact. So, Siemens, in fairness, does a whole lot of stuff. We are 311,000 employees worldwide and about 50,000 here in the US alone. There's a fair chance that something you touched or interacted with today was made by Siemens. If you have been unfortunate enough to have had your bloods taken, I hate having that done to you in my annual physical, but if you've had your bloods taken, there's a fair chance that it's Siemens hematology equipment. If you're really unfortunate and had a CT or an MRI scan, it's probably a Siemens piece of equipment. If you traveled on a train, 80% of the railroad crossings in the US are Siemens equipment. And if you drive a Ford, the engine block was probably milled by Siemens milling equipment. And if you have an electric F-150, the charging system was Siemens. All of these are industries where WebAssembly can play a part. But that's not all. Part of the power network in the US is Siemens equipment. And I'm not just blown smoke. We've got some data points on the impact that it could have. The power systems in the US are undergoing a bit of a revolution from large generating systems, from large power plants to renewable energy. And in doing so, the grid that controls it is also being changed. We're going from large monolithic grids to lots of little micro grids for micro power generation. These grids form part of the national critical infrastructure and they will also need to coordinate and talk to each other with a distributed algorithm. And this is where WebAssembly comes in. And this is my data point. Last month, my colleague Ajay presented at the IEEE PES conference on a piece of work that was part funded by the Department of Energy. And here he showed how WebAssembly could be used to control a utility-wide power grid. And the algorithm, when compiled down to WebAssembly, it's not megabytes in size. It's tens of kilobytes in size. And then depending on what you want to do, it's under a kilobyte by itself. It's a really tiny, powerful distributed algorithm controlling huge swathes of the national power infrastructure. So what is it about WebAssembly that really makes it so really appealing in the embedded space? Outside the Web, we think about portability. Being able to compile code and run it anywhere. We've all, I suppose if you've got white hair like me, been around long enough to have heard that phrase before. Of course Java tried it. It worked, but as anybody who worked with Java, like I did, it became a compiler that the marketing slogan was write once, run anywhere, and it became a write once tweak everywhere. Not because the byte code was different, but because the interfaces to the system were different, which is why WASI becomes so important. Defining a common set of interfaces provides us with portability. If you think back in the past to what Amoeba tried, the distributed operating system from Tenenbaum or Plan 9 tried, those operating systems again don't succeed today. They're not around, but they taught us an important lesson. Both looked at the problem of writing a distributed operating system and both encountered the same issue of needing some sort of common execution format to run a distributed hardware. That's really what WebAssembly provides. Namely, Java even came from a distributed operating system research at Sun. This points towards distributed compute from many different suppliers running on hardware, and that doesn't work without some form of software sandboxing. As we've heard in the component model talk, being able to sandbox the software, and as shown with RLBox, without the component model, WebAssembly can do that too. And it's important to be able to do this in order we can convert our embedded platforms, give them this capability that was normally reserved for a virtual machine or container, and we can now do it in an embedded system. It means we can open up these embedded systems as a platform to third-party developers. We can invite code in. But combine it with portability, and as Luke pointed out earlier, you can combine languages and tooling. That becomes really very important. Our devices are becoming ever smarter. And the question you've got to really think about is, how many machine learning experts do you know who are also really, really good at embedded seed? Right? Exactly. It's nigh on impossible. But if I can take some of what they're compiling, if I can have this portable, a common compilation target, I can then bring it on to this device. And that's really this mixed skill set kicks in. And it's a huge gain. I've already moved on to this common compilation target. And it's becoming really important. You know, when we select a piece of hardware to write software for, we take the tool chain that comes with it, the compiler and everything else, so we end up with usually C or C++, and we're locked into that tool chain, that board support package, and that development platform, and that's it. And at Siemens, and I will come on to this later, we supply products and hardware like the MRI machine, the CT machine, the railroad crossing. I can't change those every year or two. They sit in the field for 20 to 30 years, and we have to update them and maintain them. And that's one heck of a challenge. By divorcing the compiler tool chain from the target it runs upon, we can keep the compiler tool chain using the latest and greatest stuff and still target our old hardware. That's really the WebAssembly runtime side, but it's only part of the story. There's a whole bunch of supporting functions we need. We need something that allows us to manage and deploy this code and manage a full life cycle. It's becoming increasingly important because the EU have a new Cyber Security Act coming out, the Cyber Resilience Act, and along with it, NIST are pushing out some standards that look very similar. Making sure that us as an embedded developer follow good security best practice and publish updates and security patches to everything connected to the internet. That's an issue. We need some way to remotely control and manage just the runtime that's running on it and the payload of software that executes. Now, it's not all doom and gloom because we can borrow from what's happened in the cloud. We've seen wasm and Docker work. We can get OCI images and we can execute them and contain a D. That's a huge chunk of what we need to do, but have you ever tried putting a Kubernetes node on a ESP32? It doesn't fit. We're part of the way there, not all of the way there. And some standard mechanisms and orchestration and deployment would be critical. I mentioned earlier designing for 30 years ago, and when you think about 30 years, it's just a number, but it's always fun to give it a bit of context. So what was happening 30 years ago? Well, Jurassic Park was out of the cinema, and when you drove there, you were probably listening to Janet Jackson and Boys to Men. Maybe some of you weren't even born before Jurassic Park was out. 30 years ago, of course, first Debian release. 30 years ago, we had the first browser, Mosaic. It looked like that, but it didn't run on the PC. It ran on a Unix machine. In fact, the best-selling game on the PC at the time was Seventh Guest from Virgin Interactive, and it needed a 32-bit 386 PC with two megabytes of RAM. What's really interesting is two megabytes of RAM and a 32-bit chip looks an awful lot like some of the embedded systems that we developed for today. But how would you write software for that PC today? It probably ran MS-DOS 5, if you're lucky, maybe 3, and Windows 3.1. What compiler and toolchain could you use today to generate code for that? What would the developer experience be? How would you debug it? These are things we deal with on a daily basis. And if we think about WebAssembly, not today, but in 30 years, we have to think about this exact same question. How's that toolchain evolve? How do we keep being able to develop software with it that will still run on the WebAssembly run times we released 30 years ago? That's one heck of a challenge. That's where standards come in, and it's really important to solve that through the standards community. Standards mean multiple suppliers of technology. It means we have a fallback. Relying on a supplier for 30 years is one heck of a burden. So if you have more than one supplier, there's a fair chance that at least one will still be around. If we have that, then worst-case scenario, if both suppliers go bust, we have the standards, and at the very least, we have the blueprint for what we have to do to do it ourselves. So what does this make WebAssembly look like? Well, if we can solve some of these problems, then we end up for WebAssembly being something that can be used everywhere a container can't be. And this is a phrase we've been using internally inside the company to describe what we see with WebAssembly. It has the potential to be the de facto standard for small portable form factor software. But it's not all there yet. However, we have some really talented people in the standards groups working on it. I want to give you a brief introduction to those standard groups. I think in the previous talk from Luke, he mentioned some of them. So there's really two sides to the standards organization. We have the WebAssembly community group, and that's where WebAssembly originated from, that the guy's working in the browser, trying to make sure that everything works, we get great interoperability, we get great speed. In fact, I think I bumped into somebody from Apple earlier who was doing just this. So that's the WebAssembly community group. And on the other side, we have the WASI subgroup, and it's focusing on the system interfaces. Now, the community group obviously is focusing on the browser world, and our WASI subgroup is really focusing on the non-browser world, which is where as an embedded developer, we'd sit. Some are working on the embedded space, and there's a good chunk working on cloud-hosted software and software ecosystems. Everybody's very talented, but understandably, they all have slightly different motivations on where things should go. Both groups do talk and cooperate really, really well, and they're both really friendly and actually quite welcoming to new input and ideas. And they do share some technology. A lot of the inscripting work resulted in upstream changes to LLVM and Clang, which is then pulled down and used by the WASI group in the production of the WASI SDK. And so there's a lot of cooperation and shared assets, but it's just recap on some of the challenges that we see. So as the WebAssembly standard changes, even in the website looking at the core opcodes, and on the website for changes for the opcodes, it has to be two web run times that support it, not two run times, which means if we wanted to introduce an opcode change on the embedded side only, we'd have to make sure that all the browsers could support it, too. But on the opcode side, these opcodes are changing. The standards will evolve, and we need some way of being able to support that long-term view of being able to still generate code that can run on an older WebAssembly runtime. And that's really important to try and address. Dynamic composition is really important. Luke's mentioned some of it with the component model as a way to do it by loading of components like DLLs and shared objects, and that's great, and it's part of the story. We don't want to be sending giant WebAssembly binaries to small devices. It just doesn't work. And as I mentioned before, we need some mechanism for deploying WebAssembly to microcontrollers and understanding really what they do and how they work, looking at the standards. Is Kubernetes the right fit? Is there another solution for it? Lastly, we've got to look at sandboxing with performance. There are lots of ways to implement sandboxing. WebAssembly gives us one with memory bounds check access. That's really important. But each memory bounds check is a performance hit. Last year, we released some research we did internally on the performance of WebAssembly in different programming paradigms. If you've got a deeply nested C++ data structure with a large V-table, you get a performance hit. Is there a way to remove that? Is there a way to speed up things like the component model and function calls across boundaries while preserving memory isolation? Well, for that, perhaps the solution is actually in hardware. And we've been exploring things like Cherry, which is a capability-enhanced RISC instruction. It came out of some DARPA research about 10 years ago and has now continued to be invested in by the UK government and ARM and the University of Cambridge and SRI. It's interesting because it gives you protected memory spaces that you can create just like a pointer. And the hardware looks after bounds checking for you and generates a hardware exception if you break it. Wouldn't it be wonderful if we could use that with WebAssembly? Wouldn't it be wonderful if we could solve some of the sandboxing performance issues? And this is where you guys come in because the standards committees are looking at this and they're full of really talented people looking at this very difficult problem. And they're looking at it from different angles. And you know, there's many within the WebAssembly embedded space that are either looking at WebAssembly and actively considering its deployment or are actually using it in production themselves. But they're not necessarily actively contributing to the standards or actively contributing to a WebAssembly implementation. But that doesn't mean you shouldn't get involved. The embedded space has some unique and difficult problems that other environments don't face. And by sharing our view on what those and problems are for the standards committees, and that's why I gave you the overview and getting involved, even if you're not contributing to an implementation but suggesting a potential alternative solution or discussing some of the pros and cons of what folks are proposing, it gives great guidance into what goes into a standard. And more views and more eyeballs will only make it stronger. So it's only with your help that we can try to address these problems and really embed WebAssembly in the future. Thank you very much. So the question was, what does Tier Portal fit into all of this? And so for those who don't know, Tier Portal is a Siemens product. So right now today, Siemens does not yet have WebAssembly in production. Not yet, but likely to have something soon. So I can't say on that one. But is there any other questions? Yeah. Oh, 100%. So the question was, for embedded runtimes, can we talk about what we would prefer or what we've played with? So last year, there was a W3C in-person meeting, which due to COVID, I couldn't go, but we attended virtually. And our friends in Carnegie Mellon, Dan Titzer, organized a WebAssembly research day. We presented that, some of our findings. And what we did was a performance analysis for multiple different WebAssembly runtimes and what we saw out of it. And we compared WASM3, WASMTime, WAMMA, WASMA, and we looked at what they did, how they worked, and what performance we could get out of it. And we very much moved forward with the one that best suited our use case was WAMMA with a head of time compilation. Really looked like the most reliable one. From a performance point of view, that research showed that WebAssembly was in that form deterministic enough, reliable enough to use in a control system. And I think our colleagues from Bosch pointed out the same conclusion earlier. And internally, the phrase, a very slightly slower CPU is used when we think about WebAssembly. That's a great question. So the question was if we isolate the WebAssembly compiler tool chain from the compilation of a running target, but the running target needs a compiler to have your runtime running on the running target in the first place, then how does it solve the problem? So it reduces the amount of work that needs to be done for a start, which is really important. And secondly, depending on the product, you know, when you talk to folks at Amazon Prime and they talk about the number of devices they have out in the field and how often that they can update the WebAssembly runtime itself, that update frequency is much smaller than the WebAssembly payload that it executes. So it reduces the workload and burden dramatically. And it also, you know, for us, depending on the product, maybe we'll update the WAMR runtime if there's a security issue and it's critical, maybe, but there'll probably be products that will not ever be. And that's where this 30-year view on where things are going becomes really important. And that requires some versioning of the bytecode in some form so you can understand what's going on. And that's a difficult problem all by itself. You know, traditionally in a compiler or a running system, you would say at runtime, does my CPU support this instruction extension? I know, an AES encoding instruction. If it does, here's the hardware-accelerated bytecode. If it doesn't, here's a software emulation that will do it and it'll do it slower. And that sort of conditional check doesn't yet exist in WebAssembly and yet we're adding new instructions to it. So that's an issue that we need to look at. I took to Conrad what and he was mentioning there are proposals for a thing called a profile or WebAssembly profile so you could have different profile output at the compile time. So there's ways and means around that problem from a WebAssembly point of view but they're not all solved yet which is part of the reason why we should get involved in trying to address it. It's an interesting question and I don't have the complete answer to it. I think the proposal, the question was Bosch mentions targeting a subset of WebAssembly for automation. Is that the way forward? It's an interesting question and I think from our point of view I don't think Bosch has done that yet but they're proposing it as a potential way forward and anybody that remembers Java that looks a lot like J2ME. So we can do that and there is a balancing act. If you go too far J2ME then you can compile C and C++ but if you want to run any Python you're kind of stuffed because it won't work. So there's a balancing act for your application payload and what you're going to do. So the question is where is it? Is it the profile thing? Because if you went down the profile road which is in part what Bosch was suggesting you end up with J2ME or a variation of it. We can be smart about it and try and vary what those profiles look like or we could go down the conditional check path or we could do something else. We could put filters in place to pre-process and modify WebAssembly before it gets to the target depending on what the target could do. So there's things we can do before launch before sending it out for execution. What the exact answer is I don't know but I want to have the conversation with you guys and the standards people to try and work it out. Yes. I think it really does. The question was does WASM change the embedded debugging story in any interesting ways? For us? Yes. Obviously you have this concept of now I can run the exact same code as I'm running on my target I can run on a non-target digital twin of what I'm going to use it for and that gets really important for when you're building cyber-physical systems and safety critical systems and how they act and operate with something that the number of speakers talked about this afternoon and it is so true. The thing with cyber-physical systems is unlike a cloud-hosted system it's stuff you can touch and feel and that can hurt you if it goes wrong. So being able to host this software with a digital twin and do some debugging is a really interesting way to go about it from shipping the exact same binary with no changes to the target for execution where it shouldn't execute in exactly the same way and that's really a very powerful developer and customer story which would be lovely to see out there. The difficulty is getting there. So come along get involved, come along to the discussions. Any other questions? Going once going twice Thank you very much everybody. Thanks for your attention.