There is a group on LinkedIn with lively (read: mostly polite; only sometimes blustery) discussions peppered by insightful, lengthy comments from across the professional spectrum: a CEO, a CTO, an IBM executive, a Twitter developer, an M2M technologist, an EVP of sales and marketing.
What’s bringing them all together? The standards debate swirling around the Internet of Things: how best to connect devices, infrastructure, applications, data, and the cloud.
This makes sense given the complexity of the Industrial Internet: protocols are required to connect everything from mobile devices and home appliances to wind turbines and electric grids. And the major companies backing those industries are also backing standards. IBM has designed the MQTT protocol, Cisco is unveiling an IoT cloud offering based on XMPP (and other protocols), ARM’s Sensicode group is behind open standards such as IPv6 and REST. And, according to EE Times, “plenty of other giants and startups are already active or have plans in cloud IoT. They range from Amazon, Google, and Microsoft to less well-known names such as Arrayent, Axeda, and Berg Cloud.”
The result to all this protocol proliferation? A lack of any one common standard to overlay the existing, in-use standards. According to another EE Times article, this lack of standards is one of the main barriers to mass adoption of connected devices:
Many players are developing their own M2M and IoT networks, effectively creating a Tower of Babel that will make it difficult to manage and connect all these devices. In the words of Adam Gould, vice president of the Sensinode Business at ARM:
We need standards at the radio level, the security layer, and the data format level… For developers it is necessary that they know that those devices are going to be able to talk to each other and [that they] really focus on the application.
The Big Guns
In March, five of the bigger players in the Industrial Internet – AT&T, Cisco, GE, IBM and Intel – announced the formation of the Industrial Internet Consortium (IIC), a group focused on “breaking down the barriers of technology silos to support better access to big data with improved integration of the physical and digital worlds.”
Under the umbrella of the Open Management Group, IIC’s charter is to encourage innovation, through several initiatives:
- Utilizing existing and creating new industry use cases and test beds for real-world applications
- Delivering best practices, reference architectures, case studies, and standards requirements to ease deployment of connected technologies
- Influencing the global standards development process for Internet and industrial systems
- Facilitating open forums to share and exchange real-world ideas, practices, lessons, and insights
- Building confidence around new and innovative approaches to security
Perhaps what’s more telling about the potential for success for this group is the fact that the federal government is also part of the consortium. And not in name only; the Feds are investing over $100 million a year in R&D related to “cyberphysical” systems, partnering with private sector companies on a series of testbeds in various sectors, including: healthcare, transportation, smart cities, and increasing the security of the electricity grid.
This is not the first consortium of companies to put forth a standards effort. A consumer products consortium, AllSeen Alliance, is the culmination of 23 companies that have pledged to use the code underlying Qualcomm’s Alljoyn protocol to build products that not only talk to each other, but have more automated device programming environments. In December 2013, Qualcomm signed over the source code for the AllJoyn protocol to the Linux Foundation. The goal: create a new standard for the Internet of Things.
The Bottom Line
Despite the apparent protocol wars brewing, the bottom line is this: the Industrial Internet, like the Internet today, will require many protocols. As one commenter in the LinkedIn group put it: “Regarding your comment: MQTT is engineered for constrained environments & wireless, not ‘made for LAN deployments,’ This is exactly the point. You need to know the protocol and know what it is good at, and what it is not good at.”