The Need for IoT Open Standards - Fusion PPT

The Need for IoT Open Standards

Will there be any device in the future that will not be able to connect to the Internet of Things? The range of “things” is already vast, and getting vaster by the day. Yet web connection is only one part of the story. To exploit their full potential, these things also need to talk among themselves, so that one machine can enlist the help or cooperation of others for automatically coordinated actions. A simple building automation example might involve IoT devices working together to simultaneously control TV screens, window blinds, and lighting.

When Each Device Does Its Own Thing

The diversity of devices increases the difficulties of getting them to work together. It also makes it more challenging to manage them, secure them, and plan for their data storage and power consumption requirements. Ideally, IoT devices would be designed to meet common standards for communications, interoperability, processing and programming interfaces, and hardware platforms. Better still, these standards would be open to help keep prices at reasonable levels and prevent any unreasonable concentration of power in the hands of one or two vendors.

Existing Open Standards Lack Security

In the industrial world and IIoT (the Industrial Internet of Things), open standards already exist for machines to communicate with one another. In power grids, for instance, standards commonly used include IEC 60870-5-101, IEC 60870-5-104, IEC 61850, OLE for Process Control Data Access (OPC DA), and DNP3. The problem is that these standards have been defined with little or no attention to security, as victims of malware targeting the electricity sector have found out.

Initiatives to Define Better IoT Standards

IEEE offers its IEEE P2413, “IEEE Standard for an Architectural Framework for the Internet of Things (IoT)”, but otherwise secure open IoT standards appear to be in short supply. Other options include initiatives driven by vendors or industry consortiums:

  • Google recently announced Thread, a new network protocol for use between consumer IoT devices. Thread is based on a low-power radio protocol called “IPv6 over Low power Wireless Personal Area Networks” or 6LoWPAN for short. The aim is to make mesh networks of hundreds of devices possible, with no single point of failure and “banking-class encryption”, according to the Thread specifications.
  • Qualcomm developed the AllJoyn protocol, presenting it to the public in 2011, and thereafter making it open source. Together with The Linux Foundation, Qualcomm formed the AllSeen Alliance, bringing in Cisco, Microsoft, LG, and HTC. AllJoyn is device, operating system, and network agnostic, and therefore, at least to some extent, future-proofed.
  • Intel, Cisco, AT&T, GE, and IBM formed the Industrial Internet Consortium with the stated goal of developing standards specifically for the IIoT.
  • AMD, ARM, Imagination Technologies, LG Electronics, Mediatek, Oracle, Qualcomm, Samsung, Texas Instruments, and others created the heterogeneous System Architecture Foundation. This organization has defined a new open computing system architecture with programming tools to allow developers to integrate different kinds of microprocessors and computing resources. The unofficial goal is “write-once, run (nearly) anywhere”.

For smart cities and communities specifically as well as for IoT in general, the International Telecommunications Union has produced its SG20 emerging standard, which is in turn “is responsible for international standards to enable the coordinated development of IoT technologies, including machine-to-machine communications and ubiquitous sensor networks.”

Fighting It Out in the Market Place

Some of these initiatives to define standards clearly compete with others. As in other standards battles (the classic case of VHS versus Betamax video-recorders is often cited), marketing tactics or corporate clout may have as much of an impact as technological superiority in swaying opinion. For the moment, IoT device and system developers will have to watch the evolution and popularity of different candidates to decide which standard(s) to build into their products. IT departments will need to do the same, to plan procurement and put robust, correctly performing solutions in place.