 All right. 420, so this is the time to start. So thank you very much for being here. My name is Frédéric Devien, or Frederick Dehebion, something like that, or Fred, or Blueberry, whatever suits you. And I'm the program manager for IoT and Edge Computing at the Eclipse Foundation, so another foundation that you probably know about. And we'll explain a bit more in this presentation what I'm doing here at this Linux Foundation conference. All right, so the whole point of this talk is to give you a bit of a taste of what Zephyr is and what Eclipse components you can use with it in order to build IoT and embedded solutions. Now, before I say anything else, how many of you are already familiar with the Zephyr operating system? Please raise your hand. Oh, OK, not many. OK, so that's good, because I've got some content to cover that. At least give you the basics. And then give you the basics of what Eclipse IoT is and what components we've got in the toolkit that can have stuff, all right? So let's get started. First, if we think about IoT solutions in that general perspective or even an embedded solution, embedded is the older established term, but really IoT just adds the fact that you always have a network connection. But whatever project you consider, an IoT solution or embedded solution will have a number of characteristics that are different from a standard software project. First is the lifespan. When you build an IoT thing, you build it for 10, 20, 30 years. No way you will rip off the walls of this hotel to replace sensors two years from now, right? So you need to think over the long term. Then obviously, an IoT solution is heterogeneous in the sense that nobody in the market will give you all the software and hardware pieces that you need in a single place. OK, nobody can do that. So you have to work with multiple vendors. And obviously, there's the connectivity aspect in the sense that, well, you always have a network, but it won't be reliable. It won't be stable. And you have to design around that. But the main concern when you think about IoT or embedded is really the fact that you have to work with so many constraints, constraints of power consumption, constraints about the environment, temperature, humidity, you name it. You have to deal with that. And this has a tremendous effect on the type of software and libraries that you will work with. You need everything to be optimized to fit the constraints that you have. And that's why, typically, Linux will not necessarily fit if you have really a project, an IoT, or embedded project that will use constraint devices. So I picked up here on the slide just three devices, three boards I have lying around at home. And I wouldn't pretend they will all serve in production level environment or anything like that, but just you look at the specs on those things. CPUs, 64 megahertz, 16 megahertz, 64 kilobytes of RAM. I mean, last time I ran Linux on a 60-ish something megahertz system, I had air on my head. Can you imagine that? It's been a while. All of that to say that even if embedded Linux made great progress to slim the platform, trim it, you still need a few dozen megabytes of RAM in order for everything to fit, and maybe more if you want to do real-time and that kind of stuff. So that's where an operating system like Zephyr is a perfect fit, because it will run actually on those boards, and it can do something useful with them. Now, every year, the Eclipse Foundation runs IoT Developer Survey. And we had a question specifically on constrained devices. What are people using in their projects in the real world? And we had about 1,700 replies this year, so it was quite successful. And what people told us is, essentially, when they pick hardware for their projects, there's a tremendous amount of diversity. Obviously, ARM is dominating. When you add up all the ARM parts on this diagram, you've got about 70%. But even in ARM itself, you've got 16-bit, 32-bit, M0, M3, M7 with different profiles and that kind of stuff, and it's very varied. And there's a 30% of the rest that's really anything and everything. And if you design a solution, and your solution is specifically stuck or coupled to an architecture or anything like that, you are at the mercy of your hardware provider, hardware supplier. And this is a major problem that the respondents to our survey identified. So Zephyr is good for that in the sense that it supports multiple architectures out of the box, certainly. And as you will see, we've got additional components that can help with that at Eclipse. Now, looking at operating systems, we were asking in our survey to tell us, OK, which OSs are you using for your IoT embedded projects? And you could pick multiple choices. And unfortunately, the question didn't tell us, OK, pick the number one, the number two. It was just check everything that applies. So unfortunately, my data is not that good. But FreeRT OS, Embed OS, Riot OS, several operating systems were mentioned more than once. And you see them on the slide. But looking at the trends in non-Linux operating system in IoT in our survey, you see a few interesting facts. First, the fact that most established players have seen a decline. And many of them are proprietary in there. So you see some momentum for open source solutions in the space. And the other is the great decline in no OS or bare metal. And this, for me, is really telling IoT developers start understanding that you shouldn't write low level code if you want to deliver something that is quality and on time. Maybe you individually are a genius developer that can do it. Maybe I am. No, I'm not. Maybe you are. But the thing is, the next guy after you, the guy in the next room at the office, is he that top notch developer that can write low level code without bugs? Probably not. So to use an operating system is really, really important on a constrained device. And I was really happy to see that trend in our survey for sure. And we see that Zephyr is there with 3%, not shrinking, which is considering the overall trend in my graph, an indication that there's momentum there. Now, many, many alternatives for your real time operating system for a constrained device. How would you would pick one given the number of stuff that's there? First, there's obviously hardware support. Will it support the CPU, the SoC, the board that you are planning to use? And then there are connectivity and power supply issues. Can it run well on a battery for 10 years and stuff like that? Obviously, more and more security is important because with embedded and constrained devices, it's easy to unscrew a sensor or a board from a machine or from the wall or from whatever it is installed and run with it. And you don't want that device to be compromised. So you need secure boot, device authentication, all sorts of nifty things there. And that's on the functional side. But on the non-functional side, things to look for are, for example, a lock-in to an upstream distribution or a specific cloud. You don't want to be locked in in anything. I mean, if you are here at a Linux conference, so the same should apply to your constrained devices. Licensing and IP. How is it licensed? Can you do commercial products out of it or not? Security updates, CVEs, stuff like that. I mean, only the serious players will be emitting CVEs on their OSes and do a strict follow-up on security issues. Safety certification and, obviously, for those that are open source, the number of contributors, not only as a number of individuals that code, but who's behind this? How many organizations are supporting the project? And all of that are very, very important criteria. And, obviously, there are quite a few suitable solutions in the market that fulfill those requirements if you are to pick one. But to me, one of the most interesting ones was Zephyr. At the Eclipse Foundation, we don't have an RTOS, so I get to play with whatever I want. And one that tried it with Zephyr for me was really a distinctive and interesting OS to work with. For a few reasons. First, the fact that it is so modular, so you can tweak it to fit on those very, very small boards with just the minimum amount of functionality that you need. The fact that it supports several trading models, so this makes it more adaptable to different use cases. A clean driver interface, memory protection, strong support for Bluetooth low energy, which is a lowest common denominator if you're working around constrained devices. And the fact that it's got Bluetooth mesh now is really something. And a native networking stack because it's a pain to have to deal with those things yourself. And once again, unless you are a networking genius, you don't want to implement your own little TCP IP stack or anything which is that low level. When we consider Zephyr as an open source project now, I think there are a few things there that are really important and make it interesting as well. Well, first, the thing it is open source, but there are two report source projects. What makes it interesting is the fact that its license is permissive, it's Apache, so you can do whatever you want with it. And that it's got vendor neutral governance. And at the Eclipse Foundation, this is literally when you join, you get a few tattoos at hidden places on your body and the most important one is vendor neutrality. Okay, since I started there, I have to obsess about that. And well, I'm, you know, the Linux Foundation is certainly a natural believer in this approach. So vendor neutral governance is important because you don't want your RTOS to be something like Golang. Golang is marvelous as a language, it's a technical achievement. Okay, and it's got a great community, but this community is stuck proposing to Google improvements and modifications to the language and they just have to pray there for Google to accept them or not. Okay, single vendor open source is not the way of doing things. That's why if you pick an OS for your project, you have to pick something that is overseen by some kind of vendor neutral body. Zephyr has also an LTS branch, really, really important if you care about the stability over the long term of your hardware and software combination, especially, well, the talk just before me, they were describing a project with Zephyr on a hearing aid and they have to certify that with L-tutorities. So you need your software and hardware combination to be viable for several years otherwise you are running after bureaucrats and I'm quite sure that's a pain, right guys? All right. And another interesting thing about Zephyr is that they are looking to bring security certification for the code base, which is another problem that you don't have to deal with as a developer or as an organization and believe me, you don't want to have to deal with that and lawyers and that kind of stuff. All right. Now, okay, that's the Zephyr part. I'm here to tell you when you can use Zephyr with Eclipse IoT components. Maybe, okay, let's check. Who was aware that Eclipse was doing stuff in the IoT and embedded space? Oh, a few, okay, but the majority of you didn't. So I'm glad I'm here. So we are doing things there. Eclipse Foundation, I'm quite sure you know the name. Do not confound please with just the IDE. We are much more in that. We've got 370 projects now with a bunch of lines of code and everything. Doing all of that with about 30 people, most of them in Ottawa, Canada and we have a team in Europe as well. But when you consider our mission and what we've been doing, we have four areas that are really, really strategic to us. Obviously, Cloud Native Java is a big thing. We are the new home for Java Enterprise Edition. Whoop, Jakarta EE, that's the new name. And obviously, IDs and development tools are very part of our core mission, but IoT and edge computing and automotive are also areas where we have a tremendous level of activity. And looking specifically at what we are doing in the IoT space. So that's about 38 projects, 350 plus contributors, 40 member companies. Some of them are big, some of them are small. When you consider the toolkit, I mean it's got implementations for nearly every protocol you can dream of, really. So MQTT clients and servers, co-app, et cetera, et cetera. So I'm not mentioning all of that today. The point is not to be exhaustive here, but just to give you a taste of what we've got in the toolkit. Looking at our membership, we have lots of organizations big and small there, and that's just the membership obviously for IoT. And on the fourth line, you see the Linux Foundation. So the Linux and Eclipse Foundations exchange memberships a few months back, and we are now happy to count the Linux Foundation specifically the Zephyr project, apart of our IoT family. So because we compete a bit on the edge of things, I would say, it doesn't mean that we can't work together. And in my book, anything that makes open source stronger is a good thing for the industry and for the community. All right, so what I will look at now is to give you two specific examples on how you can leverage Zephyr and Eclipse IoT components together to solve specific problems. So for example, you have this marvelous board, you have a bunch of sensors using the I2C protocol, which is a serial protocol from the 80s, so you find lots of sensors that will support that, if you are less familiar with that. And let's say you want to write a little app that will read a sensor value. Well, there are two main steps, if you write that by hand, which is to set up some pin boxes and then interact with the sensor itself, and you see the detailed steps on the slide. Unless you are paid by the number of lines of code that you write, this is, well, not necessarily a productive endeavor, right? So we think there's a better way, which is to write five lines of code where essentially you call a constructor for the sensor and call a read function and be done with it. And at Eclipse, this is enabled by two projects that we have that come from Intel. Thank you, Intel. That are Eclipse, EMRA, and Eclipse, UPM. So in the previous example, EMRA handles the pin boxing and memory allocation and the low level stuff, and UPM is a library that will handle the sensor itself. So you see on the diagram, okay, you have your hardware, you've got physical pins, the kernel of your OS, in this case, Zephyr, and then EMRA and on the top of it in user space, UPM. So what are they exactly? So EMRA is a kind of standard IO interface for IoT hardware. So essentially it's a kind of hardware abstraction layer that abstracts GPIO, UART, whatever. It's listed on the slide, so I won't name everything there, but most of the devices that are built in on boards or the sensors you can find on the market are already supported, at least at the protocol level there. And then UPM is a library in user space, as I said, that really provides you standard sensor and actuator APIs, so for light, pressure, humidity, temperature, whatever. So whatever the actual type of sensor you have, you write the code once and you run it on multiple platforms, whether it is hardware or software. So both libraries are written in CC++ and support multiple operating systems. So Zephyr is one of them, but this will run on Linux and in fact we have plenty of community members putting that stuff on their edge gateways, for example, because they put sensors on them as well. And the libraries support x86 ARM MIPS among others and have bindings for Java, JavaScript and Python, but obviously in the case of Zephyr, you will work with that mostly in C. So those are very healthy projects that we've got. The Intel contributed them a few, I think last year, but they exist since 2014. So they are quite mature with a large community, lots of support, lots of docs. So it's really a pleasure to work with those teams. Now let's think about a different problem. If I need to manage those devices, let's say I have a factory with a thousand devices and all of them are fitted with sensors and I want to do predictive maintenance on that and monitor them in real time. Or I have this digital building with thousands of sensors everywhere over multiple floors or maybe a few thousand buses or a few hundred buses or planes or whatever and once again there are camera sensors over the place so how do I manage that? And there's a standard in the industry that's called OEMA LWM2M or, well, Lightweight M2M, let's say. And in this case at the foundation in Eclipse IoT we've got two distinct implementations of that, one in Java and the other in C. So have you seen the case of Zephyr Eclipse Wakama written in C is probably what you want to leverage. It leverages an other Eclipse project for DTLS which is, well the equivalent in that word for TLS, okay? And Zephyr has got already features that are built in that will support Lightweight M2M and DTLS and that kind of stuff, but in this case, especially if you are working with those libraries in other environments and limits environments you can use the same code across the board and the same is true for MRAV, whatever you write elsewhere, we run also on Zephyr also on those environments. So this could be one of the reasons where you would leverage Eclipse libraries instead of the built in ones or maybe because of the feature support for a specific thing in newer versions of the standards or stuff like that. And in any case, they are there and both of them have a server side components as well. So even though you may want to leverage the client part that's already in Zephyr, both Wakama and Leshen enable you to create Lightweight M2M servers and the M2M standard will help you, essentially to control and monitor devices in a standard way across the industry. Now, if this is not enough, we've got another project that could be of interest to you which is called Eclipse Augbit and Augbit will use M2M, you see it at the bottom, the bottom right, okay, device management services, but it is a wider scale platform where essentially you want to push software updates to not only constrained devices, but edge nodes as well across multiple OSs, multiple environments and this is stuff. I can't name them, but most leading cloud platform as a software providers, okay, think about the top two or top three of those are using this without telling you and on the top of that, this is a core component of the Bosch IoT Suite, a commercial product that it's built on the top of that. So it's got a very, very wide usage in the industry already and it's a great, great platform built on micro-services, you can integrate that with whatever else you want, so it's really a very, very good platform to work with. All right, now, if we take a step back and think about IoT and embedded development, there are many, many, many functional concerns. Some of them are about the constraint device itself. Some of them is about the edge and the gateways or whatever and obviously some of them are about the cloud. So when you consider overall what we have at the Eclipse Foundation, well, we've got tools and solutions for most of those concerns and for those that we don't have like the RTOS or OS for the constraint device, we're more than happy to work with the Linux Foundation on rising awareness of Zephyr because we think it's a great platform to work with and I'm still a coder, although I don't code as much as I want because I travel at the time, I speak all the time instead but let's say that if I were to start my own little business, tomorrow Zephyr would be probably my tool of choice for the operating system. So plenty of stuff, a very high level, my apologies for that. So next year I will certainly propose a few more detailed sessions about how it is to code with all of that but given this is my first year here, I thought giving you a first taste and a contradiction to it would be better. So if you want to learn more about Eclipse IoT components we've got our website, ioteclipse.org slash projects but this is just for the time being a very dry list of projects. So if you need any assistance, please reach out to me, okay, we can sit together and figure out what's the best fit for your specific project, specific product that you are working on. Please try our technology, all of our stuff is open source and permissively licensed, okay, so you can do whatever you want with it and we are just here to help. We've got a newsletter and official Twitter account for that and we've got our own little conference so if you happen to like Germany and be around there in October then EclipseCon has a full IoT track where you will learn more about several of the stuff that I discussed today and much more obviously because we have interesting things brewing especially around edge computing. So we are on the brim of announcing our edge computing working group. We have also something called the Sparkplug specification working group which is essentially a standard on the top of the MQTT protocol in order to make devices that implement it interoperable because well, if you ever worked with MQTT as a protocol it's a bit like working with Java messaging or WebSphere MQ or whatever, it works well at the transport level but I mean doesn't specify anything about the payload and the payload is key to make devices interoperate together so we are working on solving that problem with members of our community and obviously looking forward to hear from you and get you involved because that's a thing. This call of action is not just to consume the stuff, this call of action to action is really to involve yourselves and contribute to the projects because while essentially open source you won't reap the full benefits until you contribute and the reason for that is simple when you have a critical bug on Friday at 10, 20 p.m. and you need somebody to support you, I guarantee you even if you have an SLA with a commercial vendor they will not help you out in a meaningful way. They will have some kind of intern or whatever that will handle the ticket and that's it. So when you are a member of an open source community what happens is that you know the guys who wrote the code because you're part of them so if you have a critical issue they will come to your help because you're part of one big family. So that's our approach to things so I'm looking forward to see contributions from you all at some point. And that's it for now so thank you very much for listening to me and I think we've got enough time for at least a few questions if I didn't scare you. So thank you.