Internet of Things Presents New Challenges for an Old Concept
The saying “Everything old is new again” applies in spades to the Internet of Things (IoT), as the IoT is really just the evolution of automation systems we’ve been using for decades. But there is a key difference in today’s IoT applications, one that presents a significant challenge to service providers seeking to profit from IoT-related applications and services: the scale of their systems.
IoT technology dates back at least to SCADA systems used in industrial automation applications for decades to control machines on the factory floor. It then expanded to point-of-sale technology used in retail stores as well as fleet tracking systems used in transportation. All of these systems involve relatively small computers that communicate among one another with no human intervention, while producing valuable information that humans ultimately consume.
That’s exactly what today’s IoT technology involves, but on a much broader scale. Now the “compute” technology can be as simple as a sensor that does nothing more than track some variable – temperature, humidity, motion or what have you – and communicate it to some central computer.
So now we see IoT technology used for applications such as building automation and home health care. Instead of a SCADA system that may deal with a few hundred devices in a factory, these systems communicate with hundreds of thousands if not millions of devices and sensors that may be located hundreds or thousands of miles away.
This dramatic increase in scale presents a problem for service providers who are building these systems: managing and monitoring it all. Consider that the devices, sensors and networks required to deliver any given IoT application likely come from a number of different vendors. That means that the service provider who is ultimately responsible for delivering the application to the customer doesn’t really have control over the entire infrastructure.
Think about a home health care application, for example. This could involve medical devices for dispensing medicine and checking vital signs. They must communicate information to some sort of centralized server that makes sense of it all and communicates to a third party – some sort of health care provider – should anything be outside the norm.
In this case, the service provider has to closely monitor all the data coming from the network of sensors to find anything that’s out of the norm. That means the provider must ignore most of the devices and focus on the handful that are sending messages that indicate there’s a problem. When you have hundreds of thousands or millions of nodes in the network, that’s a tall order. But in this case, when you’re talking about monitoring blood monitors or respirators, it could literally be a matter of life or death.
The same goes for a home alarm system. You don’t want to find out an hour after the fact that someone was breaking into your home; you want to know when it’s happening, while you can still do something about it.
Today we’re seeing lots of IoT activity from service providers ranging from the major carriers (AT&T and Verizon) to device manufacturers such as Nest (acquired by Google about a year ago). What they’re all going to need is some sort of performance monitoring platform that can handle the scale of these vast IoT networks.
The platform has to be able to ingest data from any layer of the network, with the ability to handle the array of protocols at play in current IoT networks. It has to have the ability to deal with device inventory and configuration and track the performance of each layer of the network: the sensors, uplink to the service provider, the service provider core, and the application itself. And the platform has to be able to ingest and analyze a vast amount of data – in real time.
I’m not sure the vendors and service providers involved in delivering IoT services and applications are considering the role that performance management platforms can and should play in their networks. But I’m guessing they will before long.