How Does OpenDOF Compare?

IBM Bluemix, MS IoT Hub, AWS IoT, Alljoyn, CoAP, Ayla Networks, ECHONET Lite, Electric Imp, MQTT-SN, and MQTT

Comparison Terms

There are many options out there and many claims, with their own comparisons. Here you will find how OpenDOF stands when compared to other technologies using several key features as measurements. We will be adding additional technologies as they are reviewed, so check back often.

Features

The definitions we use are important measures for comparison. Our hope is to provide industry-standard terminology and recognized definitions for the features we are comparing. Please read the features and their definitions to understand what we are comparing and why they are important.

• Open standard: The specifications and implementations are open to the public and can be used without royalty or patent concerns.
• Efficient protocols: The protocols used are designed to minimize bandwidth, and therefore cost, and are also designed for efficient parsing, minimizing memory and processing requirements.
• Discovery (including discovery among peers): The ability to dynamically query and monitor for peers or service providers, with notification both when they appear as well as disappear, due to connectivity or topology changes.
• Libraries available for small embedded devices: Provides libraries that are tailored to the specific requirements of embedded systems, including those that may not provide standard operating systems, threading, or memory allocation systems.
• Libraries in multiple languages: Object Access Libraries (OALs) available in Java, C and C sharp.
• Authentication: Efficiently provides authentication of both client and server, and in a way that supports peer-to-peer connectivity where the role of client and server are reversed.
• Encryption: Encryption using state-of-the-art cryptography algorithms (e.g., AES) with minimum 128-bit symmetric key (or equivalent) strength.
• Access control/Permissions: Enforces fine-grained, peer-to-peer permissions that can restrict access to individual functions, properties, and events.
• Strong object oriented model with well defined device interfaces: Provides a consistent and universal approach to object naming and interface definition that applies from the embedded device through any gateways and into the cloud and database.
• Topology independent (supports gateway, peer-to-peer, cloud): Applications are mostly unaware of the system topology and changes to the topology. Any topology can be supported, including typical client/server as well as mesh and multicast systems.
• Cloud provider independent: The ability to operate independent of any specific cloud provider vendor or proprietary technology.
• Transport independent: Operates independent of transport. Applications can move from one transport to another with minimal, if any, change. Transport support can be added by the user through defined APIs.