 My name is Ming Chiu-Sung. You know, our topic is developing Android Contacts Hub Runtime Envelopment, CHI, Nano App in WebAssembly. So, you know, it's been a pretty long day already, and I think this is the last session, so thank you for sticking around. And, you know, the first also this book, Jian Qiang Li, he's actually in PRC, so he cannot travel here, so I'm just, you know, cover the topic for him. Okay, so here's what the agenda looks like. We're going to talk about, you know, what is CHI and what are the Nano Apps that we're talking about moving to WebAssembly, right? And what is the value of converting them to WebAssembly? And what kind of challenge do we have, you know, for migrating the Nano App to WebAssembly? And then we'll present our architecture, which, you know, involves like a solution to multiple of those challenges. And then, you know, we can summarize on the project learning that we have. Yeah, so there have been like quite a few, you know, very interesting embedded talk in this conference already from, you know, Bosch in the morning and Siemens, you know, they all talk about WebAssembly running in like a really resource-constrained environment. So here's another opportunity for us to push, you know, WebAssembly to the bleeding edge that is this Android CHI environment. So if you look at the right diagram here, you know, this is a typical Android software stack, you know, basically, you know, most people probably are familiar with the left-sided, which is the Android application framework and, you know, Android app running on top of the framework. But not a lot of people know like there's a second computing environment within your Android phone, which is a context hub that is running on MCU on a very resource-constrained environment. And you have, you know, basically a bare minimum scheduling capability for the CHI, which is like a round-robin, you know, task running system. So it's pretty much, you know, like a bare-metal environment for NanoApp to run on the right side of it. So why do we need to have this kind of environment, right? So if you look at the bottom, you know, this example, like if you have your earphone and you want to pair with Android phone and if your phone has a CHI system, you can get paired with your phone immediately. Unlike, you know, if you have like a really old phone that doesn't have a CHI, you need to wake up your application processor and then, you know, you finish the pairing and you end up wasting a lot of your battery power just for this purpose, right? So the CHI environment is a low power, always on, always running environment. And that's the reason that it run on, you know, really pretty weak processing unit, MCU, and extremely limited, you know, resource environment. You know, typical CHI environment, you will get maybe a few hundred kilobytes of memory as compared to your phone, you know. The main phone, you probably get at least, you know, eight gig or 16 or even more. So the CHI Nano app, they're all very small applications. They do like a specific task, you know, pairing is an example. Like when you receive some Bluetooth signal and you have, you know, Bruce Nano app kicking off and does the processing for pairing or any additional tasks that need to be done and then you finish the task and they yield, you know, the MCU back to the dispatch schedule. And there's a tremendous amount of challenge in this space. You know, we all know like there's a huge app ecosystem for Android phone, but you probably have not heard about Nano app ecosystem, right? So there's a reason for that because this is, you know, pretty difficult to program. It's a near bare metal environment and Google itself doesn't really open it up to app developer for this. And it's basically, you know, the Google building Nano app and the some OEM Nano app that allows to run in this environment. So the opportunity is very clear. Like if we move this environment to WebAssembly, then you can open them. You can have all the WebAssembly benefit and you can open the ecosystem to innovation by the, you know, the complete community of developers, right? The Android developer. So we all heard about, you know, the advantage of WebAssembly quite a few times, you know, today, for example, through multiple talks. There is sandbox security. So you don't need to worry about one Nano app, you know, trashing another Nano app memory, right? So that's the one example because they are maybe, you know, most likely they are from different vendors. They do different things. And there's also cross-platform and cross-architecture advantage of WebAssembly. So currently, you know, this MCU is non-standard. So every day does its own thing. So it could be, you know, a MCU from Texas Instruments or from some other companies. So there's a variety of companies that are doing all the different architecture. And so then typically, you know, you need to recompile everything, targeting a specific hardware. And the C-Purpose is the only language that you can use to compile this, you know, for this environment. So obviously, you know, if you can use WebAssembly for this purpose, then you can open it to all kind of language, even though it's like a modern, you know, managed runtime languages. Yeah, so that's kind of a motivation we have to, you know, to basically build this project. So it's basically, you know, C-H-I-E on WebAssembly. So that's the project that we are building. And so our design goal is to compile unmodified NanoApp, you know, source code to WebAssembly and run it on C-H-I-E. And we basically say that, you know, you shouldn't need to change anything to your source code in order to compile to WebAssembly. And you need to maintain the existing, you know, NanoApp lifecycle. And you should have, you know, interoperability between the native NanoApp and the WebAssembly-based NanoApp. So they can talk to each other because we don't expect, you know, wholesale instant replacement of all the native app with WebAssembly. So there might be a, you know, migration process. So this interoperability is actually very important. So I have provided here a GitHub, you know, link for this project. So if you're interested, you know, go to that site and take a look at what do we have implemented. And, you know, you're welcome to contribute to this project. So another thing to talk about is that, you know, this project is based on WebAssembly micro runtime or WAMR. So you probably heard about WAMR multiple times, you know, today through multiple talks. So like, it's a pretty popular WebAssembly runtime. We actually started about four years ago at Intel and then we donated that to Bicoalize. So it's one of the two WebAssembly runtime in Bicoalize. And again, quite a bit of attraction in the industry, you know, especially with multiple customers, you know, you've probably heard of Amazon Prime Video using WAMR and Siemens and Sony and the Bosch. You know, they mentioned that they're using WAMR as well. So yeah, so the reason for that, you know, this runtime is implemented in C and, you know, has a very small footprint and high performance. So that basically, you know, make it like a really suitable for resource-constrained environment such as the CHIE. And it has, you know, multiple execution mode. You can do it in interpreter or just in time compiler or even ahead of time compiler. So any of those things that you can use and support the Wadi libc and the Wadi, you know, for neural network as well. So that's kind of motivation for, you know, using WAMR for this purpose because as I said, you know, the CHIE environment is actually extremely resource-constrained. You know, typically it's only, you know, a few hundred kBi to a maximum of two meg of memory available in this environment. So let's take a look at how CHIE NanoVac works. So the CHIE basically, you know, uses like a shared memory concept and it has a global shared, you know, heat that they use to pass data between different NanoApp and between the CHIE and the NanoApp system. And there's also an event queue. So, you know, anytime like a sensor detects something, you know, you basically generate event and NanoApp can also generate event as well and the event, you know, basically being processed one by one and the dispatch basically, you know, call into appropriate callback time, callback functions in different, you know, NanoApp callback functions. And after you are done, there's also a free function that you can free the event from the heap so that you don't, you know, run out of a heap space. So that's kind of, you know, how the NanoApp works. So basically, it's like a round robin, you know, scheduling system and processing like a function call by function call based on event, trigger, you know, and once, you know, it's done, then the next NanoApp is scheduled to run on the MCU. Okay, so let's think about this kind of system. So now we want to move it to WebAssembly, right? So there's quite a few challenges here. You know, first one is that we need to ensure that, you know, the data structure, for example, the event data that people are passing around between NanoApp and the CXGA system, they need to have exactly identical structure. That's one, right? And because the reason for that, you know, your WebAssembly ecosystem use different compiler than, you know, typically used by the CHE system. So different flag in different compilers, they may generate like a different order of the same structure. And so we need to have regular to ensure that they have analytical structure. So the second challenge is that, you know, it's quite common for CHE system to have multi-layer definition of a sensor data structure or the event data structure, you know, they have like a structure within a structure or pointer within it. And we all know like a WebAssembly is linear memory-based, so there's a need to translate back and forth between the two representation system. And so another problem is that if you convert NanoApp into WebAssembly, and we know that the, you know, WebAssembly has this sandbox environment and you cannot access memory outside your linear memory space, right? So that's the good things about WebAssembly, that's the security measure that we built into the spec. But now it's become a problem because, you know, the CHE NanoSystem use a global heap to pass data between different NanoApp, between CHE and NanoApp. So we need to have solution for that. And also on the reverse direction, say this event that need to trigger a callback function in a NanoApp, you know, you need to have a way to call into a WebAssembly function, right? So that's also, you know, it's like a violated WebAssembly modularity requirement. So those are the things that we need to resolve. So let's talk about a solution. So the first one, you know, we basically use a common solution, basically use the static assert into the NanoApp application to make sure that, you know, all those structures are laid, you know, layout are identical. So for example, like you specify the size of the, you know, the sensor information data and offset of each of the individual field. So they need to be identical. So if it's not, then, you know, at least a compiler can catch that bug and you can change your compilation flag appropriately to make sure that it's consistent and doesn't fail the assert. Okay, so the first solution, you know, it's fairly straightforward. So what about the multi-layer pointer in the sensor segment, right? So here, you know, we basically say, let's introduce a wrapper that's running inside, you know, there's the middle layer between the NanoApp space, which is WebAssembly, and the THRE, which is native. So the key point here is that this wrapper can be called by the WebAssembly runtime on top and also behaving as a native NanoApp. So it has access to all those scheduling and dispatching capability of the underneath layer. So that's exactly what we did. And we have a NanoApp and a wrapper here and basically for a multi-layer structure, this wrapper is responsible for replicating the native structure, which is named here into the linear memory space and then, you know, calculate the appropriate offset of that field in the WebAssembly structure. Okay, so the second issue is that, you know, how do we pass event from the native app, native NanoApp to WebAssembly handler? So similarly, you know, we built a, basically a wrapper for each NanoApp. So it's a one-to-one correspondence and when the event happened in the CHE layer, it would actually call into this function, you know, this event handler within the wrapper and then this wrapper basically make a copy of the sensor of the, you know, event data and make a copy in the linear memory and then it calls the appropriate WebAssembly, you know, function handler so that it knows that which area to look for inside the linear memory and processes the event data appropriately. And of course, you know, after the call is completed, the CHE can call the free call to the allocated space. Okay, so this question, you know, it's kind of an opposite of what just described. So this is for WebAssembly NanoApp to send the event. So the, you know, basically the reverse order what we just talked about, you know, this one NanoApp will actually, you know, call this wrapper, event wrapper and this event wrapper then, you know, it's responsible for, you know, converting the event data and make a copy into the native CHE environment and then, you know, this wrapper will call the appropriate event handler for the event data that's got passed into the CHE environment. Okay, so in summary, you know, this is our architecture. So we have NanoApp that's written, compiled into WebAssembly, running at the top layer. And then we have the WebAssembly micro runtime running and then there is the intermediate layer that run a bunch of wrapper. You know, we talk about like a data mapping, you know, event data and NanoApp wrapper for each NanoApp and there's like a per sensor wrapper such as audio wrapper, you know, Bluetooth low energy wrapper. So all those wrapper, you know, for facilitating the communication between the CHE environment and the WebAssembly based NanoApp. And at the bottom it's, you know, the original CHE environment with all those different sensors, drivers, you know, things like that. Yeah, so that's our architecture. Okay, so I'm gonna do some two small demo here. So on the left, you know, basically we have a CHE emulator running on Linux and we have a test program that initializes all the different sensors and then, you know, registers themselves with those events and then when the sensor detects events, you know, those callback functions get called and the event got processed by the WebAssembly CHE NanoApp. So on the right it's actually kind of a similar demo but it's, you know, it's GPS signal handling and, you know, basically a NanoApp query the CHE system for position data and once you get the data, you know, you send it to NanoApp and process the data. So we talk about, you know, this challenging runtime environment with extremely limitless resources. So based on our prototype, you know, even with all those wrapper and all those data converters that we added and a managed runtime, you know, while the runtime added into it, we only increased member footprint by, you know, roughly 300 kBi. So that's usually, you know, it's acceptable for the CHE environment. You know, it's dependent on, highly dependent on like the, you know, manufacturers and they can vary between a few hundred kBi to two meg and that's, you know, well within the acceptable range. And the memory usage, you know, we only observe like a two to 11% increase. So it's not significant. Okay, so what have we learned from this project? So, you know, we think we achieve our design goal that is have WebAssembly and the original native CHE application working side by side and interoperable and we prove that's actually achievable within the CHE environment with, you know, very small, you know, resource usage by the WebAssembly runtime and the WebAssembly, you know, nano app. So we think, you know, this sort of approach can be useful for, you know, some other, you know, embedded environment framework as well. However, we will say that, you know, this is not an ideal solution. You know, you can see like there's a lot of intermediate layer. We had to add the wrapper to, you know, to kind of propagate the event and pass the call between the two system. So the reason, you know, the main reason for that is really, you know, big deal to the, like the architectural difference between CHE and the WebAssembly. And, you know, CHE basically assumes, you know, memory share everything kind of approach rather than, you know, memory isolation mechanism in WebAssembly and the, you know, the API call, for example, the data structure they use to pass calls. It goes through the global share heap. So we think if we can design a CHE from ground up with WebAssembly we can probably have a much better optimized, you know, solution for that. We can probably use like a message passing or theorization as opposed to share memory for those, you know, interaction between the runtime and the app. So that's something that, you know, definitely, you know, depend on community interest. So we can, you know, work towards that direction for a better solution in the future. So that's pretty much my talk. Any questions? Excuse me, I have a little bit of time to understand what you say. You know, could you say louder and move, maybe move closer? Oh, so, yeah, so CHE environment, you know, it's low power and it's resource constrained and it has like extremely limited OS capability, right? And that's the reason, you know, a simple share memory, share everything approach was used. And it's definitely not the, you know, most secure mechanism and it's also limiting the, you know, the opportunity for innovation. You know, just think about what kind of thing you can do. Like, you know, for example, like one network app that we constantly use, we may not be aware of it. It's like a step count, right? So when you walk, you know, it counts how many steps. It looks like a pretty simplistic, right? You know, use some theoretical movement, you know, signal of your sensor data and to calculate how many steps you have walked, right? And based on our personal experience, we know like there's good ones, there are bad ones, right? Some are like really horrible. They are not accurate at all. And some are a lot better, right? So, you know, this is an area that you can actually have a lot of opportunity for innovation. You know, one example, like if you, you know, build some sort of machine learning capability into your step, in your movement, you know, this step count could be a lot more accurate, right? So, you know, kind of a semi-closed environment with like a very risky, you know, security isolation. You know, I think Google would not be able to open it up to everybody. Or Yen would not be willing to open it up because there's too much security risk to it, right? But if you move to WebAssembly, you know, this potentially, people will come with all kind of innovative idea. So maybe the sensor data, you know, the gyroscope and the couple with your GPS and something like this kind of a combination, you can come with a really innovative use model. Just like what happened to the app store? People come with all kind of apps, right? Because it's open ecosystem. And people can invent, you know, new methodology or new usage methods, use cases. And this is not happening to CHRE. You know, recently that, you know, it's not built on solid architecture, you know, on a solid architecture so that it's difficult to open up. By moving to WebAssembly, I think it should give people this sort of a new opportunity, you know, to innovate. Any more questions? Okay, I guess, thank you for sticking around. Yeah, so, yeah. And I have contact information here. So Zhenjiang is the original author, the first author of this work. If you want to have like a detailed coding question, you know, show the email to him. Okay, thank you.