IoT vs M2M: Understanding the Difference

Use Case

As a system architect, you need to get a sensor solution up and running which won’t fall on its face at the first inkling of success. You need to worry about such things as embedded size constraints, scaling strategies, third party integration, connectivity, economics, implementation skill sets, power, and even future-proofing.

You’ll want your system to grow and evolve while the IoT is trying to figure out what it wants to be when it grows up.

It sounds a lot like you are doing M2M, so how is IoT going to help?

IoT vs M2M: What’s the difference?

“Always design a thing by considering it in the next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” – Eliel Saarinen

If you developed a sensor network before the IoT acronym came along, you’d be forgiven for thinking IoT is just lipstick on M2M. M2M is often associated with point solutions or a fleet of the same kind of thing — a system of Wi-Fi thermostats, a flow sensor network in an oil-refinery, a vehicle location system, home automation, all the heart monitoring telemetry in a hospital. For some in the industry, M2M means anything with a cellular modem on a particular carrier’s network.

Long story short, the key takeaway is that M2M is almost synonymous with isolated systems of sensors and islands of telemetry data. In contrast, the IoT is trying to marry disparate systems into an expansive system view to enable new applications — that’s not only the big idea, it’s the one key difference between M2M and IoT.

“If you consider M2M in the next larger context, you get the IoT.” – Landon Cox

I guess we can say that IoT really stands for “I want it all.” In order to achieve that, major new facets such as first class security, big data, cloud scale, ubiquitous presence, human interactions — all wrapped up in business objective parlance — come to bear.

IoT is a catch-all technology bucket and it’s probably always going to be that way, so let’s make the best of it and make headway amidst all the ambiguity and hype. Here’s how…

One practical way to think about it is: The Internet of Things is the arch connecting M2M vertical pillars (technology stacks). This view allows the IoT to leverage all of the good work that has gone into M2M, incorporate existing legacy M2M systems, yet leave it loosely coupled and abstract enough to describe various business problems (not one size fits all).

In the example above, IoT is marrying health sensor data from three very different sources and contexts, all of which are using different company’s products within siloed M2M ecosystems. Bringing this together provides a better overall picture of a client’s health than individual silos can. IoT technologies, such as cloud scale and security, gain tremendous importance in an application like this, beyond the significance within the silo’s scale.

This view also helps keep IoT from being tied to a specific M2M technology stack. The implication? For IoT to add value not already in M2M, it must provide a fabric that either bridges M2M systems, through analytics or data networking, or fulfill a business mission not addressed by an individual M2M stack.

IoT Caveats

IoT is dangerously close to the SOA vortex (Service Oriented Architecture) and is something we need to be mindful of avoiding. As SOA expert Anne Thomas Manes pointed out in SOA is Dead; Long Live Services, “Perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.”

My summary? Despite some good technology and ideas that came out of SOA, technology that the IoT builds upon, SOA died of its own weight.  We should keep the cause of death of SOA in mind when working on IoT so it doesn’t become a likewise casualty.

I would like to see IoT architecture evolve along the lines of the OSI network reference modeland not SOA (except for the important stuff). That means that IoT should be a simple, common concept used by system architects to design, map, and compare different implementations.

Ethernet and Token Ring, for example, are two very different network technologies, but both map to the OSI reference model. OSI gives us a common way to talk about nearly any network technology. We need the same idea for IoT to make it practical.

From that perspective, we could talk about many different Internet of Things stacks in the same manner we talk about Ethernet, Wi-Fi, TCP/IP, or UDP. Various technologies fit into a common network model (OSI) and are combined in various ways to achieve something useful (i.e. the web).  Same with the IoT: Think of it as a model, like OSI. Specific IoT implementations map to various parts of an IoT reference model like specific networks technologies map to OSI.

So, this is the basic philosophy behind what I would call “practical IoT:”

1. Don’t let the acronym get in the way.
2. Use the right tool for the right job (IoT stack flexibility, not one-size-fits-all, no IoT wars).
3. Ensure IoT is more technology-oriented, like the OSI reference model; less marketing oriented and less like SOA.
4. It has to be more than, and distinctly different from, M2M.

Now where?

I realize this was a really high level view of Practical IoT. Stay tuned for upcoming Desktop IoT tutorials and hands-on demonstrations as we’ll delve deep and get practical with the Internet of Things. In the meantime, imagine, expand and evolve your connected ideas with Atmel’s latest (free) white paper.

This is a guest post from Atmel, and was originally published to the Atmel blog on December 9, 2014. Atmel Corporation is a worldwide leader in the design and manufacture of microcontrollers, capacitive touch solutions, advanced logic, mixed-signal, nonvolatile memory and radio frequency (RF) components.