We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Building IoT solutions with Eclipse IoT technology

00:00

Formal Metadata

Title
Building IoT solutions with Eclipse IoT technology
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The IoT working group within the Eclipse Foundation is a joint effort to develop generic building blocks for creating IoT solutions. As of now, they host over 30 projects, which address different aspects of the realization of IoT use cases. The vast number of projects allow the design of tailored IoT solutions but bear the risk that people get lost in the wide range of projects. The recently introduced project Eclipse IoT packages will help here. It aims to provide pre-bundled software packages for the IoT. In this talk, we are going to introduce the work of the Eclipse IoT working group and showcase selected projects with the focus on how one can use those technologies to build custom domain specific IoT solutions. Specifically, we will focus on the message hub Eclipse Hono,, the digital twin solution Eclipse Ditto, the update manager Eclipse hawkBit and Eclipse Vorto a description language for IoT devices. We further plan to show how one can combine and use the projects in a sensible way within the Eclipse IoT packages project.
BuildingInternet der DingeInternet der DingeBuildingComputer animation
Internet der DingeMicrocontrollerFront and back endsInternetworkingMultiplication signBitMobile appPeripheralCASE <Informatik>Computer animation
Food energyService (economics)CASE <Informatik>Front and back endsDomain nameType theoryComputer animation
Computing platformGeneric programming2 (number)Level (video gaming)Type theoryInternet der DingeComputer animation
Local GroupFocus (optics)Software developerPoint cloudComputing platformDifferent (Kate Ryan album)Group actionFront and back endsInternet der DingeSoftware developerFocus (optics)BitComputer animation
Point cloudMessage passingCommunications protocolConnectivity (graph theory)Component-based software engineeringDigital signalRepresentation (politics)Server (computing)Connected spaceMobile appRepresentation (politics)InternetworkingProjective planeSoftwareCentralizer and normalizerWeb 2.0Set (mathematics)Greatest elementInterface (computing)Communications protocolAsynchronous Transfer ModePoint (geometry)Computer configurationCartesian coordinate systemFitness functionState of matterMultiplication signCASE <Informatik>Twin primeSystem callDatabaseDegree (graph theory)Source codeRun time (program lifecycle phase)Different (Kate Ryan album)Data storage deviceConstraint (mathematics)Food energySlide ruleFigurate numberMessage passingPoint cloudWindows RegistryAuthenticationBitComputer animation
SoftwareData managementComputer fileVideo gameProcess (computing)Field (computer science)Distribution (mathematics)Control flowError messageSoftwareRepository (publishing)Scaling (geometry)Data managementConnected spaceComputer animation
Host Identity ProtocolData managementSoftware engineeringInternet der DingeDigitizingComputer animation
Internet der DingeHost Identity ProtocolWeb pageOpen sourceLine (geometry)Group actionInternet der DingeConfiguration spaceComputer animation
Internet der DingeINTEGRALProjective planeSource codeInternet der DingeGroup actionStatement (computer science)WordComputer animation
Internet der DingeGroup actionInternet der DingePoint cloudWordComputer animation
SoftwareBitConnected spaceCartesian coordinate systemPoint cloudScalabilityMatching (graph theory)Data managementFitness functionSet (mathematics)Gateway (telecommunications)Computer animation
Physical systemSoftware frameworkService-oriented architecturePhase transitionFiber bundleSystem programmingPoint cloudError messageCASE <Informatik>SoftwareService (economics)Computer architectureTime zoneSet (mathematics)BitSoftware frameworkDemo (music)Domain nameProjective planeLocal ringPhase transitionComputer animation
Software frameworkSystem programmingLocal ringInternet forumArtificial neural networkExecution unitRight angleGoodness of fitSoftwarePasswordSoftware testingWindows RegistryMessage passingComputer animation
Network socketJava appletCorrelation and dependenceVertex (graph theory)Core dumpVortexConcurrency (computer science)SynchronizationThread (computing)Execution unitClient (computing)Spring (hydrology)InformationPrincipal ideal domainBootingProjective planeMessage passingCartesian coordinate systemComputer animation
Loop (music)InformationDew pointExecution unitIntegrated development environmentClient (computing)Spring (hydrology)Principal ideal domainCone penetration testThread (computing)Message passingInternet forumCapability Maturity Model IntegrationMessage passingMultiplication signComputer animation
Software frameworkService (economics)System programmingInternet forumForm (programming)Maxima and minimaPoint cloudFacebookOpen sourceComputer animation
Transcript: English(auto-generated)
All right, thank you everyone for attending this session. I'm Sven Jozewski, and I will introduce you to how to build IoT solutions based on Eclipse IoT
technology. So there's the Eclipse IoT Working Group, and I will tell you what's going on in there. So I think all the time when you come to building IoT solutions that have a bit larger scale, you come up with a problem like this. You have either some IoT device, which is like a really classic device,
and a sensor and some microcontroller. Or it can be a really complex device, like in this case a boat that puts all the internet cables into the oceans. And as you can already see, this is pretty heterogeneous on the sink side. So if you build your IoT solution, you might have your thing already present, the physical device.
And you might already have a cool idea for your app or my application, one, two, whatever. So the next question would be, OK, how do I build my back end here? So in this case, it's just a big question. And what people tend to do, especially technologists, is, OK, I have this cool device A,
and I just built my own back end and my own services on top of that device. And when I'm done, I just do this next thing for type B. And then there's a cool guy on the other end of the world, and he says, OK, my device is so special, I will build my own solution for my own stack for that device or for that use case. It's also maybe that you have different domains. Let's say the automotive guys say, OK, my problem is
completely different than what energy people would say. But in the end, at least my idea or our idea here is, actually, most of the problems are kind of the same. And I will get into the type of problems in a second. So the idea is maybe it's better to have something like a generic IoT platform. I guess I'm not the first one.
And we won't be the last one in this stage telling you this. And maybe it's just the 14th platform. Maybe it's the first. I don't know, but just take it as an idea. Since this is FOSTEM, I won't tell you why it should be done in open source, because I guess we all kind of agree on that model for such a generic platform.
So the question is, what is Eclipse doing in this field? So Eclipse, as you might all be aware, there's the Eclipse Foundation. And within the Eclipse Foundation, there's a special working group dedicated to IoT topics. So as you might guess, the Eclipse IoT working group. We have over 300 developers in there.
And there's more than 30 projects. And I won't go into all of them. And there's a lot of different sides and aspects of that. But you could say they either focus on the device side, on gateways, or on the IoT backend. And if you look at my introduction, my focus is clearly the IoT backend. That's also where I'm working off, and where I will tell you a bit more in the next minutes.
So what could be the device backend? So remembering the previous slide, it was more like a 10,000 feet overview, where we just have a question mark in between. So what aspects do we really need to tackle? And if you go a bit lower, a bit closer to the cloud,
I would say the first thing is the entry point to the cloud, or to the central data infrastructure. So again, we have all our heterogeneous devices on the bottom. Maybe our cool, fancy embedded device speaks of protocol A, let's call it MQTT. And our more special device has maybe MQTT or co-op,
or maybe your really own protocol. So the question is, how do I cope with that if I just want to create my own application on top of that? So that's where you need to message infrastructure and also the device connectivity as the entry point to the cloud. So the second problem I see is if you have the data in there,
you somehow need the digital representation of your device in the cloud, because every time you talk to your IT device, you don't want to make the actual call to the device being somewhere in the field, which has energy constraints and maybe it's not accessible all the time because it only wakes up maybe once a day. But if you have your progressive,
super cool reactive web app, you want to have those data all the time. That's where you need the digital representation. And another thing which is really important and this thing often forgotten in IT deployment is how do I actually manage the software running on the device to be sure that I'm able to roll out updates, which is especially in commercial setups, really important.
So coming right into the projects. Again, as I said, the first point would be the connectivity. And within the IT working group, we have the project called Eclipse Honu. And Honu is exactly doing that. So again, device on the bottoms, on the bottom. And here we have a lot of protocol adapters, in this case, HTTP, MQTT,
or you can also create your own custom protocol adapter. And it will all be translated to MQP 1.0. So on the northbound interface, so the interface on the top, you will be able to connect your MQP 1.0 application and get all the data. And at that point you don't care anymore which protocol the device actually spoke or supports.
Okay, some people look at this and say, okay, this is pretty cool. I have all these different protocols, I have all these different concepts in there, and now I get a protocol translator, which would be actually pretty awesome. So as nothing comes for free, if you interact with Honu,
they make a certain set of assumptions on, for instance, the endpoints that you can use, so that you still have the option to translate one protocol to this MQP 1.0 in the end. But it's still pretty cool because you can already reuse your existing device. One, another thing which is pretty important about Honu to understand,
it's, as all the projects I will talk in the next slides, it's more or less based on a different set of microservices, and those are shown here. So again, you have the adapters. This time we shifted the whole picture by 90 degrees on the left, and they will send the data to the MQP 1.0 messaging network, and from there you have your business application.
So in a nutshell, it's what I just said in the previous slide. What I think is really important to figure in this slide as well, the Honu project puts a lot of emphasis on defining these APIs between the microservices. In that case, it's pretty easy for you to implement your own protocol adapter, if you have your own protocol, or maybe to replace the device registry
with your own solution if you have a more centralized approach for that. And of course, the same applies to the authentication server. All right. So again, what many people say, especially if they come more from the internet side of IoT and are more used in protocols like HTTP or in web sockets, they're like,
okay, MQP 1, I can't really maybe integrate it into my application, or I don't want to do that. And also, you have some concerns of how to actually connect to the device and get the data out of that. And that's the digital representation that you need, and that's a problem solved by Eclipse Ditto.
So again, on this picture you see, we have the bottom side, getting the data from the devices and on the top side or the northbound side, because you might paraphrase it, you have the connection to the actual applications, or if you come back to my previous picture to your IoT solution or your app one or two or whatever.
One thing that I really like about Ditto, it has two modes for accessing the data from your device, which kind of differ in a way. You can either have live modes, so if you request the data, you more or less get the data with the current state from the device,
so the device should be available for that. But if that doesn't fit your need, which is actually pretty often the case for things, I mean, they're not always connected, maybe if they move around, or I guess you know the drill, then you can also have a so-called twin store where you can get the last value from the device out of the database.
So you don't need to create your own database, think about all this connection, because Ditto will source it away for you. So this was more or less a stack of, okay, how do I get my data out of the device, and how am I able to get commands to the device? So it's more, let's say, the runtime of the IoT solution.
But another problem which you will cope with is how do I actually handle the software running on the device? And this is something where Eclipse Hawkwood was founded or created on to solve that issue, and in the purple box, you basically see what the main features are here. So you have a repository to store your software
for your device, which is obviously the first step for doing that. Then you have some connectivity to CDNs, so if you have a larger scale deployment, you might use that instead of storing the data in your own way. And the coolest feature, at least to me, is the software update and rollout management.
So imagine you have one million devices out there, and you have a new update, and you want to make sure that if you update them all at once, that you don't break all million devices at once if there's an error in your software. So you can say, okay, let's start with the first 10%, and then if only 10% of those devices fail,
or more than 10% of these devices fail in the update, I should maybe look into my update process and the file that I'm distributing and can stop the whole process, which makes life a lot easier instead of having one million brick devices out there in the field. All right, so coming back to where I just started,
so how could the IoT solution, which is still pretty generic in this way, could look like based on those Eclipse IoT technologies? So you have the device connectivity, which would be soft, well, we can use Honu to do that. Then you have the digital device representation,
yeah, more or less solved by Ditto, and you have the software management that is where you get support by Hawkwood. So when it comes to the question, okay,
where do I get that? I mean, the first step is with every open source project, you just go to the GitHub page and maybe download the release or the latest code, but then you will get maybe Honu somewhere, you will get a Ditto somewhere, you will get a Hawkwood somewhere, but you still need to do a lot of work to actually combine those things. And in this slide, I just drew a line,
but it's actually some, yeah, involves a lot of configuration to have this tiny line that I have here on the slide. So people from the Eclipse IoT working group also notice that this is a lot of complexity, especially for people that come as new users to the project. And so that's why they came up with the new Eclipse IoT packages project.
So shout out to Jens Reimann, for instance, who did a lot of work on pushing that. And the mission statement here is pretty clear. They say, ITU packages is an effort for the Eclipse IoT working group to create easy-to-deploy Eclipse IoT-based end-to-end scenarios on top of Kubernetes and Helm.
So actually, I can't really add much to that because that's exactly what they do. As of now, they have defined one package, the so-called package zero, and surprise, surprise, that's the package I've just shown you based on Honu, D2, and Hogbit. And maybe one word of warning, they're in a pretty early phase,
but as of now, I would say it's a good source if you want ham charts for all these projects, but there's still some work to be done for the whole integration. So it's not like Helm install, I'm done. But hopefully, we kinda wanna wait for that. Okay. At this point, this is kind of like
building your cloud backend, but being an open source, there's not always one solution or in technology in general. And I already mentioned there are more than 30 projects in the Eclipse IoT working group. That's why I would like to give some minutes to add some words on some other projects that are there
because two projects that also work together pretty well and personally, I think it would be a fit for a new IT package is Eclipse Core, which is a software that you can run on your gateway and which solves a lot of issues. First of all, abstracting your device hardware, but also making the connectivity to the cloud. And kind of like the match on the other side,
on the backend side, would be Eclipse Capua, which has some of those problems like device connectivity, device management in one box, so more like one application and not in a set of tools. So if you're more like in a one-stop project, that's something you might check out,
but I think if you really need some flexibility and scalability and the chance to configure it for your use case, you also should take a look at Tonu or Hogbit. So it depends a bit on what you're looking at. One project that I would also like to mention because this is something that might come up in the future
it's not there yet, so we're currently in the proposal phase for that, but it's already a new approach. It's the so-called error edge framework. As I said, it's in the proposal phase for an Eclipse project, but it's already out there on GitHub. And it's based on a publicly funded project, or actually a set of publicly funded projects
in the industrial domain for solving industrial IT solutions or problems. And what they try to bring, I guess it might sound a bit like a time machine, but still talking about industrial use cases is to bring the concept of service oriented architectures into industrial use cases.
And then which this by another concept is they call it so-called local clouds, where you say like all the services in one local cloud, it's like in the same network on the same, it's a zone as you could call it. So if we look into the industrial use cases, it's easier for them.
So you can make the choice, okay, I want to access some service that is actually on my shop floor or in my factory, or I can access a service that is somewhere totally else. And that's something that will be instructed by Arrowhead, but it's something that will come up in the next years.
All right, so I actually see, I already still have three minutes left. So I have a small demo prepared. I hope it works. I won't set a red nose as my previous speaker, but I kind of feel the same way right now. Let's see. So what we have here is,
okay, let me see, it's okay. I want to showcase Honu here. So what I will do is I create, wait, a new tenant, let's call it Fosten 4. You see I already made some previous tests on that.
So what I do now is I create a tenant. Let's see if the network works for me. Sounds good. Next thing I will do is I will create a device that will talk to Honu. In this case, it's my device one. And the tenant, of course, should be tenant four.
There we go. So now what we did, we created the device. So Honu, or the device registry in Honu, now knows, okay, there's a new device out there, but we still don't know how to authenticate the device, so we have to set the credentials for that.
It sounds also pretty promising. And what I do now is I try to send a message to Honu using that device. So what I do is for the authorization,
it could also use a certificate, but in this case, I have credentials. I say my device or my username and my password at my tenant, and whoops, it won't work. In this case, it's expected behavior. So the question is why is this expected?
So the reason is there's no one listening on the other side. So if there's no one consuming the data in Honu, you won't be able to send data. So what we need to do is we start a consumer for that. That doesn't look promising.
So this is also consumer or an example application that you can download from the Honu project. And it won't work because I have a typo in there. It should be this.
So it was created. And when I try to send the telemetry message again, it says accepted, and somewhere in here, you see there's a new message arrived. So basically what you have now, you know that the temperature, you can see it here,
is 15, just a random value that I just sent with Pulseman. All right, that was just in time. Yeah. We'll have to cut it off here. So questions, or otherwise, I will just thank you for your attendance, I guess. Thank you. Thank you.