 So my name is Anas Nashiv. I will be talking about the Zephyr project and things that we have done in the last year and our plans for the next year. The Zephyr project actually was launched exactly one year ago in Nuremberg, Germany during the Impended World Conference. Launched by the Lynx Foundation as an open source project. So for those of you who don't know what the Zephyr project is, very brief overview of what we are doing and what we are. Small footprint RTOS. When I say small, we actually have boards with 8K of RAM that Zephyr can run on and do some useful stuff. It runs and designed for constraint devices. It's configurable modular, enables applications, application code to scale as much as possible. So it's built around the core functionality, the kernel in this case and based on your application needs you can configure it and scale it for your needs. So it's a truly open source project, a batchy 2 licensed, permissive license in this case, hosted by the Lynx Foundation. Very transparent development, everything happens in the open. All development processes, everything that is related to getting code into the tree, it all goes basically into an open development model. We are cross architecture. ARM x86 arc, that's where we started last year. Nios, it says Neo here, a typo. RISC-V extends, these are architectures that we added over the last year since we launched. So it's been one year and we actually have been really very busy. We have done a lot of things, we accomplished a lot of things, we changed a lot of things since we started. I will be touching on some of these items that we have done in the last year and try basically to establish or give you our thoughts on where we want to go from here. The project has started with three founding members, NXP, Intel, Synopsys. Meanwhile we actually have a few more than that and the momentum is growing, it started with a few developers working on that. Primarily from Intel and the founding members, we have hundreds or even more contributors right now from different companies from the community and so on. So I will give you some more details there, so it has been a very productive year. The first year was all about getting traction from MCU vendors from the community, get some early adopters and keep them, gain community trust and also expand hardware support in terms of boards and architectures. But it was also about creating a solid foundation for innovation and bleeding edge technologies and standards. We didn't really want to look at things and supporting for example hardware that in a few years will not be relevant anymore. So we wanted to focus on the bleeding edge on things that really matter and we wanted to build a foundation for supporting new technologies, new standards without having to reinvent the wheel every time a new standard or a new technology comes along. So the project is looking forward and although we actually started with a kernel that was 20 years old, meanwhile we managed actually to go and change it in a way that it allows innovation and adding features and support for upcoming technologies. So in terms of traction, we have very strong engagement with chip vendors including leading ARM vendors, primarily due to their permissive license but also to the open development model and the governance via the Rings Foundation. I mean we say that in a lot of occasions that our goal is to become the Linux of microcontrollers but that does not mean that we are trying to imitate Linux or try to replicate Linux functionality. Linux is good where it is and you heard Linux this morning but when it comes to microcontrollers, the development model, the governance and how we do things, we want basically ZIFR to be the Linux of microcontrollers and deeply embedded devices where Linux actually does not fit. As we have seen over the last year that the community is actually actively impressing ZIFR. So Linaro has adopted ZIFR and many ARM vendors including ARM itself actually are actively participating on the project. MyNUT founders have also joined the project late last year bringing some of the components or working or trying to collaborate on some of the components that they have already in MyNUT like the bootloader, blogging, statistics, Bluetooth, etc. So there are a lot of synergies there and we will see a lot of things over the next year as well. Nordic semiconductor just joined the project last month. They have been very active in ZIFR working on the BLE controller and they are also looking at ZIFR for other products that they have including 15.4 thread and so on. So looking here you will see basically in terms of activity, obviously we want to see more engagement and more members joining the project especially on the Platinum level. But we can see that we have a lot of traction from major players in this market and when it comes to MCUs. The project as I said earlier started with three architectures, Intel ARM and ARC and we have a few boards actually supporting the three architectures. Over the last year or actually in the summer of 2016 we added support for NEOS, a process which is an FPGA platform from Altera and now owned by Intel as well. Just recently and actually in the release that is supposed to come out end of this month or early next month we added two additional architectures, RISC-5 and Tenselica. This RISC-5 actually was an effort done by one contributor, one single contributor in this case, assisted by a few of our core kernel developers. But I mean the board itself getting something like RISC-5 or even Tenselica in this case has helped Zephyr improve some of the portability layers that we have and also shown that it's easy actually to go and look at Zephyr and port it to any architectures. Probably one year ago that was a little bit difficult and people didn't really invest a lot of time looking at that but now we are getting a lot of interest from other vendors interested in basically moving there or adding support for their architectures as well. So I expect to see more architectures joining the party here and that's all good for Zephyr of course in terms of traction, in terms of board support and having more people use Zephyr in this case. Board support, we started, I mean last year I remember when I was talking when we launched Zephyr we had like a few boards. We had an Intel board, an ARM board or an XP board, Freedom64 and Arduino 101 and a few legacy boards I would call them designed for IoT but not really microcontrollers in the sense like the Galileo for example. That's how we started, since then we have seen a flux of, I mean the increase and the amount of boards being added and submitted or contributed on a weekly basis is really amazing. I don't actually keep track anymore, I used to. These are the boards that I have a picture of and it fits like in a nice way on the slide but we have actually more than that. We have a lot of ARM boards being added by the various ARM vendors, an XP, a micro, TI, ARM. There would be additional boards added based on Intel QRI and Intel Quark platform and we will definitely see more boards coming for the newly introduced architectures like RISC 5 and Tenselica. So in one year I think this is a great achievement and we are trying basically, we learn a lot, every board we add, every SOC we add, every architecture we add, we learn or helps us improve the kernel and Zephyr in many ways. Every SOC is different, every vendor has their own way of doing things. We impress reuse of code so basically currently we integrate some of the drivers coming from vendor SDKs like from NXP or SD. Basically to make adoption a little bit faster and also to reuse some of the code and not go through reinventing the wheel by going and developing drivers from scratch for Zephyr. So some of the platforms you see here or some of the boards you see here are basically supported by SDKs that come from the vendors themselves by adding a very thin layer on top of these drivers to make them work with Zephyr. So just a few slides here showing the development and commits over the lifetime of the project. This is the lifetime basically since last year or 2015 actually when we started working on that internally all the way to where we are right now. You can see where it started with Windriver and Intel like cleaning up code that was there already. I mean it was not written from scratch as I said earlier, it's based on an RTOS that was a product of Windriver. And then you go, you move forward. I don't know why here we don't have a lot of commits. This is probably Christmas or something like that. But when you look over the last year you see basically how things started to change. Intel is still a major contributor but we see a lot of people joining the project, a lot of companies. We have basically this is since September last year and this is like the last release. We have a lot of engagement, a lot of traction with developers contributing code from Linaro, from NXP, from ARM and other community. I mean here you have unknown. A lot of people are just submitting code using aliases because they are not ready to reveal who they are or because they are just wanting to contribute something to an open source project. So it's going really well. I mean try looking at the contributors and the members and active developers. It has grown from tens or probably ten developers called developers to over 100 right now from different vendors and different backgrounds. So this is basically what we had over the last year. So looking forward, the Zephyr project has been actually established as an IoT operating system but we actually want to do more than just IoT. So we want to look at industrial aspects of MCU controllers. We want to look at adding safety and security features. We want Zephyr to be used in deep embedded scenarios and also complex configurations, SMB and also AMB in this case. And AMB actually, this is a feature that we have already. If you look at the Arduino 101 and some other bots that have multiple controllers that communicate in some way or another, this is basically the concept of AMB. But we want to actually expand that to support MPU type of systems where you have a big core and a microcontroller and probably looking at things like open AMB to support that. SMB is also very popular right now where you can actually run a Bluetooth controller or a Wi-Fi controller and do application code on a different core. So this is like usages that are available today for makers but also available in products as well, especially on DSPs. Go beyond Linux. This is a little bit confusing here. What I'm trying to say here is that our focus as a developer or for developing, we are using Linux. Linux is the main supported platform for development. We want to also support Mac and Windows as first class citizens. We do actually. Mac, I actually can go and build for many of the bots on my Mac here, flash and do active development. On Windows, same thing, but it's still not what vendors expect. So I can build on Windows and some people actually are doing that on a day-to-day basis. But when it comes to integration into IDEs, into products, we need to do more than that. So right now, because of how we build things right now and how we started the project using K-Build and K-Config and some of the Linux history that we have in the project and because a lot of the developers working on Zephyr actually have some Linux background, we want to look forward or try to find a solution where people don't get scared when they look at Linux, especially when they are most familiar with Windows. There are different ways, by the way, today to develop on Windows in a Linux-y way. You can use containers, you can use Microsoft as an Ubuntu shell or a Linux shell that's available in Windows 10. But when you are doing serious development, when you are shipping products, when you have an IDE environment, etc., you have different expectations there and you really need to support that natively. And for us, this is very important and to get actually into this level of support. And I have heard from a lot of customers, a lot of users that they actually would go and choose a different artist for their application or for their product just because of that. Because they were overwhelmed with our PIL system and how we do things in a Linux-traditional way and they were expecting something a little bit more easier. So that's basically that. And related to this, we want to go also beyond GCC and support additional compilers other than GCC like LVM, which is already supported but not really well covered. And we also want to support commercial compilers. So right now, for example, the extensa board works only with a commercial compiler. I mean, GCC support is coming. But for products based on extensa, in this case, you really need the commercial compiler to support their way of doing things, their way of creating configurations, hardware configurations. And this commercial compiler here would apply also to some of the ARM compilers and other compilers that are not based on GCC. So how do we get there? So we need to start looking at end-to-end solutions, go beyond the kernel and OS, look at bootloader, look at cloud connectors, connectivity in general. We need to cover the whole spectrum, not just the OS itself, because that's how we can actually learn to improve and how to expand and add vision and get people basically to move to Zephyr. We need to start looking at safety and security in a serious way. Right now, we are focusing on the process. But recently, we also started looking at how we can secure and harden the kernel and make it suitable for functional safety requirements and also secure deployments. And also related to what I said before, ecosystem. We need to grow the ecosystem, integration into IDEs, supported by the tools and development environments. If you look at various artisans out there, there are different tools that you can use with these artisans, for example, to profile, to debug, in general, to develop. And that's something that usually is missing in open source artises. And we want to go there and start adding support into third-party tools for Zephyr. To give you an example, recently we added support in OpenOCD. So OpenOCD supports a way for OpenOCD itself and GDB to know about the internals of the artisans you are connected to. And we added the support, obviously, both in Zephyr itself but also in OpenOCD. And it will be upstreamed into the OpenOCD project really soon. This would put Zephyr basically at the same level as RTOS and other commercial artises out there, which is really good because debugging and profiling and having tools that aid you with development is very important for anybody who wants actually to use an RTOS for their application or product. So this is a quick overview of the things that we have done over the last year. So we had a few releases, quite a few releases last year, 1.0, 1.6, which was released in the end of November or early December. We moved actually since we started the project from a monthly cycle to a quarterly cycle. So every three months we release now. Last release, as I said, was end of November. The next release will be the 1.7 coming up actually in the next few weeks. So in 1.7 or 1.6 actually one of the major changes that we have done was we redesigned the kernel and I will be touching on that a little bit later on what we have done there. So we are still working on this in terms of removing the legacy functionality or removing legacy code and replacing that with the unified kernel. But we have added a lot of things since then as well. So besides continuing to work on the unified kernel, we added direct interrupt handling. This came all as feedback or people had requirements, for example, for Bluetooth controllers and also for applications that require very low latency and very hard real time requirements. So that's something actually we implemented just recently for all architectures. This also helped us streamline and generalize the interrupt handling. And this is actually something which is probably unique to Zephyr is that when we do things like on the kernel level, on interrupt handling, we try to do it in the most generic way. We will have one generic API and the implementation on the architecture level will be different, but we try to hide the complexity and the differences between the architectures and how things are done on ARM, on ARC, on RISC-5 Intel by introducing generic APIs to deal with that. So this is done in 1.7. We started removing some of the legacy code that we had for supporting ARM by replacing that with SimSys. SimSys defines already, I mean, has all the definitions for the Cortex M0 platforms, sorry, Cortex M platforms in this case, and it has like the basic code for timers and for interrupts and so on. So we are trying basically to move to that instead of the custom code that we had in Zephyr and that's an ongoing process but a lot has accomplished there. This will make it easier in the future to move to other or to new Cortex M generations or products. It will also make it familiar or, I mean, if you are moving your SOC to Zephyr, it will make it easier for you to do that because it will be using the same interface across the board. Another thing in 1.7 was that we changed the IP stack. So when we launched last year, we had a micro IP stack which had a lot of limitations and mid last year we decided to actually introduce something that is native to Zephyr and it was introduced after the 1.6 release. So there are a lot of things happening as well. I mean, Iotivity here, this is actually external to Zephyr but actually it was made to work with the latest Zephyr release. So it's not maintained as part of Zephyr, it's actually part of the Iotivity project and Zephyr has supported the device tree, I mean, the talk before this talk was about device tree. So we are introducing the device tree model and how to define peripherals and hails and so on in Zephyr using the device tree concept. It will be static, not dynamic as it is in Linux, but it will help us generalize things and make things consistent on how hardware is defined. And obviously it will make it easier for people to add support for their devices so they don't have to go and learn a new language or do things their own way, it will be a unified way. Unfortunately the first iteration of device tree support in Zephyr targets on boards only but we want actually to go and start adding support for other architectures as well. So this will hopefully happen in the 1.8 timeframe. So as I said earlier we have risk 5 board, extensor board, open OCD support and bootloader support which is a collaboration with the MyNote project. So when it comes to Zephyr 1.8 which will be released end of May, a few things are happening there in the background and development on some of these issues or some of these features have already started. So open or asymmetric multiprocessing AMB will be added. We are looking at the open AMB project and this is primarily to support systems where you have an MCU and for example on Intel scales and Atom processors. But this type of systems exist also in the ARM world and elsewhere as well and we need to be able to communicate between Zephyr and Linux or even between Zephyr and Zephyr itself as well if it's running on two cores. Thread stack, I mean the thread protocol, I don't know if you are familiar with that but it's something that is happening right now, it's something really big. This is for IoT primarily. So we have actually a proposal to, I know there's the open thread project if you are familiar with what's going on there. It's hosted on GitHub but we have decided that this does not fit on top of Zephyr. It comes with C++ pairs, it comes with its own IP stack and so on. We want to try to make it work with Zephyr but we have at least from Intel side we are looking at contributing a native thread stack that works with the Zephyr IP stack. And this is something that will be coming in 1.8. This will not be a full thread stack initially but I mean major components of the thread implementation and the spec will be implemented on top of Zephyr. Hopefully we will get more people to contribute to that and to make it a full thread stack in the future. Bluetooth 5 features, we are starting to look at that as well. Bluetooth 5 standard is coming along. I mean there are a lot of things that we can or we can do because we don't have the hardware because things are not public yet etc. For example when it comes to Mesh but we are definitely looking forward to adding these features as soon as it becomes possible. Expand LLVM support, basically support LLVM on all platforms. Build and debug, I touched on that earlier. Memory management and that's actually something that will be huge for Zephyr because that's exactly when we start looking at implementing security and safety features like memory protection, thread isolation. In some cases also using some or adding some MMU features like paging which would be required on systems that have shared memory and like MPUs for example, multiprocessor units and so that's something that will be coming as well. Expand device support, this is something that is continuous, we will always be adding new architectures, new boards, new SOCs and so on. In the future beyond 1.8 we are looking at dynamic runtime modules, it's probably a little bit longer term, it requires a lot of things, a lot of foundation. For example memory protection first, it's MP support, time sensitive networks, precision time protocol, this is all for industrial applications. We have people already working on that, candle data, integrity, Mesh, LWM etc etc. So we have a lot of things, by the way I mean this is now put as future but the thing is I can or the project itself or me as from Intel I can commit or I can put things under a certain release just if I have like 100% certainty. A lot of the things under future here are being worked on in some way or another, we get a lot of queries from people who are actually boarding their application or doing some work on Zephyr but we don't really know when is that going to be released or we have no control over that as well. So I expect some of these items under future to actually come earlier or some of them will actually be just delayed depending on the contributions that come in. So a lot of things are there, a lot of things are coming over the next year as I said. And just to show you basically how things are actually working out in terms of where do they fit in the project and what the project will be taking and which features are part of the OS, which are actually features that are part of the project and what falls under community. So this is trying to describe that, I hope it's not too complicated. So basically we look at the project in different three levels. So there's the community and the project as a whole and people who are using Zephyr sometimes just pulling Zephyr doing something, putting good thing with GitHub without actually getting involved with the project itself. And you see a lot of these things happening. I have seen, I mean if you go to GitHub or even just search for the project, you see Zephyr being taken by university professors to teach their students about art uses and et cetera, et cetera. You see people doing like some basic stuff and probably abandoning or moving away from that, but you see the work existing like on GitHub or in some other places. And you see people also being active but without being involved in the project directly. The project is a little bit more close to what we are doing. These are people who we know what they are doing. We talk with them and we also work very closely with them. And sometimes it's actually initiated by the project itself. So we have things like SDK, tools for development and so on. Additional middleware and features that don't necessarily fit in the Zephyr OS itself but work with Zephyr. Bootloader for example. So there are, for example, if you look down below here in the community, something I missed, it's like things like JavaScript, micropython, iotivity. These are like maintained in their respective projects as support for Zephyr. And we work closely actually with some of these people and we know it's happening. But it's not really, it's not something that is governed by the Zephyr project. When it comes to the OS, so last year actually we started, I mean most of Zephyr was actually the kernel itself and some of the had. Meanwhile we expanded, we have OS services, we have application services, we have a lot of subsystems on top of the kernel. And this is basically the core OS and it's very important to make this distinction because at some point when you are trying to secure or certify something, you need to know exactly what you are dealing with. You can't be certifying everything, you can't be, I mean you don't have control over everything. So the OS itself where probably will be the part where we need to go and certify and harden. Security should be applied across the board but when you as a project are trying to maintain something secure or declared secure, you really have to have full control over it and it has to be defined and there has to have to be some limits for this definition. So this is just a little bit more about the project itself, basically tool chains, it's decays and so on. Hardware testing that we are doing, binding and so on. So in terms of architecture, we are talking here about, yeah, I mean it's going all the way up from the kernel to middleware, to subsystems and then to the application. Still our goal is to continue to be highly configurable and highly modular and to maintain some of the, like, do things in a static way so you know exactly what you are building and what you are configuring there. And to continue to have hardware support and expand the hardware support. Advanced usages, we are moving away from the traditional model of like one core, one RTOS or a few applications to supporting complex scenarios or advanced usages. For example, the Arduino 11 is a case where you have three RTOS, sorry, three cores where ZIFAR actually can run. So you have an x86 arc and arm cores running on one SOC and ZIFAR runs or can run on all of them, communicating in different ways. SMB is something that we need to add to the kernel, we don't have SMB support right now. I don't know how much more time I have. Okay, so let's move faster here. So I talked about the kernel, basically that we had two kernels, initially nano and micro kernels, separation of duties, we moved away from that. If you have done things on ZIFAR before 1.6, you use actually to develop basically for two kernels. It was good because the nano scheduler was very fast, you could use it for a lot of applications but not everything. When you move to something to complex or more advanced applications, it becomes a little bit more complex because you had to do things with the micro kernel. And we had basically two sets of APIs to do that. And from a developer perspective, this really was basically, you were basically writing for two operating systems. It has, as I said before, it had good and bad advantages and disadvantages, but this was confusing to a lot of developers. So in 1.6, we moved to the unified kernel. So basically we removed the micro kernel, we built on top of the nano kernel, and we introduced a well-known preemptible RTOS model, which supports also cooperative scheduling as well. I mean, all of that happened actually really in a smooth way, and we still support the legacy API by the way as well. So the legacy API will be supported until after 1.8, then we will remove it. So the kernel right now, I think it's a very good state to give us basically the foundation for developing on top of that. And one of the main things that also changed in 1.7 and building on top of the unified kernel is the IP stack. So it's a dual, more native stack. So that's actually one of the main reasons why we moved from the micro IP stack is that we wanted to support IBV4 and IBV6 at the same time. We wanted to have multiple controllers or bearers in this case. And we wanted also to develop it in a way very close to what Zephyr has and also control our destiny and also prepare ourselves for whatever is coming in terms of standards and future technologies. So that's where we are looking at in terms of support. We are actually, from the ground up, we are looking at supporting thread. So we have designed the IB stack actually for thread support. We looked at thread requirements and started implementing them in this stack. We are looking at industrial applications like VLAN and time sensitive networks and so on. Mesh of course, and we also looking at trying to get the IBV6 ready logo. Once we have all features implemented. Bluetooth, same thing. I mean one of the most interesting area in Zephyr, the Bluetooth support that we have. So we have a controller contributed by Nordic. Now we are trying basically to add more support for other hardware as well. And it is adding also looking at classic as well. BRGDR and six low ban on IBSP. So it is well established software stack for Bluetooth in Zephyr. But of course we are looking forward to support 5.0. Mesh once it's released. And try to expand the hardware support as well. Last but not least is integrated security. So we have adopted MPTLS for encryption. We are looking at device management updates using the bootloader that we are working on with runtime IO. There are a lot of things here that are device specific. A lot of them are being done by the vendors. It's not really part of Zephyr. But we are now for example we have the static and single binary application and single address space and no loadable modules. But this is subject to change because one of the main things that we have found out is that to be able to declare Zephyr as a secure platform we really need to have thread separation. So right now with what we have we can call it trusted in terms of processes, code reviews, scans that we do. But when it comes to security we really need to enable thread separation, memory protection in this case. So that's exactly what we are looking at going forward. It will come with a lot of penalties. But this is something that we need as everything else with Zephyr we need to keep to make configurable and keep configurable and keep it in a modular way. So this will probably take some time. We will start with memory protection, thread separation. But we want to go a little bit deeper and start looking at integrity protection schemes as well. And looking at kernel objects and try to secure them and protect threads from other threads running on the same system. So this is it. Hopefully I made it in time or I'm a little bit late. So please take a look at the project. It's hosted by the Lynx Foundation. You can find everything here at zephyrproject.org. We are right now on Garrett. Probably we are going to move to GitHub soon. But everything is available. Just search for Zephyr and you will find a lot of resources. There are a lot of talks about Zephyr during this conference. So please take your time and visit some of the sessions about Zephyr. Talking about some of the aspects that I touched on here. Thank you very much. Do you have any questions? Yes, this is something that we talked about in the past and we really need to address in terms of schedule. We definitely have plans for a LTS type of release where we can actually branch or harden for security, harden the kernel and have a security branch. This is actually part of the charter of the project. We will definitely discuss that in the board and TC meeting that we will have this week. I don't have a plan for this but it's going to happen around 1.9, 1.10 probably. This is something that we really need to get a lot of the security features that I talked about and some advanced features in before we go there. We can't actually do this before having, for example, thread separation and member protection schemes. But it's definitely on the plan. Linux kernel and Zephyr? No, there's not. Yes. If you want to call this sharing, it's a certain way of doing things. We are looking for example at the Linux kernel and there are a lot of things that are developed. For example, good example, can bus. Socket can is implemented in the Linux kernel. We are looking at that there's actually a group of people working on making this work on Zephyr as well. Using the IP stack and using the socket interface. So this is like one example. But there are other things in the Linux kernel that somehow apply to an RTOS or to an MCU. Then we look at the kernel. Obviously we need to be careful about not covering code because of GBL and so on. So we can't share the code but in terms of how to do it, we are definitely looking at Linux. We are not trying to reinvent the wheel. No, no, we definitely welcome any contribution. Just an example, the RISC-5 and the extensor boards, they were done by the vendors themselves. But we will not block that. As long as you commit to support it, submit it, document it and so on, that's all welcome. There's no limitations there. Can you finish my person for the RISC-5 stack? Yeah, well first we have to reach a level of... Right now we are just dealing with the IP stack that was added. There are a lot of issues there. But thanks to the contributions and involvement from the community, that's actually getting much better. We are actually doing the testing, some automated TAHI and other frameworks to do automated testing. And we are passing actually a good level of these tests. And once we have a certain level of confidence that we can go and do that, probably in the 1.8 timeframe we will be able to go and start getting serious about it and getting the IBV6 ready, for example. It has been a bumpy ride, but I think we will get there in terms of IBV6, but also other protocols, not necessarily. We are doing like when it comes to co-op, we are looking at interoperability testing, 15.4. We need to actually start engaging other orthoses out there that support these protocols and hardware and do some interop. Like Riot and Kuntiki and try to look at this level of support, because that's where most of the new technologies are. And you can claim support for a certain protocol or certain hardware, but if you only work with yourself, that of course doesn't... You have to work with others as well. So we are going there. Actually we are thinking about having an interop with Riot, and it's still like in planning, but at least we talked with the Kuntiki guys, but we will be talking with others as well. That probably would be necessary before going to the IBV6 ready or whatever certification. Okay, thank you very much. If you have further questions, you can come to the podium and ask me.