The IoT should be seen as an evolutionary development, one that employs M2M communications technology. Although the IoT architecture is different, it is built on a common foundation. A key IoT requirement is the need to decouple data generation from data usage. In an M2M solution they are physically linked: they monitor one issue, a physical parameter or the movement of a machine part, and transfer the data into a single application. This model cannot deliver the IoT vision.
So what is that vision? It’s vast. Example: Consider the installation of a people-counting sensor on a train; the operating company uses the data to monitor passenger patterns. At a later date the maintenance organization adds an application that employs the same data in order to move to a usage based scheduling system. This is followed by the catering company that delivers products to the train and by the stations to warn of approaching passenger loads and then by city or town authorities establishing transport strategies.
It started out as a single, simple app, counting passengers, but ends up as a mix of applications that includes those of third parties: that would not be possible in a solution based on the M2M model. The IoT model is based on an open, flexible architecture that allows multiple device types, monitoring a variety of assets, to interact with each other as well as a diverse range of applications and stakeholders. These are mandatory parameters.
A services centric economy
IoT advances the many benefits provided by M2M, but leverages its intrinsic functionality by adopting the decoupled ICT architecture that has been in place for decades in enterprise environments and which is also employed in social networks.
Example: Twitter is a service. Hash tags define topics and users don’t need to know anything about device addresses or the communications architecture. They simply register their interest in receiving messages when hash tag matches their criteria. Data on new topics can be added at any time, new hash tags are generated, but the underlying architecture doesn’t change. We take the functionality of this service for granted and that’s the way it should be, and will be, in the upcoming service-centric IoT era.
The use of a topic-based IoT architecture would allow new data flows (topics) to be added at any time. Applications would register an interest in a topic that contains the data elements it needs, and then they would receive the relevant information. New data flows coming from new apps would be automatically delivered to the relevant subscribing service.
Is it doable? Yes. In fact Eurotech has done it. To make this concept work an Enterprise Service Bus for Machines is used to decouple data acquisition and data processing and enable virtual connectivity between different device data systems and different enterprise applications. This allows the system to adapt whenever new topics appear. If a company wants to monitor a new type of asset, for example, then the infrastructure needs to be flexible in order to simply store data from new topics without the need for user intervention or reconfiguration.
Rethink your thinking
The ability to exchange information between applications gives IoT the edge when it comes to the creation of brand-new business models. They are being created right now and many more will follow. Quite a few may appear to be improbable, so step back and consider the implications of adopting the following smartphone scenario and note that there are no technical barriers when it comes to implementing similar functionality in an IoT solution.
You hear a song somewhere when you’re out and about. The smartphone app recognizes the performer and the song; asks if you want to download it; you buy it; then the app tells you about an upcoming concert in your area; asks you if you want to buy a ticket and you do. It’s a seamless, transparent process conducted on a handheld device: something that is taken for granted by the target audience. More significant is the fact that it is not seen as a solution: it didn’t address an issue. The deliverable is a service and services are also the future of B2B IoT.
Employing similar functionality in an IoT environment would be amazing — initially — and later on it too would be taken for granted.
