IoT Platforms

Internet of Things

Entire Internet of Things (IoT) can be represented in 3 tiers as shown in following figure.

Things comprise of a large number of intelligent sensors or devices deployed in field, which gather information about certain aspect of their environment. These devices interact with the “Infrastructure”. The communication media, Internet and server farm or Cloud, are part of the “Infrastructure”. The third part is the “Applications” which run on a wide range of devices are used by the end-user. The applications consume data produced by the “Infrastructure”.
An ideal IoT platform is expected to cover the middle tier (the “Infrastructure”), including the interfaces on both sides.

Ideal IoT Platform

An ideal IoT platform should be reliable and secure. It should be scalable in terms of number of devices connected simultaneously, capability to handle concurrent communication channels etc. It should provide high availability, ease of integration and should be easy to manage from end-user’s perspective. It should be extensible across industries. It should provide extensive interface APIs to application developers in order to have a good number of ready-to-use applications available to the end-user. It should be easy to integrate new types of smart sensors/devices into the system.

At one end of the IoT there is a smart sensor or a smart device. Smart sensor/device needs something to interact with – a “Connector” block which encapsulates underlying protocol semantics and provides an easy communication mechanism to the “Aggregator” node.
Connector understands various protocols (such as Wi-Fi, ZigBee, Z-Wave, Bluetooth (SDR/EDR/LE), 6LoWPAN, etc.) and may also carry out format conversion if required. The “Connector” may interact with one or more smart sensors/devices. Additionally, following are the main features of a Connector:
  • Provides easy device integration
  • Device management, such as,
    • Group control
    • Scheduling
    • Alarm and notification handling
    • Carrier subscription management
  • Device troubleshooting
  • Providing access control, authentication and authorization
The “Connector” block further interacts with the “Aggregator” block. The Aggregator could be a device as simple as a Gateway or can incorporate additional features. Aggregator forwards sensor data to the server/cloud for further processing. It may also provide additional security to the sensors/devices. Additionally, Aggregator may support following functionality:
  • Device data conditioning
  • Device management
    • Firmware updates
    • Device configuration changes
    • Remote device reboot
  • Support for encryption/decryption
Collected data from the smart sensor finally lands in a server/cloud for archival and for further processing. The data is conditioned and made available to applications for the purpose of further analysis, report generation, visualization etc. This part of the chain delivers following functionality:
  • Data archival/retention as per defined policies
  • Secured and controlled access to data
  • Data encryption
  • Data modelling, rules engine, data filtering etc.
  • RESTful web API for application developers
Application developers use these APIs to hook in/provide presentation, analysis and visualization tools for the end-user.

Conclusion

An IoT platform should be reliable, secure and scalable. It should offer high availability, ease of integration, easy manageability and ease-of-use to end-user. It should be extensible and should be developer and integrator friendly. There is a plethora of commercial and Open Source IoT platforms available in the market place with varying degree of functionality coverage. It is essential to identify the requirements first and then select a right platform for IoT solution development to ensure shortest possible time-to-market without compromising on the features.

Comments

Post a Comment

Popular posts from this blog

Security in Linux Kernel - Part 2

Image
  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll
Read more

Trusted Platform Module

Image
In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona
Read more

Common Git Tips

Image
Obtain list of commits git reflog --oneline git log --oneline These commands will also print commit ID - a.k.a. commit hash. Obtain list of branches created by a user git for-each-ref --format=' %(authorname) %09 %(refname)' --sort=authorname | grep <username> Obtain branch hash git show-ref branch_name Delete a local/remote branch Assume that a branch "bugfix/114355" is created to fix a bug. To delete the local branch: git branch -d bugfix/114355 git branch -D bugfix/114355 '-D' is same as specifying "--delete --force" . To remove the remote branch as well: git push origin --delete bugfix/114355 Undo last commit git reset --soft HEAD~1 Roll back repo to a commit To roll-back the repository to a particular commit, follow these steps. find the hash corresponding to the particular commit by checking the commit logs: git log --oneline roll back the repository by resetting the HEAD pointer: git reset --hard <commit_hash> Remove the latest co
Read more