 Hello, and a very warm welcome to this Zephyr Project mini-summit. My name is John Round, and I'm going to be covering the introduction today for the other speakers and for the other topics that we're going to be presenting. Now, if you would like to glance, this is the list of folks that are going to be presenting with us today, and it's a warm welcome to all of them for taking the time out to present, but also a warm welcome to everyone who's maybe new to Zephyr and watching this presentation for the first time, or just learning about Zephyr, but also not to forget the number of people who've been participating in the Zephyr Project over the last several years, and have really got Zephyr to where it is today, so a warm welcome to all of you. Now, no project would be complete without a vision statement, and four years ago, roughly now, Zephyr started as an RTOS project, and some people at that time would say, is there an requirement for yet another RTOS project? And the answer for that is, yes, when you start to look at the details and the way the market's changing, we feel that there was a real demand for a real open source, open governance RTOS project, and the success of Zephyr really is reinforcing what we were thinking at the time, and indeed what many others were thinking as well. Now, when we look to the facets of Zephyr, what makes Zephyr different, what makes Zephyr interesting, number one, it's an open source project. Now, many projects claim to be open source. This is an open source project housed under the Linux Foundation, and we're going to talk a bit about that later on, but it's very important to say, open source, as a word on its own, is not extremely important. It can mean a lot of things to a lot of people. But when we talk open source, and we talk community, we talk permissive licensing, and one of my personal beliefs, open governance. So, when we talk about an open source project and we talk about Zephyr, we're talking about many facets for a project, which we think are fundamental and extremely important. And as I said in the introduction, now we believe many people agree with us when we look at the support that Zephyr is getting. Now, architectures, well, we support most of the main architectures. Again, this is a community project. So, I was always told that when someone asked me, oh, do you support this architecture? The answer is, if we don't, we'd be delighted to have you participate and add that support. So, we're on the leading architectures. It's increasing all the time. And in fact, if you look to the number of board level products that we've got, there really is a significant catalog. And boards are all about getting people started. And if you look to this catalog, I look in the middle, actually, the micro bit, we really are starting at the lowest price point, but with good functionality. So, when you can put Zephyr onto one of these development boards and have a Bluetooth mesh running within literally your first hour of engagement, I think not only have we created a functional RTOS platform, but we have created a platform that can get people started and give a range of solutions out there. Now, I look at this type of board. And now what you're seeing is Zephyr shipping as default on these boards. So, these e-paper conf badges, et cetera. What does it do? It lowers the barrier to entry. It allows people to play with Zephyr. It allows people to get involved. And that's what community is all about. It's all about building that community involvement. Now, as I bump into my animation, one of the comments that was on the first slide about our mission statement and I said, why Zephyr? Why another RTOS? Well, one of the comments there was functionality. We didn't want just an RTOS. We wanted an RTOS that had a high level of functionality, but also was designed for constrained devices. Fundamental to our mission was safety and security. So, again, as we looked at the RTOS world, these were not facets, behaviors, or capabilities that we could see in open source platforms that had full open governance. What you see here is a modular architecture. And it's a modular architecture for a reason. It was designed to expand. It was designed to accommodate new functionalities. It was designed to move away from getting a kernel and then figuring out what USB stack or what BLE support you would add to it. It was meant to be a package, a bundle of tested modules. Then we could look to security. We could look to safety. In other words, as this project expanded, it brought a great deal more than just an RTOS platform to the world. Now, when you look here, what you'll see is a selection of the type of functionality that is enabled. There are really an expanding library at all times. If you go check the website, and there's going to be some discussion from the other speakers, but again, this is a community effort. So if you see something that's missing, consider yourself a volunteer, because that's what we're looking for. We're looking for participation to just grow this diagram and grow the capabilities of Zephyr. Now, I'm not going to read this list. In fact, I don't know even if you can see that text. That is a good thing. These are the number of companies that have been participating in the Zephyr project over the last 12 months. Now, where we started from? Well, we started from zero. We started from a vision statement. As I said, look at the number of people who now are sharing that vision. And it's not just about sharing. Community projects are about participation. They're about getting involved. And what we can see here is a huge list of people and companies getting involved. The way I tend to promote this to people is to say you could never afford this level of capability and size of engineering team for your company. Maybe some of the bigger ones. But then you wouldn't have the richness of the community project. So when you look at this level of participation and we have several graphs showing up into the right, this just keeps getting bigger. And that's people participating in the project. Here, again, it's not a competition. There's no way that we're going to have a world with only a single RTOS. But as a board member and with the other board members, what does this do? This tells us that that vision is shared. That's not a marketing statement. It's not a promotional comment. This is a way for us tangibly to see what is actually happening. And what you can see here, and this number continues to rise, is as more people get involved, the project just gets better. And that's, again, the plus of a community project. Now, this is a slide I think is particularly important. And when you look, I mentioned at the start to open source projects, many people will claim, well, my project is open source. And really what that means is you can access the source code. But then the first thing you have to do is check the license. Zephyr is an open source project, but it has the other extremely important piece, which is open governance. And I have to say, I've had involvement with the Linux Foundation on and off over the years. They do run an extremely good project. In other words, we have structure. We have transparency. We have openness. We have code of conduct. In other words, we have a project that's properly managed. Unlike some of the more proprietary entities who may put something in the roadmap, may remove it from the roadmap. You may have no ability to influence the roadmap. That's what an open source project is about. It's about you. It's about community. And that participation means you're a full participant. You're a full participant in this project as it evolves and as it's delivered. You can get involved today. You can add your devices today. So the Linux Foundation gives us a very strong governance framework. I must say it's just nothing but a delight to participate in. And I can talk for my other board member colleagues. And when you look to the technical steering committee in the community, the highest level, the highest level of competence and the highest level of inclusion. Now we look to the members. And quite frankly, the membership continues to grow. These are some great companies, some great people, and it's a great experience really to be involved with them all. Here's the web links which are part and parcel of this. If you want to get involved, all of us are more than happy to talk to you, but please reach out and look to these web links if you want more information. Now it's my absolute pleasure to introduce Marty Bolivar. And he's going to talk to you about WEST. Marty. Thank you. Hi, so my name is Marty Bolivar. I'm a Zephyr and a WEST developer, and I'm here to talk to you about WEST. I suppose that this is one of the early talks in the order because this is one of the early tools that you're going to run into when you're using Zephyr. So if you've already gone through the Zephyr Getting Started guide, you'll see kind of how WEST fits into Getting Started, but if you haven't, that's totally okay. It's not required and there's a link. What is it though? At its heart, it's an extensible command line tool for managing a workspace. Breaking that down, a workspace is just a directory with git repositories inside. That's it. Extensible here means that WEST is built around subcommands, and you can add new subcommands without changing the source code itself so it's pluggable. The other thing that you should know about WEST is that it is not a requirement. You know, we put it into the Getting Started guide because it is the easiest way to get going, but people do use Zephyr without it. So it's an easy way to maintain documentation for how to do so. And if you're looking for the source code, it's got its own repository under the Zephyr Project RTOS GitHub organization. So let's see a little bit more in terms of how it breaks down in terms of the core WEST and then the things that Zephyr does with it. So like I said, WEST sort of proper in the WEST repository is built around managing your workspaces. It has a configuration system, and then it has some Python APIs for extensibility. It's a good system because all of Zephyr scripts are written in Python for running on all platforms. Then in terms of Zephyr, there's sort of two main ways in which it gets used. One is for modules. And in the context of Zephyr, what a module is is it's a third-party project or Git repository that has some functionality that needs to get integrated into the Zephyr build system for whatever reason. It could be an SoC hardware abstraction layer. It could be an implementation of a file system. What have you? And then on top of that, we've got some extension commands which use those APIs to do Zephyr-specific things like building applications, flashing and debugging applications. And those all live in the Zephyr source code repository. So let's talk a little bit more nitty-gritty about kind of the main commands, your bread and butter commands that you're going to deal with. The first one is WEST init, and that's what you're going to use to create a workspace. The main things that you feed WEST init are the local file system, in this case Zephyr project, where you want to sort of initialize from, in this case the upstream Zephyr repository, and what revision you want to start at, in this case version 230, which is the most recent release from this month. What it's going to create for you is your workspace directory, Zephyr project, and then underneath it, it's going to have clones Zephyr repository which happens to contain this YAML file. The Zephyr project is the topter or the workspace root, and the WEST configuration file says that WEST.YAML lives in this Zephyr directory. So, what is inside of here? Well, the WEST.YAML file is basically just a list of projects, and if you kind of take a look at line nine, that project's list, you can see we've got a file system, we've got a bootloader, it's basically just a list of git repositories, where to check them out on the local file system, and some additional metadata like what revision to check out. I want to kind of zoom in on this from a more 10,000-foot view. So, it really is basically just think of it as a list of projects, and every element of this list is a pointer to a git repository. In upstream Zephyr, we've got all of these under the Zephyr project RTOS GitHub organization, mainly so that we can't lose track of them, URLs aren't going to change around us from underneath our feet, but when you're building with Zephyr, this is totally customizable, you can point this at wherever you want, you can host your own git repositories anywhere. So once you've got your workspace set up, the next sort of bread-and-butter command that you're going to deal with as a Zephyr developer all the time is WestUpdate. And you may have noticed that when you initialize the workspace, it didn't have any of those other repositories, any of those other dozens of repositories. Well, that's what WestUpdate is meant to do. And so when you run WestUpdate, it's going to look inside of the .west directory, find the config file, find your west.yaml file, notice all those projects, and then kind of figure out what it needs to do. So in this case, you've just initialized, you don't have anything, it's going to clone your boot letter, it's going to clone the fat file system implantation, it's going to put everything in the right place, it's going to check out the right revisions. So all the modules in west.yaml are placed under the workspace root in a directory called modules. And that's where your vendor house and your file systems, et cetera, are going to live. Now, one kind of important distinction to keep in the back of your mind is that not everything is a module. So you've got a repository that is a boot loader, which is an application, that's not a module. Another example would be there's a repository that contains a variety of tooling that's used for networking with Zephyr, and there's no Zephyr source code there, that's all host tooling. So although it's a project, it's not a module. Moving along, there's, here's some just some pointers to workspace management commands. I don't want to dwell on these, but the point here is that there's a variety of other ways that you can interact with your workspace. If you want to know more about them, turn to the online help. So you run West Help, and it'll print you kind of a list that looks a little bit like this. It'll tell you the name of each of the built-in commands. It'll give you a one-line help for them, and it'll tell you how to get more information. The slides also there, they have a link to the Zephyr documentation online. And let's get a little bit moving on from there over to the extension commands. Now, the previous slide contained the built-in commands that are developed in the West repository. You're also going to deal a lot with these extension commands that have source code in the Zephyr repository. And one thing to keep in mind about all these is that because West is optional, these are just wrappers, right? So when you run West builds to build your application, like you'll see in the Getting Started guide, really that's just a convenience wrapper around the Zephyr build system. The Zephyr build system is built on Cmake and Ninja or Newmake, and it's a totally standard, we're not reinventing the wheel here, but there's just a variety of commands that kind of make it easier to get started with and easier to use for many people. Sort of similarly, those of you who are very familiar with embedded development will know that there's a ton of different tools out there for flashing and debugging. And one of the things that you'll need to do when you get a new board is you have to figure out what they are and you know how to use them and often it'll be multiple commands chained together or you have to maybe write a configuration file. So because that's kind of a barrier for entry, to let you declare as the board porter, here's how I want my board to be flashed. So somebody can then just run WestBuild and then your users can just say WestFlash and because that's all taken care of behind the scenes, the build directory has all the metadata necessary to declare how to actually flash the target. I include this slide just because a lot of times you'll get this issue when you're just getting started. If you see invalid choice build, you're probably not running it inside your workspace. In practice, I get this one a lot so I'm just avoiding myself a little support here with apologies to the Linux Foundation for wasting time. All right, moving right along. So we've covered workspaces, we've covered a bit of the extension commands, we've covered kind of the bread and butter commands. There's one final command that I'll just mention briefly and that's WestConfig. We saw earlier that there's a dot West slash config and that's where your local configuration is. Another thing to kind of keep in the back of your mind for later is that you can also set your configuration user and system-wide and there's plenty of documentation for that just in case you're managing multiple workspaces. Finally, I'll sort of finish with help and troubleshooting. We do have a lot of documentation both in HTML form but also in PyDoc form since West has APIs, you can use the Python interactive interpreter if you're writing your own extensions. Then there's command line help. If you say West help, like I mentioned earlier, that lists everything and that's extension aware. If you're inside your workspace, it'll give you help for build. The second line, unfortunately, I noticed a typo this morning. It's not West command help. It's West help command. So you can see kind of in the inden, it says West help in it, that is correct. It is not West in it help, I'm sorry. That'll be fixed when the slides are finally put online. Then the last thing I'll mention about kind of things to keep in the back of your mind to sort of unwrap and troubleshoot is that any command can be run in verbose mode. So you say West-V for verbose and then you run the command and you give it any other arguments and it'll print out all of the sort of sub-commands, like maybe the git commands for workspace management or maybe all of the cmake commands for building and flashing. So it tries to be really transparent, it tries to get out of your way and it tries to be convenient. So with that, I think I'm all done. Thank you and I'll turn it over, I guess, back to the platform for a video on Bluetooth. Thanks very much. Hello, I'm Martin Woolley from the Bluetooth Special Interest Group, the standards organization behind Bluetooth technology. So I've been invited to give you a 10-minute overview of Bluetooth capabilities and Zepha. And I think the first thing to note is that Bluetooth is no longer a single thing, there are two distinct Bluetooth radio communications technologies. The first is called Bluetooth BR-EDR and that's the original Bluetooth from 21 or so years ago. And then there's Bluetooth Low Energy, which is newer. Bluetooth BR-EDR allows you to create point-to-point connections between devices for the purposes of exchanging data. It's a cable replacement technology, really. Bluetooth Low Energy, though, is much more versatile and more power efficient. Yes, you can have those point-to-point connections, but you can also broadcast data, which means any number of devices that are in range can receive data that you're broadcasting. And you can create mesh networks using Bluetooth Mesh, a distinct technology in its own right. And Bluetooth Mesh lets you create networks with up to 32,767 devices and it's designed for things like smart buildings where things like automation and monitoring and control of building systems is really important. But that's not all it's for. Now the stack itself isn't one thing either, it's quite modular and many of the features are now optional. There's always a controller part and a host, so architecturally those are the two main building block blocks and they talk to each other via a standard interface. The stack configuration you're seeing on screen is that which you'd probably find on smartphones and all sorts of other peripheral devices. This is for non-mesh networking. Mesh looks completely different, though. It uses the same Bluetooth Low Energy controller at the bottom, but the host has a whole new set of layers specifically for Mesh networking. Let's have a look at Zephyr then and find out what support for Bluetooth we have. Well, BREDR is incomplete and its status is deemed experimental. Probably not a lot of demand for Bluetooth BREDR on Zephyr at this stage I would say. The store is completely different for Bluetooth Low Energy though, including for Bluetooth Mesh. Bluetooth SIG qualifications exist at specific versions for host and controller for various purposes, and if you're unaware, qualifications are the formal certifications that products must have in their use of Bluetooth, so if you're developing commercial products with Bluetooth then you must have a look at this. That modularity extends to the Zephyr SDK as well, so project properties allow you to select the features that you're going to be using, and obviously this helps keep your code nice and lean. So here on screen I'm showing you the properties that I've set up for a Bluetooth Mesh using device. So I've enabled Bluetooth under the hood the controller is using, connectionless communication, all the observer and broadcaster roles as they're known. I've enabled Bluetooth Mesh itself, and I've indicated that two special roles that nodes can play, that of the relay and the proxy are not required here. Pretty straightforward, but configuration actually does quite a lot of work for you. Here's an example of a gap peripheral where again I've enabled Bluetooth I've enabled SMP, that's the security manager protocol because I'm using pairing I've said it's a peripheral and amongst other things I've enabled elliptic curve cryptography support because I want to use the best security which is provided by LE secure connections. And here's a device that acts as a gap central, so all it does is scan and connect to other devices and there wasn't much I needed to do in the configuration. Let's have a look at some code, not an extensive review because I'm very short of time but I want to give you just a flavour of what code looks like when using Bluetooth on Zephyr. So this is for peripheral devices which typically need to start out by advertising so I'm creating the content and structure of the advertising packets largely using macros, a lot of great macros for use with Bluetooth on Zephyr and then I'm making a single function call to start the advertising process. Defining gap services and characteristics is something you'll very commonly need to do you can see I've defined a UUID there, I'm not showing all my codes here did that using a macro once again then I'm defining my service in terms of the service and its UUID and the characteristics that it contains and there I've specified the UUID for each of the characteristics what capabilities they have in terms of operations supported and I've provided references to functions for handling operations on those characteristics and I've specified permissions all in one go, largely taking advantage of macros once again then I create the gap services self there's a type there, BTGatService and then I register it. So in a few lines of code I can quite quickly define a Bluetooth gap service and its characteristics and handler functions security also is very straightforward to use, you need to know what you want of course, Bluetooth Low Energy leaves it up to you to decide what your security requirements are and gives you basically a toolbox here what I'm doing is establishing the use of LE Secure Connections for PERI with pass key authentication which gives me money in the middle of protection so I have a structure there that defines some callback functions which I then register that's for use during the kind of execution of the pairing process and I then select the type of security you want on a PER connection basis and the constant that BT Security FIPS gives me level 4 security that uses LE Secure Connections FIPS stands for Federal Information Processing Standards in case you were wondering and that standard requires you to use LE Secure Connections I guess that's where the name came from when developing the code for mesh devices you tend to be concerned with three things in particular from bluetooth perspective mesh devices or nodes as they're known have a structure they have a number of addressable parts called elements and each element implements a number of standardised kind of behaviourable capabilities that are called models so your code will declare that structure and provide references to functions that will handle message types that are associated with those models so code probably looks something like this again extensive use of macros there to define an array of the models supported and then in this case I have a single element or addressable part for my nodes and then you bring everything together with BT Mesh Comp which is the whole code composition sending and receiving messages is very straightforward I haven't shown it here but you've got network buffer APIs for formulating and kind of extracting data from messages that you receive so here's a video of a demo I created using Zephyr with 16 separate nodes each of which is a Nordic thingy it so happens has an NRF 52 module inside it so it's running in Zephyr I've implemented a couple of models that let me turn LEDs on and off and change their colour I've got an Android application using one of the nodes as a proxy to talk to the network we use publish and subscribe approach to addressing the different nodes have subscribed to different addresses so I can control subsets of them so there I've sent a message that turns on all of the LEDs in the grid and then another one to turn them all off now I'm sending different message types to change the colour again all to the same address for all of the nodes in my grid and now I've changed the destination address so that only some of the nodes are responding so at the Bluetooth special interest group we have quite a nice collection of educational resources for developers and a lot of them feature Zephyr they all cover some aspect of the theory of a given topic they also have hands on work in the form of course projects so the ones I've picked on screen here are the main ones the one on the left the introduction to Bluetooth low energy development is really for non mesh Bluetooth devices covers all sorts of aspects of that really cool, good fun to work with as well actually the mesh networking one is of course for embedded software engineers who want to develop Bluetooth mesh devices and the Bluetooth mesh proxy function is also associated with mesh but it looks at how you can create applications for smartphones and for web applications that can interact with a Bluetooth mesh network using something called the proxy function and then over on the right we've got the Bluetooth LE security study guide which will tell you everything about Bluetooth LE security it features what those features are for and how they work but also illustrates what's involved in using them in code using Zephyr once again so I hope that's been a useful overview please take a visit to bluetooth.com and have a look at those study guides if you want to know more I think this time now for a few questions thank you there we go actually the questions will be at the end after a couple of us present my name is David Brown and I'm going to spend a few minutes giving kind of an introduction to the Zephyr project and the focus that we have on security in the project we did as mentioned as John mentioned toward the beginning we have had a focus on security from the beginning of the project we'll also get into Kate will cover safety following this presentation and I just wanted to start by covering what we've done so far in terms of safety or in terms of security the charter for the project has a security subcommittee which initially consists of the certain levels of members of the project get a seat on this committee and there's two elected roles there's the security architect who is responsible for overall project security that currently is me and there is a chair who is also elected and is responsible for running the security subcommittee we have meetings every other week and we go over quite a few things during those meetings and I'll get into some of that so we get further along in the presentation here so some of the things as the security subcommittee that we've accomplished we have what's called the common infrastructure initiative gold status and there'll be more after that in a minute this is a set of best practices that we've worked to achieve within the project we have registered as a CNA which is coming up a little bit but that's the CVE database is a common vulnerabilities and exploits keeps track of vulnerabilities that are discovered in projects whether open source or not and this notion of a numbering authority as this database grew it became overwhelming for a single organization to manage assigning numbers and tracking the data in them and so the Zephyr project has registered a numbering authority ourselves we are able to just assign numbers when vulnerabilities come in and I'll get more into this with our process in a few minutes we've also started documenting the project security goals our vulnerability process so when somebody says oh I found a bug in Zephyr what do I do we have documentation on the website that tells you well what do you do and just one specific thing that I'd like to point out we did put some work into the randomness and the entropy subsystem and one of the members of the security subcommittee put some efforts and some changes into the code to improve this to make it easier to use correctly entropy is one of those things where it's really easy to be completely wrong and it looks like it works just fine because predictable numbers work too they're just predictable and don't give you the properties that you would like so back to this core infrastructure initiative best practices program and hopefully these links will work when the slides go out if not google will find them and so what this project does is it awards badges based on a project's commitment to security and it's mostly about the project infrastructure not as much about the code itself the project hosting how the processes work are they following best security practices and we achieved according to their list of qualifications gold status in February 2019 and this just gives us a little badge and it basically shows that yeah we care about security and the the Linux kernel recently achieved gold status as well that's probably also something you've seen in the news so as far as the documentation goes that we've developed there's a link there to their project security overview we started with mostly documents from other projects what have other projects learned about security how do you tell developers how to write secure code how do you start with a secure mindset and the idea is it's built around secure development secure design as well as security certification you may be familiar with things such as FIPS 140-2 or 140-3 other types of security standards and our goal here is to Zephyr itself may not be something that can be certified because they generally tend to certify products not an open source project but what can we do as a project to get them as close as possible and there may be things like pre-certification things that we're investigating and this whole process of documentation security is an ongoing process it's not we just check this off we're finished we're done but as an example we've decided we need to put some effort into reorganizing the documentation to make it easier to find the things that how do I report a bug should get its own top level page this kind of thing so it's definitely an ongoing process so recently made the news that the group called the NCC group sent us a vulnerability report a couple of months ago and in this were 20 some odd security vulnerabilities that they had found through analysis of the Zephyr code tree and what this brought out to us is that it really showed us that we need to document what do we do when we get vulnerabilities up until that point we had received them occasionally one at a time and now we have 20 some so what do we do so in the process of going through this I we also updated the documentation so that additional members can volunteer to be on this team of people triaging these issues just a summary of you know what kind of things are in the process there's a notion of an embargo period when you report a vulnerability to the Zephyr project what happens we don't just publish it we want to give people who are building products with Zephyr an opportunity to fix them one thing we've noticed that's a little different than maybe a product oriented where in many projects you're building the end product and that's what gets shipped to customers and the vulnerability directly affects what you build in the case of Zephyr we're presenting a source tree that then others are building a product with so we needed a bit different of an embargo period we came up with this approach of the project having one period of time and then this is shared with certain member certain people who are then able to have a period of time that they can incorporate fixes before the vulnerabilities are published and part of this is there's various stages the issues go through we have a Jira system that tracks the security vulnerabilities that allows us to have permissions to make them not generally viewable until they've become public working with the maintainers so we get a vulnerability report that offers a large enough project that there's no individual that knows about every subsystem so we have to find who is responsible for this particular piece of code and have them come up with a fix for it and then finally when the embargo ends it needs to be disclosed at the end and get to that just a little bit with the next slide so there's something known as a insert the product security incident reporting team or project security I think is how we're using it since we aren't making a product and this is a subset of the security subcommittee so anyone each member company gets a seat as on the security subcommittee and then of that a subset essentially volunteer to be part of this response team and what the response team does is these are the people that respond to vulnerability reports that are sending them out to maintainers to get things fixed reporting them to vendors that are building projects so part of that is this notion of a numbering authority I mentioned before that there's a large database it's maintained by MITRE of these common vulnerabilities and exposures you've probably seen these numbers it's a CVE 4 digit year number that increases and essentially it's a complicated system for allocating integers but we get blocks of numbers that we're allowed to then use and then over time we have to either publish these or reject them request new numbers for different years we've already gone through two allocations thanks to that report so far this year in 2020 so this registers us with MITRE and now we issue our own CVEs since we get a CVE and I go to a little table and I just pick the next one off of it and that's the number that goes with that issue significantly you don't just ask for this there's a bunch of documentation and process requirements that MITRE has to make sure that you're actually doing the right thing as part of this so just a little bit of detail there's a link to the report here there were around 26 issues all but one of which directly applied to the Zephyr project the other issue was to the bootloader that Marti mentioned is one of the modules that's there what we decided to do is to take the critical high and medium and we made these into tickets and for the most part well actually all of these have been fixed we have pull requests that have gone into various releases and this is all tracked and there's a set of release notes that describe each of the vulnerabilities and where you can find the fix what version it was fixed in if you have an old version that it isn't fixed where to get the patch to pull in and the embargo for this has now passed and everything is updated in the vulnerability report page on the Zephyr documentation so most of these resulted in one or more CVEs being reported there's kind of some fun with the CVE rules essentially the report has multiple patches that could be independently applied they need to get separate CVE reports so there's a couple of the reported vulnerabilities that resulted in more than one and then there were a couple of them that didn't result in a CVE at all one example was the bug was introduced and then fixed before there was a release so there was no release version that had the vulnerable code in it so there's nothing to notify anyone about for that so for the most part the issues were fixed in a reasonable time frame we sent these out people were quite interested in fixing them sometimes the security subcommittee submitted the initial fix we did have one issue where a fix did not come forward very quickly and we basically recommend in the CVE that this feature should just be disabled another thing as I mentioned before since the Zephyr doesn't produce a product we need additional time for this embargo process so it initially was set to 60 days and we had a proposal with the board to move that to 90 days to give basically 30 days for the Zephyr project to fix it and then another 60 days for people who are building products out of Zephyr and sometimes there's another party in between there that may be taking Zephyr building something that then someone else builds a product with and through all of this everyone needs extra time before we publish and tell everyone about the vulnerabilities and this is a process that we hope to continue to improve turns out there's a lot of little pieces that are involved with things that expire embargo and you have to track pull requests it's just lots of little pieces and just lastly we also kind of concluded that there's a need for what we call a vulnerability alert system and what that comes down to is for the embargo to work you can't just hide the problem from everyone or there's not really much point in having an embargo there's parties that need to be notified early and so what this means is when a vulnerability comes in we create this internal issue and we have to have some subset of people some individuals that get notified about the vulnerability with some level of detail enough to know that they need to hear some patches you need to apply before this is all made public so we created this vulnerability registry this is initially seated with the members of the Zephyr project but it's an open source open governance project there's you're not required to be a member in order to build products with Zephyr and we wanted a way to for these people who are building products to be able to register and what will happen is information about the vulnerability will come in email and get sent out to this mailing list that covers these people that have registered and again I say the goal is to fix issues within 30 days and give vendors 60 days before publication of the vulnerability so that's pretty much the topic I had for the Zephyr security overview coming up next will be Kate Stewart who's going to give us a little presentation on safety certification in Zephyr thank you hey thank you I'd like to talk a little bit today about the safety certification what we're doing there and one of the things I'm going to ask people is if you've got questions there's a Q&A in this interface and so if you want to type your questions in we'll get back to them all at the end we've reserved time at the end of this for all the speakers to get together and work with answer the questions as they've come in so if you can queue them up right now that's going to be really helpful for us so when we start Zephyr off this slide was pretty much intact we knew we needed to basically be able to work with the development community and let features come in quickly and be able to be responsive and add new functionality and features but we also knew that we needed to be able to work with the safety certification folk and be able to work through the V model and the necessary evidence and safety manuals and so forth that they're going to need to see to have that evidence in place we pretty much started with 61508 in mind because that one is a good starting point for a variety of other standards in this area so you can go from 61508 to some of the things for automotive and medical and so forth but it was a good starting point when we started thinking about this project however we knew we would need to do some intermediate stages which is something we were calling our long-term stable where we basically ratchet down the development so those 10,000 commits a year you're seeing are happening on development and then every two years we're cutting a long-term stable and then from there we're taking a subset of the functionality and that's what we're taking through safety certification this way we don't disincentivize the community and we can make sure we have the processes coming in in an effective way so that's kind of what's been happening in a nutshell our long-term stable we actually cut our first one last year and we've been using it not so much for safety at this point yet but we have been using it for going after Bluetooth certifications as well as keeping it up to date with any security fixes so this is where if you wanted to work with something while we're working with the development tip for a product we'd recommend you to go work with this long-term stable and we're putting all the security fixes into it over time and it is not moving as fast as the interfaces are on the development or new developments happening and to sort of illustrate this this is where we're keeping it up to date so our long-term stable number one which was tagged from the 114 release we've already put out two other releases since then and if you go to the links you can sort of go look in our repos you can see that we have the CBEs listed in the release notes as well as any of the other fixes that have been added into each release so it's a way of being able to work with what we've got and not having quite the same pace of change but you're still up to date on the security and you can make sure if we find bug fixes we're putting them in there too now the auditable branch what we're going to be doing with that is we're just going to be taking a subset of what's in the LTS branch it's the modules that are going to be there that we're going to be taking through and working through some of the interfaces in that diagram at the start that John showed we have a large amount of components in there and in the stacks and it's just going to be a subset we're going to be working from initially and then over time we're going to be building it up the actual criteria and certifications we're going after is was initially agreed to be 601508 and then as time progresses we'll probably be going after others but that's going to get agreed to with the board and with the various committees to make sure that we're all in line as we considered were 601508 but along the way we're going to be working on moving the code base right now this year over to be Misra C122012 compliant so we're busy working with some of the tools that are out there to make sure that the guidelines for our code I'll follow it and we can do the testing and making sure we get ourselves literally lined up with it there's some other things we've been looking at but if you want to get more details what we've got some of the stuff has been documented in the TSC minutes and the coding guidelines are being published for the project right now and you'll be seeing the code base transform over to be fully compliant with those guidelines or else all deviations being noted after that we have a lot of evidence to start assembling for going after the 601508 so to do all this work there's actually a safety committee that meets every two weeks and we started the safety committee off now in last year and we are doing these best practices we've been focusing on that and then we're also looking at making sure that the code base doesn't regress so the changes we're making we're making the development tree and we're going to be keeping it going from there so the key for us is going to be preventing regressions from happening over time we have weekly severity scans going on we have the middle of scans being incorporated and we're looking at various open source tools to help us with the static analysis all of which is good for the security perspective as well but what we're going to be trying to do is making sure we have this hard to code base as we can and this is pretty much because quality has got to be your own mandated expectation for this we were lucky with this effort project and that everyone knew going into this project that we were going to be focusing on safety and security certifications as a goal and so other projects that have been out there for a long time are not likely to be able to feel like changing a lot of their interfaces and changing it the way the developers behave because they've gotten used to that we are very fortunate that we have a community of developers that is understanding that this is a goal and is lining up behind it and so we'll be working our way through this over the next quarter and we already have fairly good quality on this on the code base as you can see by the fact that we're considering good enough for people to start looking into any investigations on from like the NCC group and others so we've got some academics studying as we found various researchers have found issues and helped us fix them so we certainly welcome anyone who can help us harden this code base up it's very much appreciated and we'll say thank you this slide shows our initial focus, these are the modules the groups agreed to to do the first minimum viable config that we'll be using in a device for going after the 61508 certifications and creating the artifacts associated with it and as time goes on we're looking at other scopes of increasing it to different of these modules like the POSIX API is something that we've had requests to basically start to incorporate into that and so as we move through this next year influence the traceability matrices in place and the testing matrices in place we'll be basically looking at adding those into and as we get the first set scope done then we'll look at figuring out okay what are the next ones we can incorporate the same methodologies to and make the same evidence available because with Zephyr we have a whole variety of configurations we're going to need to handle from single core MCUs to PMP support with hypervisors with meshes there's a lot of different configurations out there that people are going to potentially make sure can be used safely in applications and we're going to be having to consider all that and keeping the scope narrow and small and being able to extend out over time is our approach to trying to make it something that we can get results and be useful so the oops our roadmap is we're going to be looking at finishing off the code transitions over to the MISRA compliance this year and one of our members is looking at doing some work versions that are on place right now with some of these certifications and we'll be taking and pulling this in to for next year in 2021 will be with the next LTS we're going to be trying to be ready for taking the evidence available so that's kind of what we're doing with Zephyr and the safety space right now and I think with that I'd like to introduce the next speaker, Michael who can tell you a bit more about some of the interesting things that are happening in Zephyr Yes, hello everyone I'm Michael, I'm coming from Antmicro one of the Zephyr project members and I'll be telling you about how to develop machine learning in MCU with and without hardware and about the marriage between TensorFlow Lite and Zephyr a little bit of introduction to TinyML and TensorFlow Lite so basically TinyML is it's even a book right but it's a term to or a name for a community of people that do machine learning in very small footprints there's a prediction that machine learning will be prevalent it'll be used in all sorts of devices not just like Linux capable devices but also things very much smaller they might or might not have a battery and of course the size and complexity of the device that will run this machine learning will limit its capabilities but there's a claim that the capabilities are pretty good even for MCUs you can do gesture recognition detection, people counting all sorts of very interesting and useful things that can pre-qualify your data increase your security anonymity of the data just because you're processing the data closer to their source and you don't have to push the data up and up and up in the stack you can kind of keep them where they're being gathered so generally speaking doing machine learning in small devices in the processing field rapidly developing and TensorFlow Lite you might know from other places mostly probably from mobile phones it's a very popular machine learning framework from Google it's used at the edge but it also now has an MCU version it's called TensorFlow Lite from Microcontrollers it's been extended to that use case by a team at Google with Pete Warden at the helm of course it's no longer a project, it's actually a very collaborative entity collaborators include Harvard ARM, our company and a bunch of other people who attend our monthly meetings I encourage you to join those meetings, they're very open we have public notes and we have many people collaborating and sharing very good results so if you look at how Zephyr kind of is up against TensorFlow Lite and why would you want to run those two in tandem if you can see some similarities between what TFL and Zephyr are trying to achieve so TensorFlow Lite is not a vendor driven library it's actually vendor neutral it targets many devices and many architectures even so it can do ARM, RISC 5 ARC a few different architectures so does Zephyr of course as we've been told just in a few presentations before and so if you want to do this machine learning applications in this small footprint you'll probably churning through a lot of data and that data comes from sensors and those sensors need to be accessed in some way and to do that you need drivers, you need APIs, you need libraries so you might guess that Zephyr is a good match because as an artist that's vendor neutral and driven by the Linux Foundation it's really good at handling small MCUs and giving you consistent access to different kinds of hardware so Zephyr with its goal to span across all architectures and be really vendor neutral is an excellent match for TensorFlow Lite because it kind of strives to do the same thing both have a vibrant developer community I mean Zephyr of course has a bigger one so for TensorFlow Lite it's kind of a great opportunity to grow its user base but I believe for Zephyr it's also an opportunity to kind of address very very interesting and hot new use cases and kind of showcase how Zephyr can be used to bring machine learning to even the smallest of devices so in total I think it's a very good combination and our work with Zephyr and TensorFlow Lite actually began in 2018 so it's been quite a long while initially we just started by helping the Google team the TensorFlow Lite team to run TensorFlow Lite in simulation on our open source simulation framework on the ARM architecture because they wanted to do testing without hardware and then we decided that hey this is a great framework let's try to port it to RISC 5 because Micro loves RISC 5 and does a lot of things related to that and we presented that work at the RISC 5 summit in 2018 very late 2018 together with Google then the year 2019 brought like an integration a full-blown integration project between Zephyr and TensorFlow Lite on RISC 5 in an FPGA platform so we did that work the work I'm telling you about today mostly in the late 2019 only that it took a while to upstream all this effort both into Zephyr and then into TensorFlow Lite both of those projects have communities they have their own processes they have a pull request flow to go through so it took a while to get there but finally we're there and we can say that TensorFlow Lite has upstream support for Zephyr or vice versa I don't know which one is closer to the truth so basically this work and results in a very cool blog note that we published on the TensorFlow Lite blog it got picked up by of course a number of outlets and generated quite a lot of enthusiasm we're planning to have academic courses with that content in the fall one of the notable entities that reached out to Harvard will see if we can make that happen but in general there's a lot of people picking up renotes because of that Zephyr and TensorFlow Lite as well together in a pack so to say it's a good match because a lot of people are spending their time trying to tinker with different kinds of machine learning activities that don't require extreme resources they can do so without hardware so I'll tell you about how it works in a second and currently we're actually working on quite a lot of new things as well so we're going to be adding more sensors and more examples like audio detection as well as improving TensorFlow Lite to be better tested in continuous integration using renotes so I've been mentioning renotes quite a bit and just wanted to give you a bit of background about that it is a framework for simulating small systems well not only small systems actually some of the systems we've simulated are big too but many of the platforms that we incorporate into renotes are actually Zephyr capable and run Zephyr by default and some people have been saying things like hey renotes looks like docker for embedded devices or it's a simulator on steroids so both are kind of good approximations of what you can think about renotes because it enables you this kind of streamlined approach to hardware it enables you to work without the hardware for prototyping you can also kind of do continuous integration because if you take hardware out of the equation you get much more capabilities to reproduce your results or build deterministic flows it's a good match to something like TensorFlow Lite because this library changes a lot like machine learning is all about experimenting and developing fast so if you want to test what you do you need something robust that the important thing to know is that we simulate not just the CPU we simulate sensors connectivity there's full blown use cases that you can put into reno and run them and see what happens so you can have one sensor reading data from one end communicate wirelessly to another one and then the other one does some processing so you can build complex systems I think that's kind of what's important to understand and of course again with respect to the vendor neutrality we have support for ARM RISC-5 per PC which has recently been added that's another open source ISA out there so we're pretty excited about that too and x86 if you need that so the complete list of supported boards is in the link in this presentation the important thing to know is that this is an open source framework and it comes with demos for all those platforms that are compiled binaries just so that they can get started very easily and quickly so it's a Swiss Army knife of simulation just go to reno.io and take a look and the most important thing that you'll eventually arrive at while using reno is that you'll see it doesn't only reinforce your local flow it really helps to have a simulator in the local flow when you're just trying to experiment and see what's going on looking at the platform in detail simulation can give you lots of information what's happening between hardware and software especially if things go wrong but as you go towards a more company-wide deployment scenario or continuous integration scenario that's when reno becomes really interesting because you can put it on a server, you can run whole suites of tests, you know randomize those tests and so on and then another kind of disinfrastructure will allow you to kind of work together in a team more effectively that's what we're really aiming for that's the kind of features we're enabling as a priority so that you can kind of seamlessly transition between your local development environment the cloud some kind of local server because it's all abstract right so you don't need to like connect the board or 100 boards to a server it all runs virtually and the platform that we use for that particular effort is Digilent RT-A7 dev board, it's a low-cost FPGA dev board with a small FPGA on it we run a soft system on chip with the risk-flight architecture inside of it that work was kind of sponsored by a Google team that was very much into FPGA so that was a natural choice for us and we added an accelerometer on a module, it's called PMOD-ACL and this accelerometer is used to detect gestures basically and the interesting thing about it being an FPGAs that FPGAs enable you to accelerate machine learning inside hardware you can dynamically kind of reconfigure the hardware to provide some kind of machine learning optimization so this is a kind of very interesting field of research that we're also involved with and what I need to add also in the reload context is that since you can co-simulate FPGAs in ReNode that will kind of allow you to simulate this entire platform, not just the hard part not just the CPU part but also the machine learning accelerator should you develop one, you'll be able to just co-simulate between ReNode and for example Verlator which is also an open source simulator but of HDL code, of FPGA code so in total you have a very good platform for developing these kind of things if you run this demo, I mean you can run it in a self-contained repository, you don't need to do much really you can just clone the demo as portrayed on the screen and execute this and you'll just see everything fly by and eventually you'll see kind of ReNode running those mainliners there's a couple of interesting features demonstrated first of all, we're actually kind of adding device models on the fly into ReNode in this scenario so instead of kind of implementing those specific models in mainline ReNode we just kind of added them into that repo and they're compiled on the fly so you can kind of add stuff into ReNode without recompiling the framework of course you can also put the model back into the framework that we're going to do in the future we're also injecting fake data into virtual sensors from files so that's kind of a pretty neat thing if you need to do different kinds of scenarios different kinds of perhaps randomized sensor data for testing your machine learning algorithm we can do that, you just need some files with the data, they are also provided in this repository and then we're also running a robot test, robot is a python based testing framework and then we can use it to execute ReNode as a scripted framework and just get results and see if your tests passed so we define a bunch of tests that we wanted to pass and we hope they do and all of that is wrapped into a CI in Travis which kind of runs those robot tests so you can see how it's built you can see how you can use ReNode for continuous degradation if you really strap for time like myself you can actually just grab this and you don't even need to compile the binary, you don't need to wait there's a pre-compiled binary in the repository but of course you're encouraged to go ahead and compile your own and change it and see what happens it is just for convenience so yeah, the results are going to be circles and lines on your screen those kind of ASCII symbols represent and of course this is a virtual circle so this is kind of the data that we injected into ReNode to pretend that we're waving the board around and showing it a circle of course the same firmware, the important things to understand is the same firmware if you actually put it on the FPGA if you happen to buy that FPGA or have it at home plug in this Pmod that's also an off-the-shelf component and run that binary on the FPGA this will also work right so you'll wave that board around and and here on the right I have a little screen showing kind of what the CI looks like but you can go ahead and check it out yourself going forward we're of course adding more platforms like we're seeing what the overlap is between TensorFlow Lite and Zephyr and ReNode and trying to kind of make them all work this one for example is added by ARM themselves so that was pretty cool they kind of issued a poor request to enable running in ReNode we're working on more for the course in the fall that I just described and other scenarios so look out for kind of us adding more just as a side note if you're really interested in developing machine learning on MCUs which is a very exciting field we're adding some performance analysis tools and capabilities into ReNode so you will be able to measure executed instructions and all sorts of other metrics inside ReNode while you're running your algorithm and you'll be able to see comparatively whether you're getting better or worse so that's a very important aspect for continuous integration so that you don't just lose track of what's important and my last slide is a summary so basically now TensorFlow Lite and Zephyr are integrated so they can play nice and can be integrated we're working to build other things on top of what we've already done as I mentioned there's some audio-related samples we're enabling and generally speaking we want to popularize this tiny ML this edge ML in the Zephyr world and try to get more people to do that hopefully I kind of managed to convince you that ReNode can be useful to kind of accelerate the development in that field and so if you want to talk about it you can always come to us and talk to us and we're very happy to hear about your use case, we're going to also discuss it we're going to discuss it with the TensorFlow Lite team and see how we can enable more interesting scenarios related to machine learning in a very small footprint so that concludes my presentation we'll now move to the Q&A session which I believe is this slide so we have everyone going online so listen just before we start with the Q&A I want to say a very big thank you to all members who've stepped up today to present it's always a significant commitment and I never thought I would say this but virtual platforms are a lot more complicated than real life that's my commentary so far so I've actually got a couple of questions and I'm hoping to get some help with the online one that's the complexity in my eyes I wanted to come to Kate first, Kate could you maybe talk to who is on the safety committee how do folks get involved, what's the safety committee doing, who's involved sure so the safety committee is led by Amber Hibbard from Intel and we meet every two weeks and so if the safety committee like the security committee is open to members if you've got a really strong case for why please reach out to me or to Amber and we can talk about it but it's open to members and we pretty much go through what we're doing for the next steps in there and that's where the strategy discussions are happening for it we have various other members putting in a thanks no that's super the way that the Zephyr project is pretty much structured from a board perspective committees get created it's not an ad hoc process when there is a specialist area a focused area like safety, like security then marketing as well but these boards, these committees are created and it's yet another way of contributing to the project I wanted to follow up with Michael and maybe I just missed it when you were talking Michael, but why Zephyr? You guys have had a ton of experience and a ton of platforms over the time why Zephyr? An easy question to start you off, but why Zephyr? That's a really cool question so I can give you a story about how we used eCost for quite a long while we started in 2009 so at that time there was a bunch of different options but the open source artist landscape wasn't what it is today to choose something that ticked off all the boxes, you always had to compromise and eCost was an operating system but still is an operating system that at that point seemed like a good choice because it ticked off those boxes of POSIX compliance and standardization and being used across lots of different scenarios because it addresses both small and big devices you could scale it up it had a nice configuration framework to kind of trim it down or build it up we used it for quite a long while and of course we used other systems when people asked we worked with a lot of open source solutions throughout the years free artists and so on but eCost kind of always was frustrating in terms of liveliness and community there wasn't anything really happening besides what we were doing and a bunch of other guys and part of it is because it was controlled by a single entity there still is an eCost-centric company that wants to sell you a pro version of it so it's always this situation where there's this problem of vendor neutrality that creeps in so when we saw a Zephyr in its early days being established and kind of donated from Intel and Wind River and kind of established as a really kind of vendor neutral community-centric operating system and kind of addressing all of those issues that we had had where we needed something that would be like post-exempliant and targeting various use cases etc etc etc we decided okay Zephyr is the thing we need to join that, we need to support this so it proved to be a great choice there's a few other interesting choices out there as well and they're great things but only Zephyr kind of achieves all of those things at the same time including the community aspect of it Good answer and I just want to say for everyone who's listening to the Q&A nobody got these questions in advance so thank you Michael it's really good to get more of a user perspective we're sitting on the project that's one view but you're outside seeing the big wide world so when you make a choice that has to be an active choice and I should have said I really want to get added to our board slide that was my one take away from listening to you earlier Kate we had a question in there about Zen are you considering certified configuration using Zen can you give me an opinion on that one I think there is I'd say yes there's been discussions about it I think we're going to need to work with the Zen community a bit more I'm actually putting on the Zen safety community as well and I think that over time I'm expecting that we will probably do something in that direction it's a question of who wants to be there and participating more I just think with that participation volunteer word comes up a lot but it's good let's keep this going I know there's like I say I've talked to several that are interested it's just a question of okay how do we make it happen no the that is a good answer and again how do we make it happen that's super I'm going to go to David David we had a question here about Zephyr support for TE do you take that sure thing and I'm assuming that this is trusted execution environment and it's not clear from the question whether you mean something specific like global platform or just the general concept of a trusted execution environment because at least the current global platform spec kind of requires a little bit more out of systems than what Zephyr targets are usually focused at so what I do know there is support in progress for Zephyr working with the trusted firmware M project which is kind of basically the equivalent of that for the Cortex I know there's a little bit of other efforts as far as supporting other kinds of trusted environments on other platforms but unfortunately I'm not familiar enough to really be able to answer the question I guess the simple answer to the question is there is some support in there there's work definitely work being done on that I can fill in a little bit at least in the risk file context because there's an effort from from 6 or Rice in Sweden to implement a Keystone enclave in Zephyr which is a trusted execution environment from the risk file world I don't know whether it's actually kind of constrained to just running on risk file I don't know enough about it to say confidently but I know that the effort is very well underway and actually just been asked to review the code and kind of help merge it into Zephyr there's definitely multiple activities of different kind of TEs going on okay I made the same assumption as David excuse me I made the same assumption as David at the start of that question but the okay now in terms of Martin barely certification around Zephyr what is the status barely certification around Zephyr I'm even asking that question to ask me I think probably someone from the Zephyr team would be better able to tell you the status there obviously you guys submit specific releases I guess of Zephyr to go through the certification process you submit your test results and I don't personally manage that rather large list of products that go through that process I'm afraid so I don't know my understanding is that a number of specific versions of Zephyr have been qualified already so I think one of the relatively early ones correct me I can see Kate there she's going to bail me out here is it 1.4 was it or something is that the first one that achieved kind of broad the qualification process is modular so I think 1.4 is the one I tend to use because that's got broad qualification of the various parts controller and host and including mesh and from what I saw on the web page on the Zephyr site there are a few specific cases that have achieved certification in other versions as well the thing for people to do there who are looking to use Zephyr for a Bluetooth enabled devices is to look at the documentation on the Zephyr website because that will tell you the answer to that question I hope that's why my subject I must confess the excellent I like to be the one that we've gotten the the accusive it's on and so that's sitting in the release notes for 1.141 and 1.14 okay I think you did perfectly well you did perfectly well Martin and Kaye as usual comes to the rescue um do you know it's the purpose and reasoning actually and I apologise for that but the purpose and reasoning is it's this functionality perspective and having the functionality but we got to the end right if somebody's interested they can be a lease application go and check the Zephyr documentation with the exception of the Bluetooth BR-EDR the very old version of Bluetooth everything pretty much you could ever want to do I think you'll find there's a qualified version of Zephyr that supports that so predominantly that's Bluetooth peripheral devices and Bluetooth mesh products you should be able to find a version of Zephyr that supports that support for Bluetooth is really good in Zephyr Martin I never paid you to say that well done that was all you needed to say right at the start right the uh this is a there you go I am going to volunteer basis um Michael I think I know the answer to this but I'm going to I'm going to ask you a question on it does Reno DeLau to integrate emulated network of devices with a real device network we're looking for a way to test a few real devices running Zephyr simulating a larger network of emulated devices yeah it absolutely does yes yes it absolutely does it'll basically one thing you'll lose is determinism because you're connecting the real world to the simulated world and the real world is not deterministic uh so it might be a bit of a challenge in some scenarios also you'll have to kind of make sure that the timing's correct because the real world is expecting things to happen in a specific time frame uh so you know if your simulation is not fast enough then you're going to miss some windows and so on but in general yes we've done that we've connected real nodes with simulated nodes in the past and uh it's absolutely possible it's a kind of a use case that we want to enable to the devils and the details of course we're happy to hear more and kind of you can tell us what you want to do we'll tell you honestly if it's a good idea or not thank you Michael I have I think this one's probably for Marty um just since he thought he was going to escape the um running git log minus s oh no no no running git log minus s reload on the zephyr git repository yields two findings what is hindering a broader adaption actually now you think it's back to Marty that's back to me I know which one you meant with Marty because I saw that question in your hand and that's a good one but it's the same like people could ask why did you develop reno in the first place which would be an hour long story so fortunately I didn't get that question the other one is easier to answer so why is reno not kind of integrated tightly into the zephyr repository I guess the only reason is just time and maintenance effort reno doesn't simulate it so you can run any software in it you can run zephyr but so on anything else bare metal or other operating systems so kind of you could argue that integrating it into zephyr in this way wouldn't necessarily be such a good idea given the fact of course that zephyr does come with its own testing infrastructure and so on I actually think it would be a good idea we just need to do it we just need to kind of get back to that topic because we did do that at one point to some extent then you know the zephyr testing group kind of disintegrated and appeared again surfaced again but at that time we were just too busy with other things and we didn't kind of join the regular meetings we have to do it again and talk about reno there so long story short no time but in general there are external integrations between reno and zephyr for example platform IO has done a really good job just kind of putting reno and zephyr together in their own kind of build framework whatever you call it so that you can grab zephyr and then simulate that in reno assuming there is support for the platform thank you very much Michael yes I started reading that and then I realised I was changing tracks I think this might be coming I didn't see this question is it possible to run zephyr with TensorFlow on a KL46Z MCU Michael off top of your head I have another specific question do you happen to know let me see the question yes I am actually going to see who is online probably not but I can double check of course for you also there might be some work in progress I am not aware of yeah I think that is highly possible well listen I want to just go very quickly around the panel we have about 6 minutes left and so I am giving you a fair warning panel I would just like you to give me what is your personal next steps with zephyr what is your group doing what purpose are you doing David you are the first in order this is not alphabetical this is by screenshot David when you go back to work in zephyr when you go back to work with the security committee what is the next steps for you fun question part of it I think the next thing I am going to do is update the documentation for some of the things that we recently discussed within the security team to make our documentation look a little bit better an unrelated task that I am going to look into that I just thought of while some of the west presentation was happening is I am going to look at what it takes to build an application in rust on top of zephyr not really related to the security team but sort of goodness you see what happens when you ask people on the spot right that is when the interesting stuff starts to come out if you don't mind me saying so David thank you very much now I am going diagonal Marty when you go back to zephyr what are you doing one of the things that I just wrapped up for zephyr is that I was helping out with the new device tree api so zephyr uses device tree for hardware description and we made a bunch of changes from 2.2 to 2.3 there is a new api which is hopefully going to be stable from now on and at my company we use zephyr as the basis for our SDK so there is a big move from kconfig to device tree that I am going to be working on as a follow up we think that is an extremely good thing to do as well so thank you very much Kate you just get too many things to do but could you pick one or two of your fives right actually the one that just occurred to me as we were listening to Marty talk is you have a manifest flow for west and I think I want to see if we can work on turning that into an automatically generated software build materials because I think we are actually pretty close so you may be seeing me in your inbox a bit because we are going to need to have accurate descriptions of all the components and the options and so forth from the safety perspective so let's see if we can start getting that one knocked out now come here yeah you heard it here first that was Marty Marty got so surprised he almost put his microphone back down but then he thought you better know ok now Martin I am coming to you but I am leaving you to the end right ok so you get preparation time here ok so Michael what's next for Renoad and Micro and Zephyr what's next I think a tighter integration in Zephyr I have to say that because you know the question that wasn't the Q&A yes you do well you know what we are big fans of what you guys do so but if I may say one broader thing that I didn't prefer to do we are kind of working a lot with open source ASIC design and this kind of stuff so what I am hoping for is to get Zephyr running on a fully open source chip in the nearest future and we have done a system and package design late last year that of course runs Zephyr because what else but I would love to do like a full end to end open source chip and run Zephyr on it wow you know what I do have such a foot in both camps in terms of open source software when I hear you say the word risk 5 it makes me all per cup and then when I hear the word Zephyr it's just a natural pairing I look forward to it and last but certainly not least Martin what technical thing are you looking forward to doing in Zephyr next I am looking forward to seeing what newer Bluetooth features emerge in Zephyr in particular some of the features from Bluetooth 5.2 which was released early this year Isochronous channels is a fascinating capability the new version has and on top of that the new Bluetooth low energy based audio technology which we announced earlier this year it's not really been fully released yet but with Isochronous channels in Zephyr you set the scene for a whole generation of wireless audio products with all sorts of new capabilities that Bluetooth today doesn't have in the world of audio audio sharing audio in conferences, cinemas multi-content streaming different languages simultaneously all sorts of amazing things all built on this Isochronous channels capability with a new codec so I don't know if anyone's working on that because obviously we're not actually involved in Zephyr at all we're a kind of neutral standards organisation but you know I lie awake at night hoping that this is going to happen so do you know what Martin with the community we've got building I think I can fairly guarantee that someone is working in Zephyr with those extremely extremely neat features but okay well listen I actually do have a prompt here that says that if folks want to move on to Slack channel 2 the track open source project updates anyway thanks to the panel thanks to everyone for listening and we'll see you next time thank you guys bye bye thanks John cheers guys thanks John