Making a splash in the physical world

Developers venturing in IoT

As a developer we have delivered many software applications. We are comfortable in writing code, debugging for defects, and deploying into a server or client’s machine to beam up with joy in seeing them use our app. IoT is a phenomenon that we developers cannot neglect more. Adoption is increasing and so are use cases that are rewarding in terms of value for its customers.

If you are a developer starting to understand where to start in IoT development, you need to understand the aspects involved. There are 4 major aspects involved in such development –

1. Device, needless IoT cannot be Internet of Things without the devices which represent things
2. Network, for same reasons as device the name itself indicates this aspect
3. Application, without which customer will not see the value for IoT
4. Intelligence, which embellishes the value furthermore

If you notice the name i.e., IoT itself carries 2 important aspects and the other 2 add value for customers to which they pay.

Your home

Application and intelligence are home to you. Cloud is a natural home for deploying such application, add the mobile capability it offers impressive capabilities for you as developer. This where the IoT suite of offerings in major cloud providers are sold.

Designing application for IoT needs to be planned and designed in 2 parts. First naturally resides on the thing i.e., the device. Next part is a traditional app that you develop with any modern-day framework. We will touch more upon the nature of app that needs to be built for the first part i.e., the device in next section. Here we focus on everything other than that.

Cloud providers Azure, Google Compute Platform (GCP) and AWS all provide services to accomplish the traditional app development. This app provides the user interface in the format of web application or mobile application with which user interactto instruct the device or the thing. Let us take an example – You create an app which sends you an alert in case you leave your keys in the vehicle (2/4-wheeler) accidentally.

In this situation you will a user interface or device of sort where you receive the notification. The app could be spartan with just the UI to display the alert or it could be bit more reporting in nature where it could show you your past such occurrences. We could extend this further with analytics where we could attempt to correlate such forgetful moments with location, time of day or any other factor.

You would notice we start with a benign requirement of displaying only alert. Let us take one cloud provider Azure to look at the services and we could draw parallel to other service providers easily. Let us say we make a mobile app using Xamarin. There is no Azure footprint that is required for to do that. However, for the notifications to be sent to device we will need Push Notification service.

Azure Notification Hub is the service that fits the bill perfectly. In AWS its equivalent is Simple Notification Service whereas in GCP it is known as Cloud Pub/Sub.

Publishing to such a service is the next thing that you will focus. Apparently, the device should do that isn’t it? But how does it do that? More than the how part right now another important part as developers you will ponder is when i.e., when does the device publish such a message?

It is time that we give serious thoughts on the device now. But let us not juice out the next section which gives a background and brings the device into perspective. So, for now let us assume that some information needs to be generated by the device and we have two options to answer the “when” question

 

 

 

1. Device without connecting to internet decides that key is left in the vehicle
2. Device connects to internet to invoke a remote intelligent service with raw data. The remote service then decides whether the key is left in the vehicle

Wow, this opens avenue for a traditional web service to be builtonly for the scenarios. However, nature of the service will be different in both the situations.

That is for

1. Service should be a gateway to Push Notification service from a device’s perspective
2. Service should consume data and intelligently determine the key’s presence and it itself or via another gateway send a Push Notification.

Is it not interesting? As even as you develop application in traditional manner of speaking you could have points where physical world intertwines with the application logic!

Let us put the bucket list of things then for what you consider your forte –

1. Configure a Push Notification Service (PNS)
2. Host an API to interface with device to either
a. Act as gateway to publish messages to PNS
b. Act as intelligent service which determines if the key is left in the key slot

You might already have an adrenaline kick by the usage of words intelligence service. Yes, you will have to develop machine learning based solution or service towards that need. For the example scenario we took, irrespective of the where you detect the situation i.e., key left in the key slot you will end up using machine learning based component at some place.

Returning our focus to device, it must connect with internet somehow and send data somehow. If you remember we had parked the question on “how” earlier to attend the question on “when”.  This leads us to the next section naturally, where we explore the “how” part of the device publishing the message?

The catch

Device and network! Depending on your background you might feel comfortable in these aspects. Cloud have made these aspects even more obscure for many developers these days and suddenly you are exposed to raw electronics, knowledge of which will help you accelerate your growth as IoT developer. Hardware used in IoT like in development also have grades for sturdiness. So, when you initially start you will not be using PCB’s and proper casing to house the electronics or in other word you will be working with prototypes and breadboards with lots of wires. There are difficult choices that you need to make already upfront and understand it from the cloud context as well. The choice is to detect which type of prototyping board you will use –

