The Difference Between M2M and IoT

Recently, while visiting another company that works in the IoT space, I got into a discussion with one of their technical leads. We were talking about the difference between M2M and IoT, and his view was that they were essentially the same thing. As far as he was concerned, IoT merely adds new sensors to collect data at lower price points, and more powerful computation capabilities at the enterprise to enable massive data mining and analytics. He summed it up by saying something along the lines of, “We measure the data with new sensors, we transmit it to the enterprise, and then some clever people do clever things to transform the data into actionable information”.

He was completely missing some of the fundamental differences between the “old” M2M and the “new” IoT architectures. In particular, he seemed to be overlooking the ways in which IoT pre-processes data at the network edge before sending it on for consumption; and in the things IoT does as it transmits the data to the enterprise’.

Traditional M2M systems have typically been applied to the monitoring, control or optimization of a single process. They have been specified, designed and implemented to address a point-in-time problem with a point-in-time solution. Using the old M2M architecture, for example, a building might have separate systems for HVAC control, security and fire detection. Quite often, these discrete systems will take the same measurements at the same places via separate sensors. The sensors are wired back to separate instrumentation cabinets, and then to separate operator screens. Each system will communicate internally using its own (often proprietary) protocols and standards.  Sharing data between systems is difficult, often impossible.

On the positive side, it has been relatively easy to specify M2M systems. When we’re dealing with a point-in-time problem we can scope out the measurements that we need to make, and the way we want this information summarized. The boundaries of what we want to achieve can be defined, and an ROI case is relatively simple to justify (or reject).
A traditional M2M system can be thought of as a manager sitting in an office, constantly contacting his team of remote workers in a never ending cycle.  The manager asks if everything is ok, and deals with any events that crop up.  To do this, the manager must know how to contact and exchange information with each of his workers. And because of the repetitive nature of the inquiries, and the limited topic of the discussion, they all use a ‘shorthand’ language that they mutually understand.  This allows them to communicate quite efficiently between themselves.  But their language is not easily understood in the wider world, and it cannot easily adapt to new situations and use cases.

IoT on the other hand, is about systems of systems. It’s about producers of data publishing information without needing to know what applications or users will be consuming that data. It’s about making data available to multiple systems in a way that can be expanded and revised as new requirements emerge. It’s about being able to investigate dependencies and causality between seemingly unrelated data feeds. It’s about optimizing not just a single process, but optimizing an entire ecosystem, and having the ability to adapt and evolve as new requirements and use cases emerge.  It’s about repurposing data, and combining it freely without having to define everything that we want to do on the first day of the project. The initial use case may justify the ROI for the system, but we don’t necessarily have to know how we want to expand the system in the future. IoT architectures need to provide this flexibility, which has never been a major consideration in traditional M2M.

Think of it as being “Twitter for machines”. If I am a device, all I have to do is subscribe to a topic of interest.  I don’t need to know who is tweeting, or how they are connected to the network.  I simply receive the relevant information, and I can then determine what to ignore and what to act upon. Other devices that are interested in the same topic, for reasons of their own, can also choose to follow it. Like me, they will receive the information without having to make any changes to the producers of the information.  And they can do it without affecting me and what I am doing.  New devices can subscribe to the data at any time, and existing devices can unsubscribe at any time. None of these devices interfere with one another. Similarly, additional producers of information can come online at any time and begin contributing their information to the knowledge pool.

Many kinds of data are mission critical, of course. And in the IoT world, information is being transferred without human intervention. Our security and recovery procedures need to be very robust. We also need topic definitions that have finer granularity than a simple hashtag.

Let’s come back to the engineer who inspired this blog, and his comment that “we transmit it to the enterprise”.

His comment ignored the critical contribution made to IoT architecture by the edge device located at each remote asset. Unlike traditional M2M equipment like RTUs, PLCs or simple routers, IoT edge devices provide data processing functions before passing the data along.  The IoT edge device not only provides the physical network interface for lower order devices and sensors, it provides the necessary translation as well as the decoupling between the data recovered from these systems and the information sent to the enterprise.

• It filters out data with little or no value. (Example: “The temperature in the room I’m in is the same as it was 10 seconds ago – do I really want to pass this information on to this enterprise system?”)
• It aggregates this into summary data. (Example: Min, mean and max temperature values in the room each hour.)
• It provides event detection. (Example: The temperature goes beyond a threshold, or has an unexpectedly rapid rate of change. Significant data like this can be prioritized and sent immediately.)
• It provides data enrichment, contextualizing information into something which is self defining and semantically searchable. (Rather than sending “PLC31 register 40072 has a value of 2078” it would send something like “B+B Galway / Tims office {date: 1 Dec 2015, time: 10:40, temperature: 20oC.)
• It provides communications management and security around the data transactions.
• It allows user business logic to be embedded in the edge device to provide highly responsive local intelligence.

It’s very easy to talk about IoT while missing the devil in the detail. “We send the data to the enterprise” is a very obvious example of this. If you really want to know the difference between M2M and IoT, consider the phrase, “I don’t know what I don’t know”.  M2M systems have historically ignored the unknown, whereas IoT architectures embrace it.

Tim Taberner
Global Product Manager, Advanced IoT Cellular Gateways