Visualizing the Internet of Things: The Design – Nuwan Jayawardene

Visualizing the Internet of Things: The DesignMy first project as an Intern at WSO2 IoT ServerWhatever said and done, at the end of the day one thing is for sure;an IoT network is complicated.With so many devices connecting and talking to each other, there comes a point when it can all be quite overwhelming. Especially when it’s not a single device layer network.What this means is all Edge Devices aren’t directly connected to the server, but rather the network is a combination of direct connections of Edge Devices and connections through IoT Gateways.Single Device layer vs Multi Device layersAnd even that is after taking into account if the Server in question is capable of supporting multi device layers.As the above diagram might show, sometime all you need is a visual aid to better understand a complicated system.This article explains a project in which I got an opportunity to have a hands-on experience in giving an IoT network a visual meaning.On July of this year (2017) I started my 12 month internship at WSO2. For those who might not know, WSO2 is an Open Source middleware provider. For my first project I was to develop a feature on their IoT platform; the WSO2 IoT Server.Since explaining the entire project in one article will be difficult, I’ll be breaking it up into 2 parts; one explaining the Design of the implementation and the other explaining the Code.Although you might find it boring at times, bear with me ’cause I’ll try to make it as entertaining as possible. :)Finding a purpose & selecting a projectAs soon as the orientation week was over we were given a list of available intern projects to select from. The projects involved all the products in WSO2 and focused on different aspects of each one.Now me being someone who’s more towards the visual component of UI/UX and somewhat fearful of Server side programming struggled to find a proper project within my comfort zone.But there was one project that stood out to me. The title of which went something like this;Edge device recognition for WSO2 IoT Server.The main reason I was drawn to this project (other than my curiosity with IoT) was a previously unsuccessful attempt at a University assignment, the details of which is enough for a whole other article.The utter fascination I had as to how a server would understand the devices connected to it, combined with the opportunity to rectify a past mistake drove me to select this project.Upon further inspection of the project spec the things that needed to be accomplished were as follows;Give the IoT Server the ability to understand a Multi Device layered network arrangement.Develop a visualization mechanism to show how the network is arrangedThe tricky part here was that the edge devices should be treated equally by the WSO2 IoT Server irrespective of device type. And since the current state of the Server did not have any capability to understand how such a network is arranged, it all had to be implemented from the bottom up.And so began my first project as an Intern at WSO2…Seeing through the eyes of the ServerI’ll admit it, I like to starting coding first and think about design mid-way through. This is how I did most of my University and personal projects all of which ended up way going beyond their deadlines.So it was clear that this approach wasn’t an option going forward with my Intern projects. First things first, one question needed to be answered; how should the WSO2 IoT Server view the devices connected to it? Since the project was more of a research focused one, there was no right or wrong way to go around this dilemma.After much discussion with my mentor and supervisor we came up with a ‘meta-data’ model.Metadata model for supporting Edge DevicesThe gist of the model is that each device is aware of who their children are and who their parent is (on the condition that there can be only 1 parent). Later we further simplified this so that each device should only be aware of the parent, and when being enrolled to the IoT Server the agent of the device will update the server with this data.The big pictureWith a basic meta model in place, it was now time to understand how the WSO2 IoT Server was structured. Now up to this point I had next to no idea on how an enterprise grade middleware was structured and how each of the components communicated with one another. So I believe this might have been the most difficult and time consuming portion of the entire project.Beyond this point it was less hand-holding and more of learning things at my own pace.After the first few months I was accustomed with how the platform was arranged. I also had the added benefit of creating a feature from scratch, so knowing the whole platform, or at least the primary parts of it was crucial.So now everyone might be wondering what the big picture is.Well, the diagram below might help shed some light on how the stack of the WSO2 IoT Server is arranged.While the numbers on the side show where each of the layers exist in the hierarchy it also represents how I progressed through each of the layers, slowly starting from the depths of the platform and making my way upto the surface UI.While there were several sub components I didn’t mention here such as Unit tests, I’ll go further into detail in the next article when deconstructing each layer individually on the code level.Layer 1: Hip deep in DAOIf you look it up, Wikipedia explains that DAO means “an object that provides an abstract interface to some type of database or other persistence mechanism”. If you found that a bit confusing it basically means that the DAO is where all the database tables of each and every function/feature of the WSO2 IoT Server resides.Now for the initial portion of my project I needed a very simple single table structure to maintain my metadata.Structure of my DB metadata tabledevice_id: The unique identifier of the device. Also the primary key of the table.device_name: Whatever user specified name of the device.parent_id: The unique identifier of the parent the device is connected to.mins_since_last_ping: No. of minutes that have transpired since last communication with device.state: The state the device is in currently. This could either be ‘connected’, ‘pending’ or ‘disconnected’. The mins_since_last_ping value of that record is used to determine this.is_gateway: At the time of enrollment the agent of the device establishes that whether the device is a gateway or not. I’ll explain the main reason of having this field later.I also wrote a DAO implementation class to include the queries that I would be running for various operations needed for my project.Layer 2: A little further up with OSGiAfter all of the DAO Database level design was done, it was time to move to the OSGi services.Gateway to access the DAO levelOSGi services are sort of like the gatekeepers allowing REST or other services to access the Database. These OSGi services are no different from your typical Java class. All it contains is the processes needed to take a bit of data sent to it and hand it over to the DAO so that a query can be executed and a DB table can be edited.Layer 3: Closer to the surface with RESTful servicesAll the stuff I’ve been working on up-to this point was entirely non-user facing. The user facing, or rather developer facing stuff begins with the RESTful APIs.How REST endpoints get stuff doneREST (REpresentational State Transfer) is an architectural “style” used in the development of web services. It’s kind of like using traditional web URLs with certain verbs accompanying them. Verbs like; GET,POST,PUT and DELETE are used primarily in REST. This makes writing and accessing endpoints or web services fairly painless and straightforward.REST APIs can be written for basically any operation needed to be done in a database. In my case I’ve got REST services written for purposes ranging from adding/removing a device to performing updates on device data. If the user of the API has the necessary permission then it’s just a simple matter of sending an HTTP request to get the job doneLayer 4: Reaching the top with the UIAt the topmost level is the UI.The REST APIs written in the level prior actually complements the UI and helps it work. Most of the time whenever you see something in a web page update or change before, that’s an API working behind the scenes. So if UI components were stage actors, REST APIs would be the stage managers and backstage hands making sure the show was running smoothly.Web app UI built on a foundation of REST API servicesBefore creating any UI it’s advised to create a mockup.Rudimentary mock-up for my visualizationThe mockup I created had a visualization of a sort of organic structure as the hero of the page. Making the visualization component the hero made sense, as it showed how the network was arranged at a glance.Such a visualization would make it extremely easy to understand how big the network is and even understand some more in-depth information like which devices are offline. Without visualization it would be extremely difficult to go through tons of database records and get the stuff you want. A simple UI just makes it, simpler!With all of that done the design on my project was complete. Now it was time to get to the nitty gritty of it and start to put code to IDE. So while I’m off for a commercial break please note I’ll be covering the rest in it’s entirety in the upcoming article. ;)This post is one in a series I’m writing about the Internet of Things. If you need to catch up to the earlier ones, the index is as follows;Episode 1: Putting the “Internet” back in the Internet of ThingsEpisode 2.1: Visualizing the Internet of Things: The Design
SIGUE LEYENDO…
Ir a la fuente / Author: Nuwan Jayawardene