 Hello and welcome everybody to this session on how to tame my edge devices. My name is Sven Ergiozeski and I'm coming to you from Berlin, Germany, working with Bosch IO. So in the next couple of minutes, I want to take you on the insights and our journey that we had when looking into how to manage edge devices and you could also say how to tame those devices. So the first thing when you look into such a problem is maybe come up with a definition what you actually try to solve or what you actually which domain you're actually looking into. And I know there's been a couple of debate on what edge computing is actually is and what it isn't. So for the remainder of this talk, I will more or less rely on this architecture shown on the slide. And I have on the one hand side, the constraint device that really small sensor devices measuring your temperature measuring your light or something like that. A small robot or control something by controlling evolve. Then you have devices controlling these constraint devices and also being kind of the bridge to the internet. And also allowing you to do some more compute computational intensive tasks. So, you know, the topic of AI comes into play in the future is possibly also more flexibility in your software. Then you have the access transport which you could also consider as an edge but maybe for all the telco folks. So in this talk, I have a bad news for you, I will mostly talk about this device edge or in this case more deep on premise side. So, and so we want more about these terms I would also recommend reading into the white paper on state of the edge. And last but not least and you can see it in the slides you have also the cloud makes a big cloud with all where data can aggregate it or you have even more computational power. So far, not so new. But when we look at these kind of architectures and looking at the oldest devices and all the qualifications that we want our developers to enable to create. You might come up with a situation that looks a bit like this. So you have something like a wolf pack of devices really heterogeneous you're not really sure how they interact if they interact. So, basically, when you think about edge management you want to go from a situation like this to this. You're still if you really get your genius devices on this case, docs but they still all behave well and kind of have a common interface in which you can interact with them. So, how do we get to support to the situation. I would say you need to answer a couple of questions. So the first question is, how do I actually manage my connectivity to the edge. So, the connection between the on premise devices and the edge devices then the cloud. The next thing is, how do we record the device state. So how do I know which state my device is actually in without always talk to the device directly. The next thing is, how do I know what my device is actually capable of doing and what is the data that can deliver to me, but also what is the data that I can send to this device. Not least, but this was a really important is how do I manage the actual firmware on the device. So when we're talking about edge and also it managing the software state, it's becoming more and more important. So coming to the first topic, or as I would call it connectivity to the cloud. So this little fella here is more maybe on a mindful connection to the to the cloud, but of course, in the technical world wants to be a reliable connection to be sure that your data is coming to the cloud in a more efficient way. So one project that I want to highlight for this is the so called eclipse owner project. Hono is following you have a number of things flying or lying or moving or whatever around. And they all are really heterogeneous and may speak a couple of different protocols like HTTP co-op or even a custom protocol. I want to connect these devices to back end solutions. And this is done by Hono by translating between the different protocols into the MQP 1.0 protocol. So the business solution would then connect to Hono or to the so called northbound interface of Hono to MQP 1.0. So if you take a more deeper look into the architecture which we will do on the next slide, you'll notice that Hono is actually a microservice architecture. So that's a good thing in a way that you can replace each of these microservices with your own implementation. And so this way we will go from left to right to get a deeper understanding of that. So first of all, we have the devices that are only connected or only talking to the adapters, so called protocol adapters. So this way you have, for instance, an HTTP adapter and you can scale it anywhere you want since you just need a middle instance of this adapter. This adapter then is strongly cut with the so called device registry to check that the device actually authenticated and allowed to communicate with your whole messaging system. So this way you make sure that no third parties are inserting any messages in your network which might be confusing or even be too, let's say, or crucial outcomes. Once the protocol adapter has translated your message, it gets into the MQP 1.0 messaging network, where it then can be retrieved by the business application. So to do that, we have what I've done here for you is having an instance of Eclipse Hono in the cloud. And what I will do in a minute, I will skip this demo at this point but you will see why in a second is you need to do the following three steps. The first thing is you need to create a tenant. So Hono is actually multi tenants capable. So you can have separate your traffic for different tenants. Next thing is create a device on that tenant. So for each tenant you can create a number of devices which is basically just the representation that the device is there. So what you need to do then is to create credentials that are connected to the device. So each device can use this set of credentials to connect to the Eclipse Hono instance. And the interesting part here is you can even have multiple credentials. So this way it's possible that the device is actually sending data on behalf of another device by using the credentials of the other device. It's really handy if you have more IoT devices connected to your Edge. Another word about the communication. So what you really wanted if you're more into protocols is, okay, how do I do all this different protocols, maybe going back to the initial slide, like H2P being a request and response protocol or MQTT where you can subscribe and just, yeah, wait for communication. Subscribe and response. So the answer here is that it actually has its own set of ideas how communication can look like separating it into these three types of messaging. One is the telemetry message. And the other one is event messages. Both are only going from the device up into the cloud. So what's the difference here for telemetry? You have a different quality of service typically than for events. So for events you would use it for critical messages where telemetry is more, hey, I got a new sensor value. So in this case, telemetry, it can happen that it might be dropped. So it's not so crucial if it gets dropped. That's why more of the difference here. So the quality of service. So hearing this, you might wonder, okay, but what do I do if I want to communicate to my device, to my Edge device, then you would use the command and response. So hearing of the protocol can be a bit more tricky, which I will show that in my demo in a minute. So from Honu, the question is, how do I get a device twin? I was actually trying to find a good picture for device twin. This is maybe the closest I could get. So because the idea with the device twin is that you're not always talk directly to your device, but you actually talk to an instance, for instance, in the cloud, that is representing the state of your device. So every time you want to make a request to your device, you only talk to this device twin and not directly to the same device, which makes things a bit easier for the whole communication pattern. And now it's not a surprise. There's a project for that. Name is Eclipse Tito. So with Eclipse Tito, you can exactly do this device twin. And as you can already see on this picture here, it has a good interaction or integration with Eclipse Honu. So what Eclipse Tito is doing is provides APIs to the devices, and APIs to so-called backend applications or mobile or web apps. So, but when looking at this, you might wonder, okay, what's the difference with Honu? I mean, I've seen already APIs for the device and APIs for the backend, so what's the difference? The difference here is that Tito is actually able to store the state of the device or the sync. So if you look into the architecture, which is depicted on the right-hand side of the slide, you would see there's an instance of MongoDB running, and this MongoDB stores your device state. So every time the device is changing its date, can send this to Tito, and Tito will store it in the database and mobile web can then come at any point in time and request this information. And it doesn't need to interact directly with the device. That's one benefit. Another benefit, obviously, is that you have HTTP and WebSocket APIs also directed to the mobile applications. And these APIs are also built based on the features and properties and attributes that you assigned to the digital twin. So this is more or less generated automatically, which is also not a feature which you will find at Honu. Another thing which is really important when you consider integrating your IoT or Edge device into a more broader architecture is also who's actually able to retrieve this information. And this is also done with Tito because he can define really strict and fine granular policies on who can read and who can write to a specific sync and who can send messages to which sync, which is also really important when you have more complex scenarios. So this about Tito. That's getting to a demo. I mean, everyone loves demos. Let's get into an example. But before we do that, let me maybe first introduce to the example that I sort of. So let's say we want to control a more complex heating system for the big office building. And actually from at multiple locations, we will only model one location but the example could go beyond multiple locations and each location has a set of rooms where you want to eat. So what you will do is you set a temperature for the heating. And you can also send a message to make like really improved heating. So with that, welcome to the terminal here. I'm going to get prepared for you as a small goal programs that will interact with our instance of hono and Tito. Before we do that, let's show what we've done. So there's a Kubernetes cluster running. We have all these containers are running. So for instance, here we have the device registry from Then we have a couple of Tito services running in containers or ports, and we have also the HTTP adapter. And these are basically the containers that we will interact. So what's the next calls and minutes. So personally, we have to do is do the cloud in it. So what we've done here is we created a tenant and eclipse solar with the tenant ID my company, and the response was surprise surprise, we've created a 201 with my company. Next thing is we will register the device. Yeah, so the device was a device and the my company Berlin has been created. Seen because of the response status 201. So the next thing we have to do is to create the credentials. Now we have set an authority, okay, so Berlin also. And we have also created password which is, we're here playing password of device password. So, yeah, nothing fancy and also nothing will be secure but you could also set for instance certificates here as credentials but for the sake of the demo. So it's simple. So the next thing is, which is this is actually kind of complicated thing is connecting it's solar with eclipse ditto. So if you remember the slide with the integration ditto will connect to the one point a MQP 1.0 endpoint of a clip solo. So we need to configure how ditto to actually use this endpoint and also that it knows what to do with the data that is coming from there. So ditto has the capability to met met data coming into onto other data in case you have different data formats in the system coming from the devices in your backend. We'll do that. So there's actually return the whole configuration so I won't go into this but you can see there's a lot of things that you can set. Then the next thing is now we move on to configuring ditto. So we will do now a set up a policy. So policy is something that you can reference later and which tells who is able to access which kind of information. So in our case we have the policy which grants a read write on basically everything. And the name of the policies, you can see it here is my company, my policy. And then you press enter to create this thing. And what we have now here is we created a thing it has the thing ID my company balloon. So namespace and ID. And now it's getting interesting it has the attributes that the location is in Germany. And it has a feature lobby, which is now a case representing one room, which has currently no value because we don't know the temperature there the same with the offers. So one of the interesting things we have properties where we don't know the value. But we also can set desire properties indicating to the thing that we want this to be realized in our case we want to have a temperature of 20 degrees Celsius so sorry for all the American folks. It's this temperature will be in sales. Locations in Germany. So what we've done here is we have now the same set with the desired property and no actual value. So let's jump to the device. So what we've created here is a code for the device. So, and once we run it will see this two options one is selling telemetry and other things to receive. So as you will see, send some telemetry. So what it's doing now it sends a telemetry message to Hono, and then from Hono the message is sent to do and use to update the state of the same. So when I run this. Formation is not the best but what you can see is it sets the path of the feature office properties value to the value 18. So how do we do we check that it's actually worked. Yeah, guess it I don't come. This doesn't come in unexpected so I'm prepared. We have a search script, which is has a name go run cloud go. We have multiple options and one is simply to request the same information. And so we get our information from the same this is pretty similar to what we've got back once when we created the same difference here now is that our office property value is actually 18. So we managed to update this value from our same. Which is this is pretty nice but the question is, what is what happens if I want to do it a bit more say interactive. So, want to make sure that devices actually receiving this information by now and not once checks for the device stage. So one thing is that the token send events once any value or property changes. I won't show that here but what I will show you is you can also send messages messages directly to the same. So this way, did you will take care of delivering the message and our special example actually did you is delegating this to Hono. So, the question of course is how do we get a command. So HTTP to device which is kind of different because you can push the data. So, in case of HTTP. We need to do a get request from the device and then piggyback the response in a way to send the command. So how is this done. Have again our device and we will send it in some kind of receive mode by sending setting a header value of Hono to CD to a specific value and this will indicate to Hono that you can send a command back to the device for the next couple of seconds which is configured in the this is exactly what we do here. So we sent another telemetry message now again this value 18 and wait now for 60 seconds for a message. So on our cloud send the message. And what's happened here it's happened rather quick. So first to the cloud. It sent a message that's saying okay let's do start quick heating. And so our example would be that the thing has the heating system is heating pretty quick for the next five minutes or full speed or full power. And we already got the response back from the same saying hey okay I got this and I will do that. So start quick eating is true. So let's go to the device what happened here. Yes we really sense the telemetry message. Then we got the message saying okay. Please do this and the response so that's why the response status is 200 and we have our response contains the message. This case you just have to believe me this is kind of in the program. So with that, I will conclude the demo for now and jump back to the slides. And what we've achieved so far is to deal with the actual data. So we have the whole device for doing all the different requests and responses moving data around saving the device state. But sometimes this is not enough because we still don't know which common commands actually can send so our device we don't and we also don't know what kind of data we can expect. To go back to our dog. Sometimes we don't really mean not really care about the dog sitting in our room we are more care about what the dog is actually possibly doing and which is also possible to document without having the actual dog or the actual dog going back to our edge and a lot of tree. And this is something that we need modeling for this. So, when people don't have a dog at hand they start to pay in front. And when people don't have the edge actual edge device to work with say start to model the capabilities. I mean this is really bad analogy but maybe stick to we as me as you know or gets a point what I'm driving it. And because for modeling. That's what I want to talk about the next minutes. There's actually two approaches that I want to show you one is the eclipse water project. And you guess by the name eclipse again that is developed not so far away in a sense from eclipse digital so there's some loosely covered integration going on and this digital you can actually model the capabilities of your IT devices is where it is. And then integrate this different things, or different cloud services or different services or generate stuff called it's points of the Java to interact with so no, or in, even as Arduino. And what you do here is you say, okay, this is kind of sense of values, then your stuff could you only need to integrate how to read the actual sensor. So the actual hardware driver in its sense. Cool thing about water it had an repository that you could store all these different models so you could really easily reuse it and reference it. Recently this has been moved to GitHub so there's some type change there but the models are still available. What I want to note is you're still model the capabilities and data from a single device is really device centric and the whole modeling approaches coming from the device or device centric modeling approach. So the kind of a new kid on the block is the so called bum meter model. It's has been published as part of the open manufacturing platform, which is also kind of a new activity going on in the manufacturing domain to align some activities and also do some open source work together there. The latest results is this bum meter model. So, here, again be able to model the data and the capabilities of our devices, but they are not coming from the device side will be more coming from a modeling of so called digital twins. I haven't said the word digital twins so far for a simple reason because there's so many definitions out there, these bonds I heard, and it really depends on the domain you're in and who you're asking. So that's, that's kind of difficult topic but the way we would model or define digital twins here is that we have a digital representation of physical asset. So, the same machine, for instance, and the interesting thing for this asset is it may have different aspects. So, coming back to our eating example we have maybe the aspect of the current mode of operation. So, which, which temperatures in the room which how quick are we heating what kind of energy are we using, are we using intensity 12345 I'm not an eating expert. Or, but there's also another aspect that you might be interested in this, which is here who manufactured the seating system who was actually the one putting it in place who's responsible for the maintenance. So, two completely different aspects of the same aspect. So the twin was likely would also represent both aspects. And to keep it short, the bonus doing it just allows you to model each of these aspects. What does this mean it defines with an adf set of elements, which you can use for your model to use to have your own model based on this meta model. And how does it look like in practice. Yeah, more practical. It's not really practical to have more an example. On the one hand side the real abstraction of the meta model based on the meta model you can do your model. So, now this example be a model, the aspect of movement. So seeing that can move around it's an injury a rubber to car bicycle human everyone can move. And this can be modeled in a way okay we have is moving as volume value and the position in 3d space. So the actual implementation and this is where, for instance, come to the level of digital is the Jason that we get out of here so we have a Jason is moving with a volume value and the position x y that presenting representing the position in the 3d space. So, but our digital trend, then would look like, could say okay we have digital trend which has this the following aspects, the aspect models online somewhere here, and go to this address to get the actual data. So that's where also we have then the model model based on the fun aspect meta model. And maybe another cool thing that you can mention here is that it actually allows you to move your domain knowledge out of the application into the model. What you often do is your friends if you implement an UI for the data coming out of the edge or your edge devices you know from your domain expertise. Okay this data is somewhere between zero and 25 and it's something in degree Celsius and it is representing my room. This is because I just told you on the, in our slides, because I'm the domain of expert of our special heating system, but this way when we model this with bum, the software is able to execute to extract this information and already built this UI based on this information so that's having, for instance having a via access which is only produce up to 25 and labeling the access. Maybe so much about data modeling and I really have to admit this is more like X course when talking about edge devices or more. It's a separate topic but I think all the lines together. Once we want to bring our edge or edge management into a broader perspective of moving on managing the data coming out of there. So let's go back to our edge device so the actual device level. One thing. I guess our devices come how I wouldn't say broken because it doesn't really fit the picture but has some issues put it this way and I can just like around or maybe some security issues which of course it's not so easy to depict the doc picture. How do we deal with that. One thing is the firm on the device. This is the one thing and the other thing is how do we manage that. And this is where it comes into play, which is actually quite a handy because what do it keeps or maintains an overview of your software state on your devices. And has some management API is to get this information also really handy management to allow it to interact with your eye. It also has connections to artifact content delivery networks with artifact content networks that has the capability to store your software somewhere and this is one of the coolest features when you ask me it has the capability to do a roll out management. So I've only talked about the upper API is the real magic isn't the lower API is because here you can each device can either directly some Federation service to the device management Federation API to get the information. Hey, there's a new update and please download it from this location. The last thing which is not a drawback but what you have to mention here is the device still needs to do or perform the update by itself. So the way Hogwarts is doing this it has some something that they call distribution set so in a distribution set you can combine a set of files that you need for your update or your firmware state. And then the device gets information okay up download this distribution set and perform the update the way you normally from updates and this is really specific to the application to the device. So it could be the new container it could be the whole Linux subsystem it could be just a package so I guess you have more imagination than I do, but this could be. So this, as I said is specific to the device but what Hogwarts is doing it keeps track of whether this was successful or not. So the device can signal hey this was this update work and I'm now back up and running. And this allows her to do some kind of campaign management. So, for instance, you can say I have a couple of devices it's the animal devices and have the update and really show it works but it's a really small option that doesn't work. So I say okay maybe just roll out to the first 10% and once these 10% of the devices all work, let's do it to the other 90% and with a click of button, how could it's doing that for you. To this point, I've mostly talked about software to managing the edge, or even to model it or to support the data flow from into the edge. But another really important aspect is actually the operating system on the device or on the edge device. And in many cases, this is Linux. So that's why I also want to spend a couple of minutes on the topic. So, when you develop a traditional edge device or something is more like an embedded device or somewhere in between this classical embedded device and the more computational powerful edge device, we end up in a situation that is depicted in this slide. So you have a better software project which is tasked with finding the specific software for your specific product or specific device this case. And you have a couple of layers that you have to fulfill you first of all you need your hardware and also support for the hardware so you need some drivers, then you need the operating system. And then, especially in this edge cloud continuum and architectures you also need some add on software and runtime services, which allow to the edge device to become part of the infrastructure. So this could be a client for Ditto for instance, or direct client for Hono, or it could also be the opportunity to execute containers which is really big topic also for the edge. So, for instance, this Ditto you not only can control the actions and data coming from to the edge to the IP sensors but you could also trigger the execution of software components like containers on the device or to some other more management infrastructure management related topics which is also in the field of runtime services in this case. Another thing which sometimes tends to be forgotten but it's also really important to enable the other layers is of course tooling. So, coming back to our embedded software project they need to find solutions for all these layers. And luckily or happily or it's a good thing. We have a lot of different projects and solutions out there. Many of them open source, maybe most, but also some proprietary solutions. And the task here is to pick the right one from each of these solutions and to align it in a, let's say in the right order with not only fulfilling technical requirements but also a lot of non functional requirements as I would call them. So for instance you want to keep track of the vulnerabilities. So you need to make sure that you know which kind of software components are in your software stack you also need to know this one to fulfill the license obligations. That's another thing. Also when you put all these things together you want to make sure that they really work well together on your, your hardware. So, you see there's a lot of things that are not part of the actual solution but that you don't require to enable use. So, this whole software stack and receive potential for coloration on the side. And that's where we see the potential for missing link, which something that the working title could be referred to as industrial great Linux. So, it's not a simple Linux distribution is many good for really good ones out there already. It's more about the idea to find some certain elements in the upstream project world in this different layers that I just mentioned before, to be really aligned. So that if working software stack which could also be provided by the provider or source provider or distributor in a form like a kind of ideal pro. But this, again, is not just about technology but also about these other aspects for instance really big topic could be the shared testing to work together on this setting up and deciding on the testing infrastructure. And for different devices and different device classes. And with that. If you are more interested in the more details on this side we have a whole talk during this conference, which is a case study and on the use of Linux or in heterogeneous and just for devices. And if you're interested in that I really recommend maybe watching the recording of this at some point. Where are we are from here. So how do we put all these things together so that we end up in a situation that you can see in the picture where all our docs or devices and our technology are working well behave together in the same direction to the same common goal, the way we wanted. So let's go back to the challenges that we had. So if you're looking at our picture and also the challenges, I think, listening to the talk. You, we can come to the conclusion that for the connectivity, one option is to set go for a clip solo. And then connect this with tips digital to maintain a good overview also device state to not always need to directly talk to not always have the need to directly talk to your device. So we're able to manage this from the cloud in the cloud. Once you have this whole data type and it's not a real pipeline. It was infrastructure set up. We also might be interested in modeling that we are representing the device data and capabilities. So based on the question, whether you want more, the model device focused on with more digital twin focused you can go for export or the own pay meta model. And you also want to manage the firm on your devices and for that, you can go with the clip socket. And with that, I wanted to leave it with that and want to open the floor for questions and want to thank you for joining my session. And in case you have any questions, comments, other ideas, feel free to contact me, maybe on GitHub. If you have any questions or comments or otherwise we can close the session. Thank you.