IoT, the Internet of Things, is currently one of the most hyped concepts in the computing world. Cloud IoT platforms may even exceed IoT on the hype scale. Nevertheless, both have real applications and could become important to your business. In this article we will define IoT and cloud IoT platforms without too much technical detail, then discuss what you need from a cloud IoT platform and how to choose one.
The simple explanation of IoT is that it is physical things connected to the internet. These things can have sensors that measure various parameters and send their data over the internet, typically back to a remote or “edge” server located in the same geography. Internet things can also take directions via the internet and act on them. Most usefully, the physical things that make up IoT might both send measurements and receive instructions.
For example, a “smart” internet-connected soil moisture sensor could report its readings periodically, and whenever the soil in a field was too dry an internet-connected water valve could open. When the soil moisture was adequate, the valve would close.
The moisture sensor and the water valve might be connected to the same “edge computing” device or node that talks to the internet, or they might be connected to different nodes, since many soil moisture sensors are likely to be used for a large field, while only one centralised irrigation system would be needed for each field.
How does IoT relate to the cloud?
“The internet” is not an endpoint, of course, but an interconnected collection of networks that transmit data. For IoT, the remote endpoints are often located in a cloud server rather than in a single server inside a private data centre. Deploying in a cloud is not absolutely necessary if all you are doing is measuring soil moisture at a bunch of locations, but it can be very useful.
Suppose that the sensors measure not only soil moisture, but also soil temperature, air temperature, and air humidity. Suppose that the server takes data from thousands of sensors and also reads a forecast feed from the weather service. Running the server in a cloud allows you to pipe all that data into cloud storage and use it to drive a machine learning prediction for the optimum water flow to use. That model could be as sophisticated and scalable as you want.
In addition, running in the cloud offers economies. If the sensor reports come in once every hour, the server does not need to be active for the rest of the hour. In a “serverless” cloud configuration, the incoming data will cause a function to spin up to store the data, and then release its resources. Another function will activate after a delay to aggregate and process the new data and change the irrigation water flow set point as needed. Then it, too, will release its resources.
Local vs remote IoT feedback loops
In the irrigation example, the system will still work if the response time from the cloud server is an hour. Other systems are much less tolerant of lag.
For example, consider a self-driving car: It is constantly viewing the road, identifying obstacles, and measuring its location. It may also constantly send its data to the cloud, but it cannot depend on a remote server to adjust its throttle, brakes, or steering. That must all be done locally.
This is one of the essential lessons of an introduction to control systems engineering course: Push the control feedback loops down to the lowest possible level. Yes, a remote supervisor can change the destination set point or the route plan, but the car itself must take care of all the time-sensitive actions.
Essential cloud IoT functions
A cloud IoT platform must monitor IoT endpoints and event streams, analyse data at the edge and in the cloud, and enable application development and deployment. These are the essential functions required for virtually any IoT implementation.
In order to enable cloud data analysis and application development, the IoT platform needs access to cloud storage. For industrial IoT devices and vehicles, there can be a lot of data to store, although it can be filtered or aggregated for long-term analysis purposes. Industrial IoT can also present a challenge in terms of network and protocol conversions. Old-fashioned industrial programmable controllers were not made for Ethernet and TCP/IP.
Another piece of the puzzle is transporting the data from the edge devices to the cloud platform. For indoor applications you can often use wired Ethernet or Wi-Fi. For outdoor applications, such as the agricultural scenario, using cellular data is common, with cellular M2M (machine-to-machine) plans rather than much more expensive cell phone plans.
Managed IoT connectivity services can help with this piece. Some of these services are mostly about managing SIM cards and related data; broader IoT connectivity platforms also deal with edge device operating systems and agents. Beware: Some mature M2M services have added “IoT” to their branding without adding any real IoT capabilities.
IoT platform considerations
Rather than simply jump onto an attractive-sounding cloud IoT platform, you should first identify your own requirements and sketch out a few monitoring, analysis, control, and application architectures that might fulfil them. Figure out the user experience, data, and business decision pieces of the design before jumping into the technology.
Try to avoid designing to a specific device, device OS, gateway, edge platform, network, communications protocol, cloud platform, or cloud brand. Instead, design in generic terms first. Figure out which features are most important to your application, and use that list to inform your platform selection. In other words, it is a process.
Cloud IoT costs can be hard to predict, and easy to underestimate. Part of the problem is that cloud pricing is inherently complicated. (Often the only way to really know what a cloud application costs is to run it for a month and look at the bill.) Another part of the problem is that cloud IoT platforms generally offer an introductory discount. If you rely on the introductory pricing, you can be in for a rude surprise when the prices go up. Finally, it is easy to neglect the cost of data storage, and hard to implement a long-term strategy for discarding older inessential data.
Another difficult part of the process is to evaluate your own capabilities. Do you have expertise in managing devices and sensors? In communications protocols and networks? In cloud application architecture, operations, and management? Will your people be able to dedicate themselves to building your IoT application, or do they have important ongoing responsibilities? Will you need new hires? Are new hires with the right skills available?
Those evaluations will inform your choice of full-featured or bare-bones cloud IoT platforms. Some vendors offer robust, nearly complete platforms that are easily customisable to your application needs. Other vendors supply some of the pieces you will need, but require you to do much more integration and customisation, either internally or using consultants.
The value of performing a proof of concept for your first cloud IoT deployment cannot be overemphasised. Like any other project involving software development, you need to plan for your first effort to fail so that you can learn from your mistakes and build it right the next time. Only after your proof of concept succeeds can you start scaling it up and out.
IDG News Service
Ltd
