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

Security in Linux Kernel - Part 3

Image
  In this short post we will explore a Linux system call facilitating secure computing. In earlier parts of this series we saw how LSMs protect the kernel. However, LSMs occupy a much deeper position in the call hierarchy and do not offer protection at process level. Additional mechanism is required to provide protection at process level. Need for a system call In Linux, applications programs use a number of system calls, in fact a large number of system calls are available to applications programmer. These processes using system calls expose a large area of the kernel to malicious attacks. Linux offers a mechanism to limit this capability using seccomp system call, thereby reducing the attack surface. seccomp is enabled using prctl() system call with appropriate operation mode. seccomp Modes The seccomp system call works in two modes - strict mode (SECCOMP_SET_MODE_STRICT) and filter mode (SECCOMP_SET_MODE_FILTER). When seccomp is set to first mode, i.e. strict mode , process has ...
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