(Part 3) IoT Platforms: Common Building Blocks & Key Differentiators

(This is Part 3 of series of three parts. In Part 1 and Part 2, we saw the common building blocks of an IoT platform and commonly used technology stacks. In this part, we will talk about key differentiators when we compare multiple IoT Platforms)

With the common building blocks discussed in Part 2 being in place for many of the platforms to a varied extent, the following are the important differentiators. In some sense, they indicate maturity of an IoT platform. A more matured IoT platform will be easier to customize and start using.

Architecture – Platform architecture should support multi-tenancy in all the layers. It should allow scaling as required and support distributed computing.

Supported IoT Protocols – The platform should support important IoT protocols like MQTT (and it’s variants like RSMB, MQTT-SN), AMQP, STOMP, HTTP/REST and CoAP to name a few. The interfaces exposed for receiving messages from different protocols should be similar, example – REST URL and MQTT publish URL should have some resemblance and should carry similar payload. It could use message bridges (like, HTTP to MQTT bridge) to achieve this.

Ease of Device On-boarding –The platform should expose APIs for Device Management, which includes device registration and activation. APIs should allow administrator bulk registration of devices or devices self-registering themselves. Activation APIs are required for already registered devices for retrieving the activation key (certificates). This activation key can be used for subsequence API calls.

Security

Devices – The platform should support security based on device activation key and other additional parameters like IP address, location etc.

Role Based Access Control – This is for operator admin for managing policies/rules and reports on his role and permissions per locations and device families.

Rule Engine Customizability

Rule Definition – IoT platform should expose APIs for creating rules. A rule should take inputs like product family, location, payload attributes for matching, matching conditions and action to be taken when condition is met. It could define DSL (sql or jsonpath like syntax) for defining rule queries and corresponding actions. For dynamic rules, it should allow connecting to machine learning or neural frameworks.

Supported Actions – IoT platform should provide out of box implementation of actions to take when rules are met. Some of frequently used connectors are Email, SMS/Text, Republish to message queue, Outbound voice Calls, XMPP and posting on social networks etc. These connectors could be configured with some template messages that can be sent out.

Other Goodies include

• Intuitive, easy to use and well documented APIs with good examples of request, response and error conditions.
• Availability of sand box environment and a developer kit to quickly build a proof of concept IoT pipeline
• Web based portal for admin activities for provisioning devices, rules management, user management and managing dashboard/reports.
• A good search Interface to look up devices and data based on filters, search queries.
• Of course, there will be a commercial view which will be a function of scale and growth of the operations (volume of devices, size of messages, numbers of users etc.), SLAs and other features like reports, dashboard etc. which is not included above.

Thanks for reading this far! Would like to hear your thoughts, views and comments.