This is an article in a series being done by IoT Forum. We noticed many startups are being founded by professionals from Software service and product background and making choices with insufficient appreciation of the consequences. More coverage will be posted at IoTForIndia.org. This is co-authored by Arvind Tiwary and Somshubhro (Som) Pal Choudhury.]
Internet of Things (IoT) encompasses different technologies and standards from the sensor to the cloud. IoT is multi-faceted and inter-disciplinary, encompassing a plethora of networking protocols and technologies, using the latest advances in sensors, wireless connectivity, analytics, AI and with the need of security from the physical world to the cyber domain.
Under the challenges of having a complete IoT system working, a natural tendency is to have it vertically integrated, build it grounds up, owning as much as possible, very similar to older generations of IoT/M2M deployments in a vertical or silo-ed approach. This is particularly true in the early days when the core horizontal components are not yet matured and standards still emerging. So everybody builds bottoms up. This also has roots in industrial SCADA world where reliability and control are paramount. However with the scaling up of open innovation around Internet technologies, we now know that a vertically integrated single source approach is expensive, slow moving and can put the brakes on innovation and mass adoption. Today’s world is also rich with availability of open source components and modules that can be effectively leveraged. While reliability and security is still of paramount importance, how can a layered approach with few standardized or even open sourced aspects enhance innovation?
The ISO 7 layer model of communication is a great example of layered architecture which has led to mass deployment of networking everywhere.
In this, the webserver services Http requests (Application layer) irrespective of the method of data link (Cellular, WiFi, Ethernet etc.) and type of device (PC, smartphone, server etc).
Layering has proven to be exceptionally successful architectural principle. Each layer acts as an interface to the layer above and the layer below and isolates the top layer from the bottom layer. This interface approach is very common. For example, when we add a new printer to a desktop normally it will be plug-n-play. At worst we need a driver which will adapt the specifics of the new printer to the common printer interface used by the operating system. This interface approach allows a very diverse range of printers to be supported. We also have virtual printers and can print a web page to a pdf!
It is possible to conceptualize a similar layered architecture for IoT stack – From Sensor to the Cloud. We envision the IoT stack as shown in figure below, though in practice this is still work under progress and not there yet. The Touch Point layer is unusual but important as IoT is a lot about automation and machine to machine (M2M) interaction. Analytics is strictly an application or a class of applications and not a layer.
Unfortunately, in the world of IoT, there is a great deal of coupling between devices, the data and connectivity and applications. Some applications are closely tied to Internet communication like TCP/IP and not available on popular non Internet communication methods like Bluetooth or LPWAN. In the past, the applications were tied to specific sensors and replacing a sensor or device with another needed significant rework (assumptions of temperature units, frequency, accuracy and error correction and calibration for drift as well as communication endpoint and encoding and encryption…). Examples of interoperability requirements can be explored in different scenarios.
IoT standards have tried to address these in various ways. Zigbee is popular in Smart Home based on IEEE 802.15.4. Zigbee Alliance defines public application profiles and devices are expected to belong to a profile.
Public profiles are designed so that products from one manufacturer (X) can work, right out-of-the-box, with products from another manufacturer (Y). For example, a thermostat from Honeywell can work with a variable-airflow-valve from Trane, or a light from Philips can work with a switch from Leviton. The Home Automation profile describes different types of devices.
A specific device is expected to support some actions. So a remote control may be expected to support: Play/Pause, Skip Forward, Skip Backward, Volume Up, Volume Down etc.
IPSO ( Internet Protocol for Smart Objects) is another standard with broader domains.
Apple’s HomeKit had a goal of providing interoperable home devices within the Apple ecosystem. Others like AllSeen have more broader goals. So, just only in the SmartHome segment, the IoT world is split among fragmented approaches to managing devices. This introduces problems of interoperability if you have mixture of Zigbee, HomeKit and other devices from other manufacturers.
The Hourglass Architecture is one approach to decouple layers and encourage independent evolution across layers. Nandan Nilekani, a former Unique Identification Authority of India (UIDAI) chief, has waxed eloquent on this and the graphic from iSPRIT on India Stack captures the essence.
In the picture of the IoT Stack, the IoT Platform and the Gateway then become the layers of the IoT Stack intended to provide this decoupling for mass flourishing. The innovation happens on the top half of the Hour-Glass where Applications, Analytics & AI and Interfaces rule and the sheer possibilities are endless. On the bottom half, it is probably a narrow funnel with more innovation on the sensors and senor fusion and around 15-20 different connectivity options both wired and wireless.
The beauty of the Hour-Glass architecture is that the innovator focuses on his or her area without the need to worry about the connectivity and interfacing.
There are a number of features provided by popular IoT platforms and the Gateways, the stem of the Hour-Glass Architecture of the IoT Stack. Ability to connect to devices and support different communication protocols and sensor data and actuation commands is the key. The IoT Platform provides application developers with a simpler consistent interface to data from different devices and methods to control them. This Gateway may also include interoperability across Zigbee, Homekit and proprietary solutions from Honeywell, Johnson controls etc.
Competition is intense and M&A activity in this area is also hot. Many platform providers are adding application development features and analytics and migrating from an AEP (Application enablement platform) to an IDE (Integrated development environment). However, they should be seen as a separate function and the platform function of device management, scalability and interoperability should be key.
As our next post, we will talk about the state of affairs and the different features and expectations of IoT Platforms followed by that of Gateways.
