POV on Architecture for Internet of Things
This article embodies the architectural thoughts on Internet of Things for Architects and developers. The aim of this paper is to provide a base architecture that covers challenges and main requirements of IOT projects and systems - devices, server side, cloud based services, third party integration that interact with and manage the devices.
1.1 What is Internet of Things?
The Internet of Things (IoT) is a scenario in which objects, animals or people are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. IoT has evolved from the convergence of wireless technologies, micro-electromechanical systems (MEMS) and the Internet.
A thing, in the Internet of Things, can be a person with a heart monitor implant, a farm animal with a biochip transponder, an automobile that has built-in sensors to alert the driver when tire pressure is low -- or any other natural or man-made object that can be assigned an IP address and provided with the ability to transfer data over a network. So far, the Internet of Things has been most closely associated with machine-to-machine (M2M) communication in manufacturing and power, oil and gas utilities. Products built with M2M communication capabilities are often referred to as being smart. ( smart label, smart meter, smart grid sensor)
1.2 DevicesThe simplest devices have embedded controllers - they have no operating system
Devices with 32-bit system that can support OS - such as Linux
Devices with 32 bit/64 bit computer platforms such as a wearable watch that can connect to internet and support 2 way communication
Devices that communicates to gateways; these gateways perform filtering, aggregation, event processing
The way devices communicate with gateways/internet could be based on:
Ethernet, WiFi using TCP/IP or UDP, MQTT, http, CoAP
UART, SPI/ I2C
Near Field Communication(NFC)
Zigbee and mesh networks in RF, blue tooth
Low Power Bluetooth technology
We have to address the obstacles to the connection to the devices - Firewalls, Network Address Translation (NAT) and other obstacles on the way.
There could be issues in connectivity of devices due to internet connectivity, battery life, RF interferences, simply being switched off, physical security/damage etc.,
There is plethora of protocols, vendors in this space. Inter-operability among these and derive the required data from these could be a challenge.
3.0 Key Requirements:
· Device management - remote provisioning and upgrade of firmware/software.
· Device security is mandatory - only the authorized personnel should have access to the information from the devices. Also, lock and isolation of impaired/hijacked devices should be supported.
· Ability to process live stream of data and apply configurable complex event processing/rules on the incoming data to respond real time/near real time.
· Support for time series data and transformation of data to the granularity required for reporting.
· Leverage existing open/marketplace API's, technologies - should have a loosely coupled architecture, where we can plug/play/replace these components.
· Multi modal communication API's - support for tablets, mobiles, web applications and other third party integration.
· We need an architecture that scales well (horizontal) with addition of devices; should have high availability and fault tolerance features. Should support cloud hosting.
4.1 Device Layer:
Sensors, Actuators, Bar code reader, RFID readers, wearable, smart meters, GPS locators, mobile phones, google glass, biometric sensors, drones are examples of devices in this layer. They communicate in various protocols covered in Section 1.2. Gateways can act as protocol translators, data aggregators, data cache (where connectivity is intermittent).
4.2 Data Ingest/Processing Layer:
The data from the devices is accessed over various protocols as mentioned above and protocols with lowest overhead over payload - MQTT and CoAP are clear winners on this account.
We can have an implementation of Agent Hub running in the device/gateway layer, which would collect the data from devices and send it over to a Central Registry (which is the case with Bosch M2M platform) in the ingest layer.
We need a filter, adapter, transformation are part of data ingestion; Complex event processing (CEP), Business process Modeling (BPM), Business Rules Modeling (BRM) are in the Processing layer. A pub/sub model is best for handling data at this layer. Choices could be ActiveMQ, RabbitMQ or cloud bases offerings such as SQS. CEP is available in many flavors - open source tools such as WS02, ESPER; enterprise tools from Oracle etc; also, Storm/Spark from Hadoop world. Data in flight Analytics using R or any other similar tool can be done in this layer. Volume/Variety will decide the selection of tools in this layer.
4.3 Data Storage and Access Layer
SQL and NoSQL data bases are candidates for storing data. Depending on the volume HDFS can be used as well.
Recommended data access to the consuming applications is over REST API. This layer of abstraction enables access across different data sources.
Employee health and Safety, Remote Monitoring, Track and Trace, Traceability, Predictive Maintenance, Risk/Fraud Analytics, Digital Farming, Industry 4.0, Connected Vehicle Technology, Smart Home/Factory/Warehouse/City are some of the applications in this space.
he Quality of Service is across all the layers - it should support non-real time, soft real time, hard real time depending on the application requirement. Architecture should support measuring the latency, data loss, ability to handle duplicate data, late arriving data, identify error in data. Instrumentation should be provided in all the services in the system that is capable of reporting the health, resource utilization, efficiency etc.,
Security risks associated with using inherent internet and risks that are associated with IoT devices should be addressed. Best practices such as encryption, Identity and access management with OAuth/OAuth2 (tokens rather than username/password) are suggested. XACML based Attribute/Policy based Access control are appropriate.