The cloud services market for IoT devices is complex and fragmented. Here’s how to make it simpler.
By Paul Donaldson
EMEA Vertical Segment Director, Future Electronics
The process of transforming a conventional embedded device into an Internet of Things (IoT) node is, today, extremely complex. Strangely enough, there is no technical reason why this should be.
The problem is that the end-to-end system from node to cloud requires links provided by multiple companies. And there are no universal standards for ensuring interoperability between one link and another.
This means that there is a massive barrier in the way of electronics products OEMs which wish to serve their customers better by bringing the devices they make into the IoT. How can it be removed?
The answer is in bringing together into a single service the multiple partners which are needed to complete the chain between nodes and the cloud – a role to which an electronics component distributor such as Future Electronics is ideally suited. As this article describes, it is possible to hide the inherent complexity of IoT service provision and to make it much easier for OEMs to commission, secure and monetise the cloud services that IoT end nodes need.
Why is cloud service so complex?
The problem for OEM design engineers tasked with turning a conventional product into an IoT end node is that they are forced to solve engineering problems in two dimensions. At the board level – let’s call it the horizontal plane – designers are used to the problems. Upgrading a design to adapt it for the IoT might involving selecting a beefed-up microcontroller, adding an RF module and extending the system’s application code. Not easy, but it is the work that electronics designers are trained to do.
But the IoT also has a ‘vertical’ plane: the services and technologies which link an end node to a cloud server. And implementing this end-to-end chain does not involve the usual board-level design processes with which electronics engineers are familiar. Instead, it requires integration of connectivity services and airtime, internet services, cloud storage, graphic representation of the analytics and security at each stage of the system – and each service is provided by a different specialist supplier. If the end node is to communicate successfully with the cloud, each of these services must be interoperable, and the end node must be configured so that its software can be securely updated while continuing to perform the task required of it by the application.
To take an example, a streetlight manufacturer might want to make every lamppost a node in the IoT. By equipping every lamp with a CO2 sensor, a network of streetlights could become a source of local, granular air-quality data that could be made available to users via a browser or app.
So the streetlight manufacturer might want to send CO2 sensor readings via a LoRa® Low-Power Wireless Wide-Area Network (LPWAN) to a Microsoft Azure cloud-storage server for analysis by an IBM analytics and web applications service. In order to accomplish this, the OEM must talk separately to an LPWAN network service provider, to Microsoft, and to IBM, and hope that the services they provide are interoperable. It is a process full of risk and uncertainty.