 OK. Hello, everyone. Thank you for coming. So today, I would like to present, give an overview of what it's like to create an application, like a full-cycle application, the different layers of an application using Adjects. And for this example, we used an automotive IoT app. And we used Raspberry Pi. So Malini and I, we created a sample automotive app last year, all in Python, on the Raspberry Pi to see what it was like to create an Edge-based application. And then we started working on Adjects, Adjects Edge Computing Framework. And I decided that I would recreated this application with Adjects to kind of show the process, show what it's like as a developer to recreate this application. So today, we'll talk about what it's like to create an Edge-based application, so your architecture. Then we'll talk about the Python sample app that we created last year. Then I'll give you a quick intro to Adjects Foundry. We don't want to go too deep into the mechanics and to the internals of Adjects Foundry, because I really want this to be a user from a user's perspective. And then we'll go deep into the full-cycle app, the different levels, the different layers, and what it was like to use a Raspberry Pi. And then I'll talk about the future work. So this is from the project's website. Edge has been historically kind of segmented. A lot of proprietary work, a lot of people working on their side in the company. So the nomenclature and the terminology has kind of been non-standarized so far. So when we talk about Edge, we really talk about everything that's in this box. So that could mean a lot of things. That could mean some people think of Adjects devices. Some people think of it as bigger servers that are closer to the data center. So as an effort, in order to make this a little more standardized, this project was created. It's called the Edge Computing Glossary, Open Glossary of Edge Computing. It's on GitHub. It's under LF Edge. So it's supported by the Linux Foundation. And it's really cool. You can open a PR. You can discuss. They have weekly meetings where you can kind of discuss the different terms and kind of argue the definition of different terms. So yeah, so the automotive ad that we created, it was very simple. We had a Raspberry Pi. We wrote an application on Python in Python that would read from a GPS. Just read like geocoordinates. And read from an OBD sensor. The OBD sensor is the little dongle that you plug into your car to get all kinds of metrics from your car. You can get a lot of data. You can get your speed. You can get the engine, like RPM. You can get your fuel level. You can get all sorts of stuff. So we gather all that data into the Raspberry Pi. And of course, the premise of Edge Computing is you have a lot of data. You don't want to ship all of it up to the cloud, right? You're using a lot of bandwidth. So the idea is that you can aggregate all the data in your Edge Gateway closer to the data generation, filter it out, and then only send the necessary event up to the cloud. That way, you use less bandwidth and less data. So yeah, so we have three layers here. Devices, Edge, Cloud Endpoints. The cool part about this proof of concept is that we could serve three different endpoints through one Edge Gateway, right? So you could have three different applications, three different use cases. So yeah, so now let's go into EdgeX. It's supposed to be hardware OS agnostic, any kind of OS. I run it on my Mac, natively on my Mac OS. Obviously, I ran it on the Raspberry Pi. You can run it on X86. Dell sells those big Edge gateways that you can obviously run it on. Plug and play, so it's virtual microservices. You can replace and replace with anything that any services that you would have built internally maybe, your own rules engine, your own filtering system, your own devices, obviously. You can run them as containers. We have some Docker files you can use. You can run them as Snap. Snap doesn't have the right, we haven't built a Snap for ARM64 yet, so you can't use it. You're not able to use it on Raspberry Pi. And you can also run the Go binaries. But in the case of the Raspberry Pi, we don't have a lot. I mean, it takes a long time to build on Raspberry Pi, so not recommended. It's under the LF Edge recently, recently announced. And it's Apache 2.0. So this is the image that everyone uses to kind of describe the project. The core services, I won't go too many details, but this is where your data lives. They send the commands. They know the metadata about all your different devices. And then southbound, south of this. So when we talk about southbound, we talk about devices. We talk about anything that's closer to the data generation. So you can create your own device services. There's an SDK called Device SDK. There's one in Go and one in C. And there's a lot of examples you can use for any kind of protocol that you think of. There's BLE, there's MQTT, things like that. And there's a lot of examples you can look at to kind of get started. And on the other side, upstream, not upstream, I'm sorry, northbound is when you go to the cloud. And we have export services, and there's a new SDK that's about to come out during the next release that will help everyone build a pipeline up to the cloud. All right, so a full stack app. So like I said, three different layers. The edge being in the middle, that's where your gateways are. That's where EdgeX will live. In the southbound, the device layer, all the devices. So like I said, you have to build your own device services with the Device SDK. That device service will live on the edge with EdgeX. And that's where all the data is going to come into play. And northbound is the cloud. So there's a new SDK that we're coming out with called App Function SDK. And that lets you build a function pipeline that will be the way we call on every single event that's being created from the devices. So let's start with the device layer. Like I said, Devices SDK, there's a series of functions that you have to implement. You don't have to use all of them, but you have to implement them in your go file or C file. So any data that you want to extract from your devices has to come from a command. So you have to define your command. You have to define, for example, for the GPS, we had to define a GPS command that would pull one coordinate. And then you can obviously schedule it to come in every second, every millisecond, every 10 second, whenever you want, depending on the type of granularity that you want. And so you define your command. And you define your resources, your data type. So in our case, we had a bunch of data that was coming from one single device. We had longitude, latitude, speed, and time. So we didn't want to create four different devices for those four different data types, because it came from the same device. So what we did is I defined a resource to be a string. And every time I find a new geolocation, I create a JSON object that contains all those different data points. And that passes the value. But let's say you had a thermometer and you want to query the temperature, then your data type would probably be long, or like a float, rather. And that would just contain the temperature in Celsius of Fahrenheit. And then once that data is being extracted and sent into EdgeX, it's saved into a MongoDB or Redis database, whether whichever one you decide to go with. And you can decide to persist it or not. And then you can, obviously, you can decide to send it to the cloud or not. So this is the GPS dongle that we have. It's we picked this up on Amazon for, I think, $30. We liked it because it was USB-C. Sorry, it was USB. So we could just plug it in directly into the Raspberry Pi. Very easy. So once you plug it in, it actually dumps the data. It's a push device as opposed to the pull device. So you just open the dev slash USB 1 or USB 0, and it will just dump all the different lines. And then you have to look for the specific line that you want. You have to parse it, and you have to convert the coordinates into minute degrees. Yeah, so like I said, we have four different data types. We have latitude, longitude, speed, and time. Time is actually very useful because often, if you're driving around and you have a Raspberry Pi in your car, you're not going to have connectivity. And then in the Raspberry Pi, it's not able to keep track of time without connectivity. So time is great because now you have the time from the GPS device. And we included a mock data file to help people get started because no one wants to buy a $30 GPS device if you're not sure what you're going to do with it. So there's a mock data file that replicates exactly what the GPS device would output, which is really useful for development too. So if you want to get started with EdgeX and create some kind of location-based application, we get a data file for you. And yeah, so like I said, the device, as soon as you plug it in, it starts dumping data. So what we do is that as soon as the device service has started, there's a callback that's called Add Device. And what we do in this callback is I just start a Go routine. I implemented this in Go, by the way, a Go routine that would just read all those lines. And as soon as I see a line that I'm interested in, I pull it, convert all the data, and save it in a global struct. And then once we have the handle read, like once I send a read command, the device service will get that global struct and send that data to the cloud. Sorry, to core data. So let's see the app function SDK. So that's the northbound part. It lets you, it's new. It's still in beta. It's coming out with the next release in November, October. So what it does is that there's a bunch of built-in functions you can use, like some JSON formatting things. You can convert JSON to XML. And obviously, you can create your own functions, which is, or I guess, interesting. Because that's where you can start filtering your data. You can do some interesting analytics of your data. For example, one of the use cases we've thought about is that we want to know when you're speeding, for example. So if we know your speed limit, we can just set a threshold of 65. As soon as we see a speed above 65, we can create an event, see how long it were above 60 miles an hour for, and then send your speed, the time, and then maybe the location, like the start and end location of your speeding. That way, you're not sending any, every single event, because those location events, the way I set it up right now, are, I think, read every second. So it's obviously way too much data. And like I said, those functions are called on every event that you create, which is very useful. And you can create however many functions you want in the pipeline. Yeah, so again, the next release is coming out. The Fuji is coming out late October, early November. We're working on a number of different types of data, creating an export function for all the most popular, the very popular cloud provider. I think right now we're working on AWS, Azure, and Alibaba. So those three cloud providers have an IoT product. And it's usually an MQTT endpoint that you can send MQTT data directly to. So we're working towards creating an out-of-the-box MQTT export. So you just have to enter your credentials and it would send it to your cloud. All right, so now the interesting part, the gateway, the Raspberry Pi. So it turns out it wasn't that easy to install on the Raspberry Pi. Mostly because so far the community has been working with X86 mostly. So there hasn't been that much support for ARM, although we do have, we do build our code, our microservices for ARM64. So most people, when they have a Raspberry Pi, they'll install Raspbian on it. Super popular. However, it's only 32-bit. And EdgeX only works with 64-bit at the moment because, especially if you use the Mongo version, because Mongo requires a 64-bit architecture. So 64-bit ARM, 1 gigabyte of RAM, you will want to create SWAP because if you build, at least my GPS service, if you build it, you will run out of memory. It has ethernet, super easy to split it in, Wi-Fi, Bluetooth, low energy. That was nice when we used the OBD sensor because the OBD sensor we bought was Bluetooth, SD card reader. I used that to flap the operating system, Ubuntu 264, and four USB ports. So the requirements. So like I said, Ubuntu Server ARM64, that's so far the best, the most popular one when trying to run on Raspberry Pi. Make sure you use the 64 one. I used the 32 one. It wasn't really clear which one it was, and it did not work. You'll need Go 1.12, 1.11 should work too. You can install it as a snap. You can install it pretty easily. Same thing for Docker. You can install it with AppGet. So that's easy. However, Docker Compose, like I said, you don't want to use Docker the Docker way because we don't have a snap for ARM64 yet, and it will take you hours to build the microservices from scratch. So definitely use the Docker Compose. However, if you want to install it, you want to install it with pip. And you'll have to install libssl and this libffi before installing Docker Compose, it will fail. It took me a long time to solve that one too. Then we have an ARM64 Compose file too that you don't want to download. Obviously, the x86 images will now work. You'll want to create one to two gigabytes of swap. We had a 16 gig SD card, so I just created two gigabytes. You'll want to download and build the device GPS device. So right now, it's in incubation mode. We have a Ajax Foundry holding organization on GitHub where we're going to hold all the project that will eventually get merged into the main organization. This is pure appending. It will actually merge into the main organization in a couple of weeks. And then you'll want to create your own function pipeline to see whatever you want to do with your data and obviously put in your own endpoints into it. And at this point, you should be ready to go. So I have a quick little demo of how it looks when you build and you run the GPS device. So this was running on a Raspberry Pi on my network. I was an association to my Raspberry Pi on my Mac. And then there's an API call that you can call to see all the readings. So you'll see that in a second. So I'm just showing the running containers. I already call Duck and Compose up the FD ahead. Going into my device GPS, building it. It's a pretty small device. So it's pretty slow build times. So at this point, Ajax is running. All the microservices were started previously with Duck and Compose. And at this point, it's waiting for a device to kind of sign on and register itself and send all the data into Core Data. So that's built. Then I'm going into Command and starting the device service. It's a Go binary. So it's registering. And these are all events. I actually have here a whole log statement every time I send an event of. And I'm going into my browser, reloading. And this API call. Let me pause this. You can just do a get request to this API. It's called events-device-device-device-gps. And then a number of events that you want. And it'll give you all the different events. And it might be a little small here, but like I said, the value, instead of having a single value, I have a string containing the JSON object. So this is longitude, latitude, time, and speed. And that's coming from the data file that we have in the repository, which makes it a lot easier to develop with. So now, the last part. So the last layer that I had in that first slide was the cloud. Obviously, your user, if you want to have some kind of user facing application, you'll have to create a cloud endpoint unless you want to use one of the big cloud providers and IoT products. I just built an endpoint in Flask. It was pretty easy. Python, Flask. I would just have like a put request endpoint. And I would just push the event I was interested in at that time. And then I built a UI in Python, sorry, in JavaScript in React to kind of display. So whoever the user would be would kind of see this on the browser. And I would get the data from the endpoint, from the database in the cloud. But this is outside of Ajax Focus. So we don't provide support for this. All right, so future work. So in terms of helping developers running on Raspberry Pi, Raspberry Pi's are super popular. People love them. They're definitely not very cost-effective. They're ARM64. I mean, you probably don't want to use Raspberry Pi's in production, but they're great for hobbyists and for hacking on a weekend. So I want to make those files more readily available. I had to kind of dig around to find the ARM64 Docker file. There's a good amount of tutorials that are a little outdated on how to run on a Raspberry Pi. So definitely want to update all the links and update all the information. And then we had a repository on GitHub containing our previous sample app. And I'll make sure I add this to all the components to that so everyone can see it. And then we can see side-by-side like a native Python app and an Ajax-based application. And then relative features that are coming into the next release. We have App Function SDK. That's the big one. They've been doing a great job on this. It's looking really good. And as part of that, we'll have the IoT, AWS, Azure, and Alibaba IoT export functions. So you can just enter your credentials and then explore your data into an MQTT format. And we know there's a lot of different cloud providers out there. We don't have the resources to create one for everyone. So feel free that we are looking for contributors. Feel free to contribute. Contributions are more than welcome. And then the device GPS, which is currently still in holding in incubator mode, should be merged in the next couple of weeks. So people will be able to use that and use the mock data file that comes with it. Thank you. 2D. I'm sorry, to the OBD. OK, so there's two things. Originally, in the first POC that we made, there was Bluetooth. So they have a bunch of that. Some that are USB2. The one that we purchased was Bluetooth. It's pretty good. But then the GPS has a USB port. Yes. So right now, we support MongoDB and RedisDB. So we have Docker Compose files for both of those. However, if you want to support your own database, you'll have to create your own connection. There's no SDK, but it should be fairly easy to do. You can see how Mongo is implemented and how Redis is implemented, I guess. Oh, that's a great question. Absolutely. Yeah. It's after the license change. Yeah, so it's after the license change. So yeah, I know people will use Redis for that reason. Any other questions? Yeah. Yeah, so like I said, there's a little Redis, also Redis. I think when people started designing IJX, it was kind of meant to run on a BFure Edge machine. Although, I mean, I ran it on a Raspberry Pi, so obviously, you can run it on a pretty small machine, too. But like I said, you should be able to implement your own database connector, as well. And obviously, you don't have to. So in the configuration file, there is a toggle that says, persist data or not. So if you don't want to save all your data on the Edge, you really don't have to. So if you're concerned about storage, you should be able to just not persist your data. Did I answer your question? It could be just for buffering. You could make it so it would just delete the data after you make your analysis. In the case of the GPS data and all the location data and the speed, we really don't have to persist it at all. You can just read it as they come in in the app function SDK. You can look at every single event. If it's under 60 miles an hour, just dump it. If it's above 60 miles an hour, you record. Like you start a timer or something, and then you dump it. And if you do your analysis on the go, you might not have to save it at all. Did I answer your question? They should, yeah. If you want to shoot me an email, my email is on the first. Let me show you my first slide. I'll be glad to send you the slide and also answer any of your questions. All right, if I don't have any more questions, I think that's it. Thank you.