Does the Internet of Things Need a Standardized Communication Architecture?

We may have to wait five or more years for the industry to reach a consensus on standards. Could the smart use of the right types of software bring us to a viable IoT communication architecture sooner?
Published: November 7, 2016

The true power of the Internet of Things is its far-reaching foundation—the more devices we connect, the more powerful our data and insights will be. Could sensors on a tractor and harvester help a refrigerated truck fleet optimize its operation? It may not seem like there’s any overlap now, but who knows where data could be useful in the future? One big problem the IoT faces is the interoperability of data-collecting devices made by different vendors with various communication capabilities and requirements. The McKinsey Global Institute cited interoperability as the difference between the IoT being a $7 trillion market and a $11.1 trillion market by 2025—that’s a $4 trillion problem!

For the IoT to continue to grow, there is no doubt that we need devices and systems to work together seamlessly. But do we need standards to shepherd us there? Or is there another free-market solution? Let’s look at where things stand now, and what some possible solutions might be. First, let’s consider the complex communications stack that devices use and the different options that are available:

When IoT technologies that use these various layers and combinations are combined, it is inevitable that communication between devices will be misunderstood. For example, it is very likely that smart-home users could have a connected thermostat from one manufacturer that cannot interact with a light bulb from another, due to one using Wi-Fi and the other ZigBee, one transporting data with MQTT and the other HTTP, or each requiring data to go through separate proprietary clouds. Consumers locking themselves into a single ecosystem could provide a short-term solution to this problem, but not one that would solve the industry’s issues in the long term.

The same concerns are relevant at the enterprise level as well. Take a farm that bought soil moisture sensors several years ago and now wants to leverage those sensors’ data together with a brand-new smart tractor. Without unified communication standards, doing so would require a significant amount of engineering work to integrate the two systems, which is not what farmers are familiar with and not what they bought into. You can see that this is a pretty tangled web that we’re trying to unravel to reach a seamlessly connected future.

So, the question is this: How can we, as an industry, enable seamless interoperability between devices? Here are a few options, some more viable than others:

• Wait it out and hope there are a few winners in the IoT, or a niche within the IoT: Delaying a project for years, with no clear decision on the horizon, is not a great option, but “wait and see” could be right for some projects that are lower in priority. Even if you wait for five years for a consensus among industry players, it may take much longer and there will inevitably be some legacy devices that cannot be easily or cost-effectively replaced. This option just isn’t reasonable for most.

• Build in closed ecosystems using standards defined by an organization: Selecting devices based on the preferences of a certain standards group or industry organization may be an option for some. Now that the Open Connectivity Foundation and the AllSeen Alliance have merged, that may be an alliance to look to in the future, but big players like Apple, Google and Amazon still are not involved. So for now, there are no groups sufficiently established to fully standardize most offerings. Being locked into an ecosystem limits flexibility to select any device and often drives up prices, because users must buy from within the ecosystem.

• Add gateways and other hardware to translate and connect different stacks: This approach is being used in many projects, but adds to an implementation’s complexity and cost by adding extra hardware and steps to get data to where it needs to go. This is a solution to make things work, but it’s neither elegant nor cost-effective for projects looking to achieve a positive return on investment.

• Abstract and decouple elements of the communications stack: Working around the layers on the software side, by decoupling communication layers to allow certain layers to be swapped out, can enable significant flexibility in communications. With the right software in place, lower layers such as link and transport can be very different and still work with an MQTT application layer.

Regardless of how a project overcomes interoperability obstacles, good planning up front to consider what may come in the future will serve any project well. At infiswift, we see a consensus on standards as part of the solution, but not the whole solution to interoperability. Rather than waiting out the prolonged back and forth coming between the many alliances and organizations trying to come together on a single standard or group of standards, we would like to see much of this complexity abstracted from the communications stack, using software to help old and new devices communicate with each other more easily—regardless of manufacturer or stack choice.

With true interoperability in the future, the refrigerated truck fleet manager mentioned earlier will be able to easily tap into diverse data sources that are important to his operation. With information collected from tractors and harvesters on the farms, the fleet manager will be able to determine precisely when a batch of produce is ready for pickup, and thus arrive exactly when a harvester is pulling up. It’s impossible to know what data sources may be important in the future, but what we do know is that true interoperability will drive the IoT from concept to reality.

Arup Barat is the co-founder and chief commercial officer of infiswift, an enterprise IoT platform provider based in San Ramon, Calif., where he guides commercialization activities through product, marketing, sales, business development and customer success.