2. Contents
1. Introduction to IoT
1.1. What is Internet of Things?
1.1.1. Definition of IoT
1.1.2. ‘Things’ in Internet of Things
1.2 Two main parts of IoT
2. IoT Reference Model
3. Internet of Things Communications Models
3.1.Device-to -Device Communications
3.2. Device-to -Cloud Communications
3.3. Device-to -Gateway Model
3.4. Back-End Data-Sharing Mode
4. How Internet of Things Works
4.1. Working in non technical terms
4.2. Working of IoT in technical terms
5. Challenges with IoT
3. Introduction to IoT
1.1. What is Internet of Things?
● In simplest language Internet of Thing is the concept of
basically connecting any device with an on and off switch to the
Internet (and/or to each other). Here the domain Thing is
extremely large. This includes everything from cell phones,
coffee makers, washing machines, headphones, lamps,
wearable devices even humans and almost anything else we
can think of. This also applies to components of machines, for
example a jet engine of an airplane or the drill of an oil rig. As I
mentioned, if it has an on and off switch then chances are it can
be a part of the IoT. The relationship will be between people-
people, people-things, and things-things.
5. 1.1.1. Definition of IoT
The more precise definition given on Wikipedia is “The
internet of things (IoT) is the internetworking of physical
devices, vehicles (also referred to as "connected devices"
and "smart devices"), buildings and other items—
embedded with electronics, software, sensors, actuator,
and network connectivity that enable these objects to
collect and exchange data” The Internet of Things (IoT) is a
system of interrelated computing devices, mechanical and
digital machines, objects, animals or people that are
provided with unique identifiers and the ability to transfer
data over a network without requiring human-to-human or
human-to-computer interaction.
6. 1.1.2. ‘Things’ in Internet
of Things
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.
IoT has evolved from the convergence of wireless technologies,
micro-electromechanical systems (MEMS), micro services and the
internet. The convergence has helped tear down the silo walls
between operational technologies (OT) and information technology
(IT), allowing unstructured machine-generated data to be analyzed
for insights that will drive improvements.
8. 1.2 Two main
components of IoT
First main component of IoT is the
device itself. For supporting IoT, device
is connected with some hardware
which support internet connectivity.
This hardware is programmable and
available for any type of device
requirements. These hardware are
called Prototype or Device SDK.
Second, the server on which device is
played. Server helps to monitor device
from any location in the world
9. 2. IoT Reference Model
In an IoT system, data is generated by multiple kinds of devices, processed in
different ways, transmitted to different locations, and acted upon by applications.
The proposed IoT reference model is comprised of seven levels. Each level is
defined with terminology that can be standardized to create a globally accepted
frame of reference. The IoT Reference Model does not restrict the scope or locality
of its components. For example, from a physical perspective, every element could
reside in a single rack of equipment or it could be distributed across the world. The
IoT Reference Model also allows the processing occurring at each level to range
from trivial to complex, depending on the situation. The model describes how tasks
at each level should be handled to maintain simplicity, allow high scalability, and
ensure supportability. Finally, the model defines the functions required for an IoT
system to be complete.
11. 2. IoT Reference Model
The IoT Reference Model provides the highest abstraction
level for the definition of the IoT-A Architectural Reference
Model. It promotes a common understanding of the IoT
domain. The description of the IoT Reference Model includes
a general discourse on the IoT domain, an IoT Domain
Model as a top-level description, an IoT Information Model
explaining how IoT information is going to be modelled, and
an IoT Communication Model in order to understand
specifics about communication between many
heterogeneous IoT devices and the Internet as a whole. The
definition of the IoT Reference Model is conforming to the
OASIS reference model definition.
12. Level 1: Physical Devices and Controllers
The IoT Reference Model starts with Level
1: physical devices and controllers that
might control multiple devices. These are
the “things” in the IoT, and they include a
wide range of endpoint devices that send
and receive information. Today, the list of
devices is already extensive. It will
become almost unlimited as more
equipment is added to the IoT over time.
13. Level 2: Connectivity
● Communications and connectivity are concentrated in
one level—Level 2. The most important function of Level
2 is reliable, timely information transmission.
● This includes transmissions :
● Between devices (Level 1) and the network
● Across networks (east-west)
● Between the network (Level 2) and low-level information
processing occurring at Level 3
●
14. Level 3: Edge (Fog) Computing
The functions of Level 3 are driven by the need to convert
network data flows into information that is suitable for storage
and higher level processing at Level 4 (data accumulation).
This means that Level 3 activities focus on high-volume data
analysis and transformation. For example, a Level 1 sensor
device might generate data samples multiple times per second,
24 hours a day, 365 days a year. A basic tenet of the IoT
Reference Model is that the most intelligent system initiates
information processing as early and as close to the edge of the
network as possible. This is sometimes referred to as fog
computing. Level 3 is where this occurs.
15. Level 4: Data Accumulation
Networking systems are built to reliably move
data. The data is “in motion.” Prior to Level 4,
data is moving through the network at the rate
and organization determined by the devices
generating the data. The model is event
driven. Most applications cannot, or do not
need to, process data at network wire speed.
Applications typically assume that data is “at
rest”—or unchanging—in memory or on disk.
At Level 4, Data Accumulation, data in motion
is converted to data at rest.
16. Level 5: Data Abstraction
IoT systems will need to scale to a
corporate—or even global—level and will
require multiple storage systems to
accommodate IoT device data and data
from traditional enterprise ERP, HRMS,
CRM, and other systems. The data
abstraction functions of Level 5 are
focused on rendering data and its storage
in ways that enable developing simpler,
performance-enhanced applications.
17. Level 6: Application
●
Level 6 is the application level, where information interpretation
occurs. Software at this level interacts with Level 5 and data at rest,
so it does not have to operate at network speeds.
● Level 7: Collaboration and Processes
●
One of the main distinctions between the Internet of Things (IoT)
and IoT is that IoT includes people and processes. This difference
becomes particularly clear at Level 7: Collaboration and Processes.
The IoT system, and the information it creates, is of little value
unless it yields action, which often requires people and processes.
●
18. Summary
The Internet of Everything (IoT) Reference Model is
a decisive first step toward standardizing the concept
and terminology surrounding the IoT. From physical
devices and controllers at Level 1 to the
collaboration and processes at Level 7, the IoT
Reference Model sets out the functionalities required
and concerns that must be addressed before the
industry can realize the value of the IoT. With the
goal of enabling the IoT, this reference model
provides a baseline for understanding its
requirements and its potential.
19. 3. Internet of Things Communications Models
In March 2015, the Internet Architecture Board (IAB) released a
guiding architectural document for networking of smart objects (RFC
7452),39 which outlines a framework of four common communication
models used by IoT devices.
3.1. Device-to -Device Communication model
The device-to-device communication model represents two or more
devices that directly connect and communicate between one
another, rather than through an intermediary application server.
These devices communicate over many types of networks, including
IP networks or the Internet. Often, however these devices use
protocols like Bluetooth,40 Z-Wave,41 or ZigBee 42 to establish
direct device-to-device communications, as shown in Figure
20.
21. 3.2. Device-to -Cloud Communication model
In a device-to-cloud communication model, the IoT device connects
directly to an Internet cloud service like an application service provider
to exchange data and control message traffic. This approach frequently
takes advantage of existing communications mechanisms like
traditional wired Ethernet or Wi-Fi connections to establish a
connection between the device and the IP network, which ultimately
connects to the cloud service. This is shown in Figure
22. 3.3. Device-to-Gateway Model
In the device-to-gateway model, or more typically,
the device-to-application-layer gateway (ALG)
model, the IoT device connects through an ALG
service as a conduit to reach a cloud service. In
simpler terms, this means that there is application
software operating on a local gateway device,
which acts as an intermediary between the device
and the cloud service and provides security and
other functionality such as data or protocol
translation. The model is shown in Figure 3.
23.
24. 3.4. Back-End Data-Sharing Model
The back-end data-sharing model refers to a
communication architecture that enables users to export
and analyze smart object data from a cloud service in
combination with data from other sources. This
architecture supports “the [user’s] desire for granting
access to the uploaded sensor data to third parties”.
This approach is an extension of the single device-to-
cloud communication model, which can lead to data
silos where “IoT devices upload data only to a single
application service provider’’.A back-end sharing
architecture allows the data collected from single IoT
device data streams to be aggregated and analyzed.
25.
26. 4. How Internet of
Things Works
We know that all devices cannot directly communicate with each other.
They need some medium and protocol to communicate with each other.
4.1. Working in non technical terms
First, there’s the underlying technology, the various wireless radios that
allow the devices to connect to the Internet and to each other. These
include more familiar standards like Wi-Fi, low-energy Bluetooth, NFC
and RFID, and some that most rarely heard of, like ZigBee, Z-Wave
and 6LoWPAN
Then there are the things themselves, whether they’re motion sensors,
door locks or
27.
28. light bulbs. In some cases, there may also
be a central hub that allows different
devices to connect to one another.
Finally, there are cloud services, which
enable the collection and analysis of data
so people, other devices can see what’s
going on and take action via their mobile
apps, Intelligence programs.
29. 4.2 Working of IoT in technical terms
Working on IoT starts with the thing which needs to be monitored on Internet. To monitor the device
some sensors or actuators are connected with it. For example the sensors in AC to record the
temperature and actuator to set the temperature. Till now device is not smarter. the device is required
to be connected with internet. Now to facilitate communication with device the IoT service providing
company(eg. konekt.io) provides a Prototype. Working of prototype is explained separately. This
prototype is embedded with the device. The prototype is also called as Software Development Kit
(SDK).
When data is transmitted by Prototype it reaches its destination present on Internet. The destination is
IoT service providing company’s servers. At the IoT server Data is checked for authentication. The
IOT servers have various features. The data is then fed to the Virtual Device and Rules Engine.
Virtual device and rules engine are present on the server. From there data is processed and then
rules engine commands the device based on users requirements.This is how IoT works.
30.
31. 4.2.1. Virtual Device
(Device Shadow)
Virtual Device is virtual version, or “shadow,” of the device on the server. A thing shadow is
actually a JSON document that is used to store and retrieve current state information of a thing
(device, app, and so on). We can use the thing shadow to get and set the state of a thing over
MQTT or HTTP, regardless of whether the thing is connected to the Internet. Each thing shadow
is uniquely identified by its name. We can retrieve the last reported state of a device or set a
desired future state through the API or using the rules engine.
Device Shadows make it easier to build applications that interact with your devices by providing
always available REST APIs. In addition, applications can set the desired future state of a
device without accounting for the devices current state. IoT server compares the difference
between the desired and last reported state, and command the device to make up the
difference.
The Device SDK makes it easy for the device to synchronize its state with its shadow, and to
respond to desired future states set via the shadow.
32. 4.2.2. Rules Engine (Application Program)
● Rules Engine helps in building applications that gather, process, analyze and act on data generated by
connected devices at global scale. Rules engine actually are the services provided by the IoT servers to
command device automatically based on past and present state. Rules in rules engine can programmed
by user on the console provided by the IoT service providing company. The Rules Engine can also route
messages to various other applications, devices and various other backend services.
● We can write rules using a SQL-like syntax. Rules can be authored to behave differently depending
upon the content of the message. For example, if a temperature reading exceeds a certain threshold it
could trigger a rule to transmit data to AWS Lambda. Rules can also be authored to take into account
other data in the cloud, such as data from other devices. For example you could say take an action if this
temperature is more than 15% higher than the average of 5 other devices.
●
33. 4.2.3. Work of Prototype
(Software Development
Kit)
The prototype, also known as Software Development Kit (SDK) is the
hardware that is embedded with device. It is used as an interface
between device and web application. The SDK is programmable and
facilitates communication with device via MQTT, Websockets, HTTP.
● The SDK is connected with all the input and output pins of the device,
actuator and sensor. SDK is programmed in such a way that it
receives data from the device, process that data with the software
installed on SDK and transmit data.
●
34.
35. 4.2.4. Features of SDK
● Gives a unique identity to device (using IpV6 address).
● Sends event data
● Receives messages
● Maps server commands to device functions.
● Buffers data when network connection is down
● Batches messages to improve communication efficiency.
● Supports pluggable transport protocols. HTTPS and AMQP
protocols
●
36. 5. Challenges with IoT
5.1. The Need for Open Standards
●
The IoT consists of a lot of individual devices with their own specifications. Further growth in IoT
will require that smart devices can communicate with each other.This is solvable if we can agree
on standards instead of constantly aiming to disrupt, define or own aspects of this growing
ecosystem. The IoT has the potential to redefine our world and could help solve some of its most
pressing problems but for that to happen, we'll need to work together."
5.2. Sharing data
● "Connected and sensor-enabled devices that monitor a person's health are growing in popularity.
It's likely we will see more of them in the future, as they have the potential to greatly improve
health and reduce the cost of delivering care. There are however many unanswered questions,
including who can access a person's data, how to ensure device and data interoperability, and how
closely national or private care should be directly tied to ownership of such devices."
37. 5.3. Energy Demands
● Several years ago, Gartner predicted that 4.9
billion smart devices would be used by 2015
-- an increase of thirty percent from 2030. By
2020, Gartner estimated that the number of
smart devices would reach 25 billion by 2020,
an increase of 100% each year. In 2012, the
data centers that powered the Internet were
estimated to require 30 billion watts of
electricity a year -- enough to power a
medium-sized town, and the Internet of
Things is likely to require even more.
38. 5.4. Storage Issues
● Storage of information generated by smart devices will increase the energy
demands required by the Internet of Things. A single corporation like Google, which
already has myriad server farms, each occupying tens of thousands of square feet,
could be dwarfed by the demands of smart devices.
● However, the physical demands are only part of the problem. Much of the data
generated by smart devices is needed only briefly to send signals to device, and
does not need to be stored. Other data, such as timers for devices, might ordinarily
need to be stored for only a week or two at the most.
39. 5.5. Lack of Privacy and
security issues
● Potentially, the Internet of Things is a wealth of information
about those who use it. Smartphones can already be tracked,
but smart devices point to a future where governments
supplement census information with the output of smart
devices, and manufacturers harvest information about your
habits so efficiently that they make Facebook's insights into
your interests and buying habits seem vague.
● At any rate, no matter how secure a device can be potentially,
users can be guaranteed to remove much of the security. For
example, I recently bought a router whose default login that
gives access to a configuration file stored on my computer was
"admin" and "password."