The IoT Hype
IoT seems to be the next big thing around the corner !! Everyone is
investing billions on this hyped up sector and a tech bubble is building up. If you are an IoT enthusiast like me, it would be interesting to know the problems of the game ! :)
Here are the two important points why I think there are challenges associated with IoT : 2020 vision (Gartner has projected that there will be 50 billion connected devices by 2020) -
Let us establish first why there is a need for change in design methodologies of embedded systems, at least from IoT point of view. The embedded system part of IoT comprises of sensors and actuators. And IoT connects many embedded systems using a network fabric. The timing needs to be accurate in all sense of design, otherwise it may lead to system failure. For example, an actuator not turning on at exact moment when it is required can cause damage to human life.
The conventional design of an embedded system software is using a high level language like C. But majority of these high level languages do not capture timing semantics. For example, take a simple code :
#include <display.h>
void main()
{
print("\nHello World of things!");
print("\nI don't know how long will it take for this line to be printed on the display! :( ");
}
This simple hello world program executes sequentially. But it does not tell the programmer about how long it will take to execute. It depends on the hardware it is going to run; and the timing semantic is not a part this programming layer in C. In fact, even the ISA layer does not capture timing semantic. Its a failure of abstraction layer if it does not capture all the necessary features required in the higher layer.
The problem is more worse if there is an underlying OS which schedules this task. There are no guarantees about when the task is scheduled, no guarantees that the program will not be preempted before its completion, and no telling how long it will take to complete the task.
Even with RTOS, the method of determining worst case delay is using bench testing (determining WCET - Worst Case Execution Time), and thus this is not a deterministic way. Thus there is a need for fundamental new design concept, where timing is a part of every abstraction layer ! We might have to develop new hardware (like Precision Timed ARM), new ISA with timing abstractions, programming language that gives adequate control over time etc.
If we have multiple sensors posting data onto the server at defined frequencies, we will run into three problems -
a. Battery of the embedded system will drain out.
Usually, communication is a more expensive operation than computation. The RF technologies used for networking are not friendly on battery at all. This is a challenge for both VLSI community and embedded community; The VLSI community should produce very low power chips, that do not consume high power for communication, and the Embedded community to come up with smart standards (like MQTT) which can enable smart energy efficient communication.
b. The server will be loaded with highly correlated data.
The source of data stream here in IoT are sensors. If these sensors are constantly dumping data into database, they will take up too much of space. Also, these data have some correlation between them. For example, a temperature sensor in front of an AC produces an output which almost looks like a sine wave. Thus it is highly likely that we can fit in a mathematical model which describes the sensor outputs.
Now, if we can make both the embedded system and the server aware of the mathematical model for the sensor, we can expect that both the data source (Embedded System) and the sink (Server) are in synchronization. So, it is enough to transmit the data which are not expected by the sink. This saves both disk space and battery life of the embedded system (since we can cut down on number of packets sent). It is estimated(click for the source) that the number of packets sent can be cut down by 95%, a substantial amount.
c. Of course, we need to make sense of the data from multiple streams and generate insights.
Big data and machine learning technologies are here to take care of this problem. But there might be cases, where decisions need to be taken real time, and many researchers and working on this hard problem. For example, an autonomous car driving application will generate multiple data streams; these data, along with other source of data such as the traffic rules data etc., will have to be combined and use them to take decision about the state of the car, all these in real-time.
Both the above headings are research intensive problems. Also, lets not forget that internet infrastructure is not in place yet everywhere (Another very hard problem). We will definitely need IPv6 to be the standard if we are going to connect 50 billion devices to the internet. All these problems are real difficult to meet by 2020.
Here is a reminder from Gartner about hype cycles :
But its time to put the thinking cap on, and aim for the plateau of productivity !!
Here are the two important points why I think there are challenges associated with IoT : 2020 vision (Gartner has projected that there will be 50 billion connected devices by 2020) -
1. The Embedded challenge :
Let us establish first why there is a need for change in design methodologies of embedded systems, at least from IoT point of view. The embedded system part of IoT comprises of sensors and actuators. And IoT connects many embedded systems using a network fabric. The timing needs to be accurate in all sense of design, otherwise it may lead to system failure. For example, an actuator not turning on at exact moment when it is required can cause damage to human life.
The conventional design of an embedded system software is using a high level language like C. But majority of these high level languages do not capture timing semantics. For example, take a simple code :
#include <display.h>
void main()
{
print("\nHello World of things!");
print("\nI don't know how long will it take for this line to be printed on the display! :( ");
}
This simple hello world program executes sequentially. But it does not tell the programmer about how long it will take to execute. It depends on the hardware it is going to run; and the timing semantic is not a part this programming layer in C. In fact, even the ISA layer does not capture timing semantic. Its a failure of abstraction layer if it does not capture all the necessary features required in the higher layer.
The problem is more worse if there is an underlying OS which schedules this task. There are no guarantees about when the task is scheduled, no guarantees that the program will not be preempted before its completion, and no telling how long it will take to complete the task.
Even with RTOS, the method of determining worst case delay is using bench testing (determining WCET - Worst Case Execution Time), and thus this is not a deterministic way. Thus there is a need for fundamental new design concept, where timing is a part of every abstraction layer ! We might have to develop new hardware (like Precision Timed ARM), new ISA with timing abstractions, programming language that gives adequate control over time etc.
2. The Big Data Challenge:
Every data out there is not useful. More so in the case of IoT.
If we have multiple sensors posting data onto the server at defined frequencies, we will run into three problems -
a. Battery of the embedded system will drain out.
Usually, communication is a more expensive operation than computation. The RF technologies used for networking are not friendly on battery at all. This is a challenge for both VLSI community and embedded community; The VLSI community should produce very low power chips, that do not consume high power for communication, and the Embedded community to come up with smart standards (like MQTT) which can enable smart energy efficient communication.
b. The server will be loaded with highly correlated data.
The source of data stream here in IoT are sensors. If these sensors are constantly dumping data into database, they will take up too much of space. Also, these data have some correlation between them. For example, a temperature sensor in front of an AC produces an output which almost looks like a sine wave. Thus it is highly likely that we can fit in a mathematical model which describes the sensor outputs.
Now, if we can make both the embedded system and the server aware of the mathematical model for the sensor, we can expect that both the data source (Embedded System) and the sink (Server) are in synchronization. So, it is enough to transmit the data which are not expected by the sink. This saves both disk space and battery life of the embedded system (since we can cut down on number of packets sent). It is estimated(click for the source) that the number of packets sent can be cut down by 95%, a substantial amount.
c. Of course, we need to make sense of the data from multiple streams and generate insights.
Big data and machine learning technologies are here to take care of this problem. But there might be cases, where decisions need to be taken real time, and many researchers and working on this hard problem. For example, an autonomous car driving application will generate multiple data streams; these data, along with other source of data such as the traffic rules data etc., will have to be combined and use them to take decision about the state of the car, all these in real-time.
Both the above headings are research intensive problems. Also, lets not forget that internet infrastructure is not in place yet everywhere (Another very hard problem). We will definitely need IPv6 to be the standard if we are going to connect 50 billion devices to the internet. All these problems are real difficult to meet by 2020.
Here is a reminder from Gartner about hype cycles :
![]() |
| Hype Cycle for a technology |
But its time to put the thinking cap on, and aim for the plateau of productivity !!

Nice article,
ReplyDeleteThank you Yogesh!
DeleteAwesome!
ReplyDeleteGood one sisya !
ReplyDelete