1. Microcontroller boards
2. Single Board Computer or known as SBC’s

Examples which put these categories in clear as day and night is Arduino is a good example for Microcontroller based boards and Raspberry Pi is a good example for SBC. That said the choice depends on the usage but few guiding principles that could be used to assess the choices are –

1. Power requirements, SBC will require more power
2. Ease of development, yes you will be required develop application that runs on the board
3. Data acquisition requirements, in simpler words sensors connectivity
4. Data processing requirements
5. Data storage requirements

For the scenario of detecting key left in the key slot we will draw key requirements like you will do in any software development project. These key requirements typically will drive 85% of decisions on the hardware in this case. To effectively use the scenario let us limit ourselves to only 2-wheeler.

1. Ability to identify key in the key slot
2. Ability to detect that 2-wheeler is stationary
3. Ability to detect that rider is not seated in the 2-wheeler

Now if you had electronics or mechanical background already you would have started thinking of the sensors. Detecting the key in key slot could be simple open / close circuit detection only if you knew where to tap in a 2-wheeler key system. Next the challenge of vehicle being stationary is easily detectable with an accelerometer sensor. Any acceleration along X, Y or Z axis will indicate a movement. Threshold values which should be used for acceleration can be worked upon while piloting prototype. The last key requirement of identifying seated 2-wheeler rider is interesting there are plenty of ways with varied levels of complexity.

As a software developer the one that comes to my mind is to use a camera. Take shots from the camera which points in the direction where rider sits. Use case is extensible tomorrow to situation where you could use the snapshots to determine if the rider is same person or different. Not face detection with high accuracy but a custom-built model for all the physical variances like helmets, glasses, attire etc.

Looking at the requirement of detecting key in the key slot one can rethink of vision-based identification where the presence of key is identified. One of the key considerations in any physical world implementation will be the power requirement and the source that could be used in the bike to provide such power. We will not dive more detailed on the calculations but leave it for you who savour it to endeavour into.

The next big piece of work in the scheme of things is the connectivity to internet. For a moment you could question that as well. Can we not use Bluetooth lite to pass the message from the device to mobile? That can be extended to removal of PNS as well. But think about it BLE has range within which it works what happens if you go beyond that?

To address such scenario internet needs to be used and as well ifyou decide to use cloud-based processing to detect the combination of requirements to send the alert. To accomplish this there are couple of possible ways –

1. Use a SIM module to connect with mobile internet
2. Use a WiFi module with data card in a secure storage of the bike

Depending on the packaging, power requirements and your individual preference you could use either of the approach to connect the device to internet. Once, you do that the next thing is wiring the software on cloud to accept data and then have a processing workflow in place which will do the decisioning.

Azure service IoT Central, IoT Hub are good choices for managing devices that it identifies as allowed devices and could ingest data to software that you have written earlier. In AWS it is IoT Core where as in GCP it is Cloud IoT.

These services are popular ones and are typically the first thing that you will try. We do not by any means indicate that there are no other services. However, the ones listed above does much of the heavy lifting and lets you connect securely to the cloud.

Once the data is ingested other services can be used to analyse and build intelligence atop the ingested data.

The journey of thoughts that we had in this section will be most likely the way you would approach an implementation of IoT project from hardware choice and selection perspective.

Putting in perspective

You have cloud to handle the software i.e., notification, services to façade the actual workers and importantly intelligence. From the requirements the fact of identifying the presence of key itself could be a complex piece of logic or could be an interesting ML based implementation. However, for the use case we are not advocating the need to use the solution as outlined here but rather to take the thought process used for solutioning. We are sure one could use near field communication to trigger an alarm in case the rider moves away form the key beyond a threshold thus reminding to pick the key. Such a utilitarian solution will lack the reporting and analytics that you could do by looking at history of such negligence and we could as well bring in an insurance flavor if the solution is IoT based.

So where do you start

You start which is you consider as your forte. Wasn’t that obvious?

But there are considerations that you need to make while venturing even in those areas which you consider as your home.

1. Device interoperability
2. Error tolerance
3. Delay tolerance