POV on Architecture for Internet of Things
1.0 Introduction:
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 Devices
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
Modbus
Low Power Bluetooth technology
SRF
2.0 Challenges
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.0 Architecture:
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.
4.4
Applications
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.
4.5
QoS/Monitoring
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.,
4.6 Security
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.
5.0 Conclusion: