 Hello, welcome everybody. My name is Thomas and I have the pleasure today to have a talk about Riot the friendly operating system for the IoT. In advance, can everybody hear me? Better now? Okay, so Riot the operating system for the IoT, the friendly operating system for the IoT. In advance, I want to give a little bit of a motivation why you rethink it's a good idea to have an operating system or software platform for the IoT and how we imagine that to be before I actually go into details concerning Riot. So why? In the course of the past few years, especially like hardware for the IoT got very affordable. Those, this hardware is on both sides of the spectrum for the IoT. So there is high end hardware for the IoT in like compared to like a Raspberry Pi. And then there's the other spectrum the low end spectrum hardware for that, which often runs some kind of Arduino framework or still a lot of people program on them like bare metal. And I mean, a lot of amazing projects came out of that already, especially if you look at the maker space and so on, like there's a lot of things going on and a lot of creativity. But at some point, you often reach a certain complexity in your project where you have to include some advanced network connectivity or your application evolves. And at that point, it's, oh, it's a good idea to actually have something that takes work from you. And also, especially if you develop bare metal, it's often hard to like provide a degree on portability. So you're often bound to a certain hardware platform or comparable. So via software platform, it speeds up innovation because you spread development costs. And on the long term, it provides robustness and security because you have, you can profit from development others do too. Open, especially open source software platforms provide a certain degree of trust and transparency. And you're also, I mean, it's a possibility at some point to reduce actually like garbage and they're like, everybody knows it like you buy your cool new gadget and at some point, the company just doesn't support it anymore or even worse, the company disappears. So at this point, you want to have some kind of a possibility to actually still use your device. And how do we imagine this software platform experience, especially from Linux shows open source for an operating system is a very good idea, especially the course should be free. And also, if the development is actually driven by by a broad community, then chances are that they will still get picked up, even though maybe certain people lose interest in that kind of project. So it also enables indirect business models like around this software platform or environment. And it especially also provides geopolitical neutrality. So you're not locked in or like under too much of an influence of maybe some kind of government or any other means. One of the kind of models for riot is if you can't use Linux for your device, try riot. So we obviously more focus on the low end IoT devices. And those devices come with a lot of constraints. And within these constraints, there's like identified like these four main points, which are for one, you have to have a good performance kernel. Then it's the next one is on system level, you want to have interoperability. And this kind of interoperability also want to have on a network level. So connectivity to the internet of things. And the third fourth point is trust. On the low end, for low end IoT devices, there's good news and bad news. The good news, we probably won't have to deal with any kind of GUI or something like you have access to it by a simple shell. That's for most cases, sufficient. And because most of those devices will not have a display connected to it. Those devices also, in most cases, have a very low throughput in terms of network traffic. And they don't run dozens and dozens of applications on one device. So most of those devices have one single purpose. The bad news, we're dealing with devices that have kilobytes of RAM, typically no MMU. And the use cases for these kind of devices are usually they're running on batteries. So you have to have, you have to be very, very energy efficient, at least as energy efficient as possible. There is existing software platforms out there for low end IoT devices. If you take a look at the timeline, there is a, especially tiny OS, Contiki and Artus, they were, they came out when the IoT was actually still called wireless sensor networks. Before we had this fancy marketing name. And after that, there was a lot of standardization pro progress. So we got IEEE 802-154. We got RFC 49-44, which was basically IPv6 on 15.4. And in 2010, we also saw the ITF core working group starting, defining IoT protocols like co-op and SIBO representation and they like. And then 2013, and Teraiit. And especially in the last years, a lot of other software platforms popped up, most prominent here, Sapphire. But before that, there was already MBATOS by ARM, and also Huawei has LiteOS. And so there is, the good thing is all those operating systems, software platforms, operating systems are open source. And besides that, there's also a lot of closed source alternatives. So what is Riot? Riot tries to be an OS that fits IoT devices. So we are not targeting Raspberry Pis. We're not targeting mobile phones or anything like that. Does these devices have the operating systems and operating systems that are very mature and also driven by companies that invest a lot of money into it often? So we are trying to get all those devices that, as I mentioned, have a few kilobytes of RAM, no MMU, very energy constrained. That's what we or for Riot as part of the IoT. Riot is free and open source. It's licensed NL, GPL version 2.1. You can write your code in NCC or C++. There's no kind of CDAT dialect or something, which you might know from TinyOS. Riot offers some selected POSIX features like P-threads and sockets. And actually starting out with Riot is pretty easy. You don't even need hardware. You just compile Riot on your local Linux machine and start several instances of Riot in parallel. And you can even connect them via tab interfaces. So you can actually simulate a significant network on your computer. And as you can run it as a process on your Linux system, you can also use the well-established tools like Wireshark, Wellgrind and GDP, as mentioned. Riot is a free and open source. It has contributed worldwide. So pretty much every continent by now. Those people are either from industries or somehow affiliated with a company or many people are also from academia and also a lot of hobbies and makers. The community is self-organized, so there is no hierarchy in it other than the common repository hierarchy. So you have a certain subset of those contributors who act as maintainers and do the code review and the like. Getting to kernel performance. Riot has a microkernel architecture. And this kernel uses about 1.5K of RAM on a 32-bit architecture. The Riot scheduler is tickless. So unless there's actually work to do, your device remains or can remain in a deep sleep mode. This is mostly for the mentioned energy efficiency. The scheduling is actually deterministic to assure real-time capabilities. And also the interrupt handling is as little latency as possible. It provides a modular structure, only compile into your binary that code you actually need. And Riot offers real multi-threading and IPC framework. So each thread running on your device actually has a separate memory region and the like. That's the overall, or should give a little bit of an impression of the architecture. So on the very bottom you always have the abstraction from the hardware. In Riot, those are called like pair interfaces. So those provide an API to timers, UART, SPI, and the like. On top of that, you have drivers for sensors, radio drivers, other kind of network devices. And the kernel. And on top of that, in SysNet it's mostly like the network stack. Sys also contains some additional tools, which I will show later. And in package provides a mechanism to actually include existing libraries to include in your Riot project. The two main points I want to cover next are portability and connectivity. Those are mostly in the signed building blocks. Redowning connectivity. Riot comes with a couple of supported networking technologies. As mentioned, 802.15.4, also 802.3 Ethernet. You can use Bluetooth, NFC, you can also run an IPv6 stack over serial, and you can also use Canvas. On top of that, we have a very well, by now, tested six Lopan implementations. So we've been to a couple of interoperability tests. Actually testing against Linux and Contiki. And also IPv6, as we're talking about IoT, I think there's not much other, or many other possibilities. And we provide UDP TCP connections. And on top of that, for the application layer, we have our own co-op implementation. But as I mentioned before, with the packaging system, you can also use, for example, LIP co-op. And since a few weeks, actually, we also have MQTT sensor network implementation, which is still very young and not yet interoperability tested. But it's in the making. That's, like on the bottom to the radio device, you have a NETF2 interface. That's Riot's abstraction to the, to the, to any kind of networking interface. So on top of that, you can easily put GNRC, which is Riot's GNRC, like generic networking stack, which includes the features I mentioned before. But you can also use basically any other kind of third-party stack. So there is ports for LWIP, micro IP, open threat. And we also have a support for some more experimental stacks, like CCNLight and NDN. So those are a different approach to basically how we route traffic on the internet. Regarding portability, we try to keep hardware dependencies as low as possible. So in a perfect case, you code your application once and run it everywhere. In a, in a usual full IPv6 co-op application, that's true for 95% are actually hardware independent. In terms of hardware, Riot supports various 32, 16 and 8-bit platforms. Those are mainly like ARM, X86, MSP430 MIPS and AVR platforms. And one, as far as I saw it yet, a kind of special thing to Riot is actually most of the drivers interacting with the, the, the MCU. So Timers and Son are actually written by Riot contributors. So we are not using vendor libraries or anything like that. And to actually compile your project, you can either use GCC, which is the standard tool chain, but you can also use LLVM. And as mentioned a couple of times already, you can also use existing libraries like lip co-op, lip fix math, LWIP, micro ECC, and relic as to give us an example. And porting actually your hardware to Riot is pretty, or we try to make it as easy as possible. Usually it doesn't take more than hours or days depending how much support for your platform is actually already in Riot. So if you have some kind of Cortex-M based board, it's very likely that the port to your platform will be done or can be done within an afternoon. If you actually bring in a new CPU and so on, it will probably take a little bit longer, but especially if you take, for example, Cortex-M platforms, there's a lot of reusable code already existing in the tree, so you don't have to deal with all the scheduling and so on on the new platform, so you can easily reuse that. And it's also meant for us maintainers to actually reduce code to take care of. And so we try to provide some additional tools for developers. So as mentioned, there's a wrapper for enabling developers using POSIX sockets and P-threads. And there's also the before mentioned shell. The shell is basically you can connect your computer to your device over a serial interface and then interact with the device using, for example, PS to see all the threads running on your device and their memory consumption. And you can also use ifconfig to actually configure your one or multiple networking device. So it's that we also offer some crypto and hash algorithms. You can write your code also in C++. We not necessarily encourage you to, but you can. And you can also take your Arduino sketch, for example, and just run it within write. So we implement the most frequently used Arduino APIs. So you can really just take your loop and put it in the main file and it will run. We also provide you with a C-Boar and cml interpreter. So those are both technologies coming out of the ITF core working group. C-Boar is mostly the representation of the data. And cml tries to be a common markup language for sensor data. So then we're approaching trust. If it's secured, the IoT can really be groundbreaking in a positive way. So the IoT will penetrate our daily lives and already had, already did. But it also has a lot of thread in it. So especially if you take a building of yours with a couple hundred of devices, there's concerns coming up about privacy, security, and also reliability. And what's going to happen if the company I bought X devices is not able to support us anymore because of any reason. So the IoT is challenging. But what is possible if we provide an enter and open source solution? So you have Riot on the Internet, Linux on the Internet, and also maybe on the gateway. And maybe Riot Device, you have an enter and open source setup. And what we also want to promote is an enter and secure and open communication stack. So those devices can actually still, there's no magic to the protocol that's like openly specified. So it's really about the, from the device to the server, it's all open and hopefully secured. A little bit of history. So Riot, that actually a kernel is a result of research projects called FireCurnally and Mucleos. And in 2013, there was the rebranding to Riot. The source code was moved to GitHub, and which gave us a much broader audience and development and very much accelerated. So there was the code grew significantly and also the community grew. In numbers, in 2016, there was 3,690 commits to the Riot code base from about 150 contributors and reviewed by 30 maintainers. Today we support more than 60 boards, so mostly development boards by various vendors. Those boards feature more than 35 MCUs and we have drivers for more than 25 sensors. Last summer we had our very first Riot summit to just provide an opportunity for the community to gather and have talks and just celebrate this success a little bit. And we are also still in the process of actually forming a foundation or association to provide a kind of legal body behind the project, which can interface with companies and like. The usual work is usual as we have a time-based release model, so we release every three days a month. We changed that from a feature-based release model because we just saw it just delays some releases often for too long. We have a roadmap to gather input from the community and from companies and to help the core developer team to focus on specific topics. And one means of that is actually the so-called task forces, so people organize themselves in groups and sit together either physically or virtually and actually try to come up with solutions. And the whole development process is actually very open, so you can basically see it all on Github. It's mostly done by Github pull requests and issues. And besides that, we have those lovely hack-and-ex sessions, which are basically once a month to bring together mostly maintainers and contributors to work on certain issues that arise during the code review. General communication is mostly done on mailing lists, and a lot of people discuss things or just chat in the RIC channel. So coming to an end right in nutshell, right? There's a free open source platform for portable IT software and tries to be functionally equivalent to Linux. So open source, open access protocol stacks and that all driven by a enthusiastic community. With that, I want to say thank you. We have a Twitter account for the news and before mentioned mailing lists and RIC channel. And I'm happy to answer questions if there are any. There was a very long ongoing discussion within the contributor community and LGPL was the consensus at some point. There were others mentioned as Apache, MIT, BSD, but in the end it got LGPL. Mostly it's like contributions made. People want them to be still like maintained. So people don't want to make contributions and then somebody else uses it and never contributes back. So that was one of the most cited arguments. Anything else? Here in the threat model, it's basically every threat becomes each stack size. So you have a certain amount of memory designated to this threat. You can change those numbers. The default is 1K per threat and this is for this threat only. We have kind of, there is a work ongoing to support MPUs, so memory protection units, but as those devices don't usually have an MMU, that's like how far you can go with memory separation and so on. Anything else? Okay, thank you everybody.