A comparison of open standards for the IoT

Prometheus gave us fire and the power to see, in Greek mythology. And as we give intelligence and connectivity to our physical world – electricity grids, manufacturing plants, and everyThing between – we need well-structured open standards so…

(Image: VectorStock)

Prometheus gave us fire and the power to see, in Greek mythology. And as we give intelligence and connectivity to our physical world – electricity grids, manufacturing plants, and everyThing between – we need well-structured open standards so devices can see and talk to each other easily, in the same language. This enables AI to more effectively process the data, and we can continually find new, beneficial and valuable use cases. It also means we’re not locked into a particular vendor; and we have the assurance of a peer-reviewed, rigorously tested system with strong community support. If we make interoperability difficult, we are limiting innovation, and limiting evolution of the IoT and the progression it can bring to our planet.

Let’s take a look at the strengths and weaknesses of three sets of open standards for IoT.

• Uses the lightweight CoAP application protocol defined by RFC7252 and RFC8323. Easy for manufacturers to interpret and use.
• Production ready, developed from 2014.
• Open-source with contributions from Intel, Cisco, Samsung, CableLabs, and others.
• Many data models defined, meaning versatility and ready adaptability to utilize data from the diverse IoT for many purposes.
• Specifications defined for Device2Device, Device2Cloud and Cloud2Cloud connectivity.
• Native device library as well as cloud native reference implementation.

• Not adopted by consumer manufacturer.
• High-level of security can slow initial phase of some projects.

• Backed by giants Apple, Google, Amazon.
• Adopted by consumer manufacturers.
• Big marketing budgets.

• Application protocol data model encoding defined in their own specification – difficult for other manufacturers to interpret and use; less efficient; compatibility issues.
• Need to define data models for devices. Labour intensive, and can be difficult to keep data models up to date as new devices are released.
• Less well established, developed from 2019.
• Defined Device2Device only, so you need to use Google (Google Assistant), Apple (Siri), or Amazon (Alexa) clouds and share your data with them.

• Uses COAP/MQTT/HTTP application protocol with CBOR/JSON. Easy for manufacturers to interpret and use.
• Main protocol is HTTP. Well established, easy to use, efficient protocol.

• Developed from 2013, but not officially released yet.
• Not adopted by many manufacturers.

Clearly each of these three sets of standards has its strengths and weaknesses. As we look towards progression in IoT, the OCF is the strongest contender with its accessible application protocol, many data models, and reference implementation; though adoption by more manufacturers would help its case. We look forward to broader adoption with time.