If I were to tell you that the IoT is experiencing fast growth and that it will keep doing so for the next few years, you would answer that I am not telling you anything new. In fact, you would be right. I even said so myself in this post: we already talked about it.
Thus, to take things one step further, in this post I will focus on one of the main reasons why the growth of the Internet of Things is unstoppable: the importance of connected devices, which are continually gathering and transmitting data around the clock and have become natural drivers of the IoT.
To better understand what I want to convey to you, imagine you are the mayor of a town called – pardon the pun – Paradigma-by-the-sea. You want to offer a service that will allow the townsfolk to know how many parking spaces there are available for parking around town. Initially the goal would be to provide the following:
- A map of the town divided into neighbourhoods showing which spots are free for parking.
- Any parking restrictions, such as loading zones.
- The rates (if any).
In addition, thanks to your town’s robust birth rate and the large manufacturing sector that is developing, you would like to be able to expand the service as the town grows and more streets are paved.
In order to build this solution, we are going to use sensors capable of detecting when a vehicle is above them and communicate this to our cloud platform.
In this scenario there are different device-related challenges:
Inventorying the devices
As you can imagine, it would be necessary to have an inventory of all devices per domain: neighbourhood, street, type of parking, and so on. Thus, we will be able to carry out actions on the devices as a group and also to see the entire installed base.
Of course, having a dynamic, organised inventory is an important task in our project.
Expanding the coverage of the service
Trusting your town will grow, we need to avail ourselves of certain mechanisms for including devices in our IoT platform in an economical, transparent manner.
In this regard, the ideal scenario would be for the devices themselves to be capable, once they have been physically installed on the streets, of registering themselves in the platform and starting to send data from the very beginning.
Improving our service with updates
Assuming our current solution has been well received by the townspeople, we would like to offer them more features and, above all, keep all the devices updated with the latest safety patches and software versions.
Once again, having thousands of devices deployed around the town transforms a relatively simple problem such as physical manipulating a device and updating it into a major headache.
As far as the IoT is concerned, we should have mechanisms that allow us to do all kinds of updates in a remote, unmanned, automatic manner, thus bringing down the service’s operating costs.
We would like to offer the people a quality service and, in order to do so, we must be certain that all devices are working properly and are not degrading over time, and if they do, to be able to take appropriate measures. Having real-time information from every device is crucial in this regard.
Accordingly, we would like to go one step beyond the monitoring proper and set up a predictive system based on machine learning.
With the data history we could train a model and detect behavioural patterns that would help us to anticipate potential problems, which would result in a better quality of service.
Managing the settings
The life of a sensor is complex and ever-changing. Sticking to our example, loading zones would be created and terminated according to the commercial activity on the streets. Hence, a sensor situated in a parking space could at a certain time become part of a loading zone.
Once again, we must be capable of changing the settings of the sensors without having to physically go to their locations to alter their operating mode.
Another example would be if we noticed that the sensors were taking a high number of samples (to see whether there are vehicles parked or not): 10, for example.
Once the service has been up and running for a certain amount of time, we might find out that we can provide a service of the same quality with a lower sampling rate, e.g. once every minute. Moreover, to carry out this action, we can rely on our organised inventory.
In this present case – thousands of unmanned sensors, it would be complicated to guarantee full connectivity of our sensors to our IoT platform. Our system must guarantee that the measurements are delivered no matter what, even if it must be on a deferred basis.
We will thus be able to have all the data generated over time at our disposal and to analyse them to detect patterns of use of the parking spaces.
If something stands out in the IoT ecosystem is that, in the past few months, the main public clouds have echoed these challenges and developed diverse products as part of their already wide ranges of solutions.
Amazon has been investing in the IoT for a while now and rounding out its product catalogue to meet the needs of this technology and its use cases. So much so that it become the steward of the FreeRTOS project – a real time operating system for microcontrollers – to give it a boost and make it a part of its solution.
Google suggests we use the following services to cover the needs of our devices:
- AWS IoT Core: It takes care of transmitting messages between the devices and the cloud. Furthermore, it offers capabilities such as message filtering, security, etc. As you can see, the name does it justice as it is the main component.
- AWS Greengrass: It has several functions that are very interesting:
- It gives the ability to work in intermittent connection situations. It does so by gluing messages together and sending them when the connection is back.
- It manages the settings of the devices via shadowing. Hence, we can adjust their behaviour without having to physically access them.
- Monitoring: It provides a connection to AWS CloudWatch to concentrate the logs of our devices.
- AWS IoT Device Management: With this component we will be able to create groups of devices and create sets of attributes that we can assign to them (e.g. location, device type…) so as to be able to properly manage the inventory of devices. It will also allow us to issue device update jobs. A job is just a series of commands that the device must be capable of interpreting and executing.
By combining the aforementioned services, adding new devices is a straightforward thing to do by means of an auto-discovery feature that works in a secure, scheduled manner.
As far as Google is concerned, the company centralises the needs of the devices around Google IoT Core, but there are some functionalities, such as e.g. the procurement service, that are only available in an early access mode to partners like us.
Evidently, Google’s technical solution differs from Amazon’s and proposes different mechanisms, but it also allows:
- The inventory of devices to be easily handled via an administration console and procurement utilities.
- The information on the status of each deployed device to be kept.
- Commands or actions to be executed in the devices themselves.
- The devices to be monitored via Stackdriver.
In Google’s case, its device solution is associated with Android Things, an extension of its Android platform that is focused on a great variety of consumer, retail and industrial devices.
If you are familiar with Android, you will find it very intuitive and easy to build your application and to use the tools Google provides to overcome the challenges we have discussed above.
With this Paradigma-by-the-sea example, I wanted to illustrate the difficulties of integrating the digital and analogue worlds – which is precisely the aim of the IoT – by means of a use case with specific needs.
In the end, the IoT – and everything it involves – sets for us a new set of challenges that we must face. In this case, I wanted to mention the devices, but I could have just as easily talked about security, performance or even the specific use cases for which this technology is ideally suited.