unit3-241119090144-4cgfhfxxfh7d92930.pptx

ARI 202
INTERNET OF THINGS
"Anything that can be connected, will be connected"

IOT
ARCHITECTURE
• Internet of Things (IOT) technology has a wide variety of applications and use
of Internet of Things is growing so faster.
• Depending upon different application areas of Internet of Things, it works
accordingly as per it has been designed/developed. But it has not a standard
defined architecture of working which is strictly followed universally. The architecture
of IoT depends upon its functionality and implementation in different sectors.
• Still, there is a basic process flow based on which IoT is built here in this article we
will discuss basic fundamental architecture of IoT i.e., 4 Stage IoT architecture.
So, from the above image it is clear that there are 4 layers present that can be
divided as follows: Sensing Layer, Network Layer, Data processing Layer,
and Application Layer.
2

1.Sensing Layer –
• Sensors, actuators, devices are present in this Sensing layer. These Sensors or
Actuators accepts data(physical/environmental parameters), processes data
and emits data over network.
2.Network Layer –
• Internet/Network gateways, Data Acquisition System (DAS) are present in this layer.
DAS performs data aggregation and conversion function (Collecting data and
aggregating data then converting analog data of sensors to digital data etc).
Advanced gateways which mainly opens up connection between Sensor networks
and Internet also performs many basic gateway functionalities like malware
protection, and filtering also some times decision making based on inputted data
and data management services, etc.
4

3.Data processing Layer –
• This is processing unit of IoT ecosystem. Here data is analyzed and pre-processed before
sending it to data center from where data is accessed by software applications often
termed as business applications where data is monitored and managed and further actions
are also prepared. So here Edge IT or edge analytics comes into picture.
4.Application Layer –
• This is last layer of 4 stages of IoT architecture. Data centers or cloud is management
stage of data where data is managed and is used by end-user applications like agriculture,
health care, aerospace, farming, defense, etc. The best place to start is to define what
an architecture is. Fundamentally, an architecture is a diagram or model that
comprises two parts: the key technology components that make it up and the relationship
between those components.
5

6
IoT architecture components:
• At a high level, the components involved in an IoT architecture include four key
components.
• The applications and analytics component.
• This is the piece that processes and displays information collected via IoT. It
includes analytics tools, AI and machine learning and visualization capabilities.
Technologies for this component range from traditional analytics and visualization
packages, such as R, IBM SPSS and SAS, to specialized IoT tools and
dashboards from cloud providers, such as Amazon, Google, Microsoft, Oracle
and IBM, as well as application suite vendors, including SAP and Salesforce.

7
1.The integration component.:-
This is the component that ensures that the applications,
tools, security and infrastructure integrate effectively with
existing companywide ERPand other management systems.
Providers include the aforementioned software and cloud
players, as well as a range of open source and middleware
providers, such as Oracle Fusion Middleware, LinkSmart,
Apache Kafka and DynThings Open Source IoT Platform.

8
2. The security and management component.:-
• IoT security includes securing the physical components of the system via firmware and embedded
security providers, such as Azure Sphere, LynxOS, Mocana and Spartan.
• Traditional security vendors, such as Forescout, Symantec and Trend Micro, also offer packages
that focus specifically on securing IoT.
3. The infrastructure component.
This includes physical devices -- IoT sensors, which capture information, and actuators, which
control the environment.
• It also includes the network on which the sensors or actuators reside. Typically, though not always,
this is a wireless network, such as Wi-Fi, 4G or 5G.The relationship between the components is
the second part of the architecture.

• By relationship between, we mean how components communicate with each other,
and what sorts of information are exchanged. This can include data flow,
metadata flow, control information or no information at all. Software
components often communicate via APIs, and network layer components typically
communicate via network protocols.
• Speaking of layers, architects often think in terms of component layers, such as
network layer, perception layer, processing layer, physical layer, gateway layer,
platform layer, device layer, business layer, security layer, sensor layer and so on.
• The concept of a layer is that it comprises a set of capabilities that communicate
with one another, but for the purpose of other components can be treated as a
single entity, with a single transparent entity.
• In IoT architecture, the application layer need not know what type of physical
network carries the data. All the network devices comprise the network layer
that transports traffic as needed by the applications.
9

OPEN SOURCE ARCHITECTURE FOR
IOT
• The seven high-level architecture requirements for an IoT based system are:
• 1. Context: Captures the context at all times, 24 hours a day, 365 days a year
• 2. Standards: Uses standards based communication protocols between IoT devices and
enterprise systems
• 3. Scalability: Responds to increased load by a decline in performance, not failure; increases
capacity proportionally as resources are added
• 4. Data management: Efficiently manages huge volumes of data
• 5. Connectivity: Provides high network connectivity for large data payloads and continuous
streaming
• 6. Security: Moves and encrypts information securely even as IoT introduces new risks and
vulnerabilities
• 7. Interoperability: Networks all systems together and ensures interoperability of all data
• According to the estimates of several experts, the IoT will consist of around 30 billion objects
by 2020.
10

WHY OPEN SOURCE MAKES
SENSE FOR IOT
• According to the estimates of several experts, the IoT will consist of around 30 billion objects by 2020.
• Today, IoT promotes the adoption of different open source technologies, standards and protocols that
help devices communicate with one another. The following are the drivers that prompt organisations to
adopt open source technologies for IoT.
• 1. Cost: Adoption of open source IoT frameworks involves no costs at all, as these are free for use.
This encourages the community and organisations to implement IoT without any hesitation.
• 2. Innovation: Open source code from the community helps in building newer applications, leading to
more innovation and agility. The developers are able to build different products, which will be
interoperable across different OSs such as Android, Windows, iOS and Linux.
• 3. Open APIs: Use of open source APIs for the IoT framework offers a common gateway for different
software, hardware and the systems to communicate with one another.
• 4. Libraries: An open source IoT framework offers a wide range of libraries, SDKs and open source
hardware like Raspberry Pi and Arduino, ensuring that companies remain on the cutting-edge of
technology by using different open sourced tools to customise IoT platforms.
• 5. Security: Open source software can protect individuals’ data by implementing really strong
encryption for the use of the general public (SSH, SSL, PGP, etc), and hence supply the building blocks
for mobile security and the protection of data.
• 6. Interoperability: Adoption of open source solves the problem of interoperability.
11

• Open source IoT architecture
• There is a need for organisations to provide a validated, modular, flexible IoT architecture that
is built to be open, interoperable and cost effective. The architecture should deliver end-to-end
open source IoT that addresses enterprise level IoT needs.
The characteristics of open source IoT architecture are:
• Loosely coupled, modular and secure
• Platform independent
• Scalable, flexible and can be deployed anywhere
• Based on open standards
• Streaming analytics and machine learning
• Open and interoperable on the hybrid cloud
• Application agility and integration
• No vendor lock-in, since there are no rigid architectures or proprietary formats and
components
12

Following are some of the Architecture Design Principles related to IoT system design that I have come across in many years
of designing IoT systems. This list is only indicative and in no way definitive for any particular IoT solution or domain. Here you
go:
1. Standardized Integration
• Some enterprises mandate the use of an enterprise service bus for all communication between systems while others may
restrict
integration to using API only. Whichever integration mechanism is employed, such a mandate ensures external and enterprise
systems are integrated uniformly which enhances the maintainability of the overall IT inventory. Based on the enterprise
mandate, a
standard integration mechanism could be a guiding principle to follow while designing IoT solutions. It can considerably increase
the speed of on-boarding new systems thereby adding more value to an IoT ecosystem.
2. Platform Agnosticism
• While architecting IoT solutions based on AWS, Azure, GCP or any other cloud platform, the usage of PaaS services binds the
solutions to that vendor. Avoiding such a vendor lock-in may be part of the enterprise directive but it entails that the full capability of
the underlying platform is under utilized. A hybrid approach is sometimes followed where the business logic is at least made more
portable than the rest of the components. For instance, using Kubernetes based on serverless (Functions as a Service)
components instead of Azure Functions.
3. Data Residency and Compliance
• Data Residency is a requirement that is gaining prominence across all organizations implementing IoT or any other cloud based
solution. Set as a principle, it affects the choice of components or sometimes even the cloud provider itself, for implementing the
solution. Some cloud services are not available in all regions or countries and in some cases a service could be available in a
country but sub-processing of data by that service may happen outside the boundary of the country. Such strong mandates
affect the vendor selection, technical architecture and design choices quite significantly.
13

4. Using existing investments
• This is especially more frequent in case of Big Data Analytics and Data lake existing in an enterprise. Data Analytics and
Big Data technologies have existed even before IoT entered the mainstream. Though all IoT platforms are capable of
processing and storing big data and applying analytical models on this data, such capability already exists in
many enterprises. The idea behind this principle is to utilize existing investments on such functionality.
5. Prefer Edge Intelligence to Cloud Processing
• With most cloud platforms offering machine learning and serverless constructs on the edge, the acceptance of
edge as a
processing node is more than ever. The primary benefit being that this form of distributed computing reduces
processing
load in the cloud. Additionally, edge computing also reduces the network bandwidth consumption of sending every bit of
raw data to the backend.
6. Security by design
• Device and Data security is paramount in ensuring end to end security of an IoT system. Data security involves protecting data in
transit
and at rest. Device security usually involves device identity and authentication based on security certificates. With such a directive in
place, all IoT development happens defensively. And hence it influences the low level design of IoT functions.
7. Real time processing of Alarms/Alerts
• While the usual telemetry data from devices can take a path of ingestion, storage, processing, analytics and visualization, the device
alarms and alerts must take an emergency path to notify business apps or configured email/sms route for quicker action. This entails
14

8. Support multiple connectivity protocols
• High variability in devices and device types that connect to an IoT platform necessitates a protocol agnostic approach to
connectivity. An enterprise grade IoT platform is expected to ingest and process data riding on any transport and with
any data structure.
9. Support switch off mode
• This mode implies that the system works even if there is a loss in connectivity between devices and platforms. It may
result in reduced functionality but wouldn’t cause complete disruption of system availability. Such a feature is made
possible by services like Device Shadow which maintain the current and intended state of devices. Devices and
gateways are also designed so that they can sustain operations for a long time without being connected to the backend
platform.
10. No downtime
• It essentially means high availability of close to say 99.99% for an IoT solution. Many cloud services follow SLAs of
99.95% or less and therefore to reach the four 9s availability, the overall design of the platforms requires ingenious
design. Such highly fault tolerant systems must take care of disaster recovery by ensuring redundancy of each service
and all data across availability zones and regions.
15

IOT ARCHITECTURE REFERENCE MODEL
16

• An ARM consists of two main parts: a Reference model and a Reference Architecture.
• •A reference model describes the domain using a number of sub-models
17

• IoTivity is an open-source, reference implementation of the OCF Secure IP Device
Framework.
• The OCF Secure IP Device Framework provides a versatile communications layer with
best-in-class security for Device-to-Device (D2D) and Device-to-Cloud (D2C) connectivity
over IP. IoT interoperability is achieved through the use of consensus-derived, industry
standard data models spanning an array of usage verticals. The OCF Secure IP Device
Framework may be harnessed alongside other IoT technologies in a synergistic fashion to
lend a comprehensive and robust IoT solution.
41

• OS agnostic: The IoTivity device stack and modules work cross-platform (pure C code) and
execute in an event-driven style. The stack interacts with lower level OS/hardware
platform-specific functionality through a set of abstract interfaces. This decoupling of the
common OCF standards related functionality from platform adaptation code promotes ease
of long-term maintenance and evolution of the stack through successive releases of the
OCF specifications.
• Porting layer: The platform abstraction is a set of generically defined interfaces which elicit a
specific contract from implementations. The stack utilizes these interfaces to interact with the
underlying OS/platform. The simplicity and boundedness of these interface definitions allow
them to be rapidly implemented on any chosen OS/target. Such an implementation
constitutes a “port”.
• Optional support for static memory: On minimal environments lacking heap
allocation
functions, the stack may be configured to statically allocate all internal structures
by setting a
number of build-time parameters, which by consequence constrain the allowable workload
for an application.
• C and Java APIs: The API structure and naming closely aligns with OCF specification
43

Outlin
e• What is IoTivity and why is it
useful?
• IoTivity stack architecture
• IoTivity resource model and request-response
flow
• Role in the IoT ecosystem
• Cross-platform support

What is
IoTivity?
•Open source framework and
SDK for building IoT
applications
• Independently governed

Why is it
useful?
Turn Lights
Smartphone ON
Light bulbs with BLE radios
75F
75F
Smart TV
Digital
Thermostat
Regulate
Temperature
Table
Notify Current Setting

Why is it
u• Csroesfsu-pll?
atform support
• Uniform and easy-to-use APIs
• Based on open standards
• Support for multiple connectivity types
• Extensible to support proprietary protocols

IoTivity stack
architecture
Connectivity Abstraction
Secure Resource Manager
Resource Model
JNI Glue Layer (Java API)
Object Model (C++ API)
Base Functionality (C API)
Smart Home Health Enterprise
Industrial Automotive …..
Services Layer

OIC protocol & connectivity
t• yMpesesasging protocol
• Currently based on CoAP (RFC 7252)
• OIC payloads encoded using CBOR (RFC 7049)
• Adapter abstraction
• Handle multiple connectivity types
• Dual-stack IPv4 / IPv6
• Bluetooth Low Energy using GATT
• Bluetooth EDR using RFCOMM

OIC
Client
OIC
Server
OIC
Client
OIC
Intermediary
OIC
Server
Model 1 Model 2
IoTivity resource
m• RoESdTefull design -> Things modeled as
resources
• Server role: Exposes hosted resources
• Client role: Accesses resources on a server
•Intermediary role: Bridges messaging between client
and server

Resource
URI rt: Resource
Type
if: Resource
Interface
prop: Policy
n: Resource Name
…
…
Common
Properties
Resource
Specific
Identifies the type of resource
List of interfaces associated with the resource
Policy associated with resource: discoverable,
observable, secure, etc
Friendly name
Resource URI :/a/light1
rt: oic.ex.light
if: oic.if.rw
prop:
discoverable,
observable
n: myHallWayLight
State: 0 (OFF)
Dim Level: 0
Resource URI :/a/fan1
rt: oic.ex.fan
if: oic.if.rw
prop: discoverable
n: myKitchenFan
State: 1 (ON)
Speed: 10

“Well-Known”
resources
Functionality Fixed URI
Discovery /oic/res
Device /oic/d
Platform /oic/p
Presence /oic/ad
Security …
/oic/res
ic/d
/oic/ad
/oic/res
ic/d
/oic/ad
/oic/p
/o
OIC Device 1
/o
OIC Device 2
Examples of OIC devices are thermostats or AC
• Resources are associated with “Entity Handlers”
• Execute OIC methods on resources

Resource
c• Loinlkles
tcotoiothnersresources (RFC 5988)
• Express hierarchy, groups, indexes
Room
/a/room
Light
/a/light/1
Light
/a/light/2
Light
/a/light/3
Collection URI
rt: Resource Type
if: Resource
Interface
prop: Resource Properties
n: Resource Name
links: [Other resource
URI]

IoTivity request-response
flow
Application
Resource Model
CoAP over UDP
L2 Connectivity + IP
Application
Resource Model
CoAP over UDP
Server
Client
EH
URI: /a/light; rt = ‘oic.ex.light’,
if = ‘oic.ex.rw’,
prop = discoverable,
observable

Resource
sco
di
Application
Resource Model
CoAP over UDP
Application
Resource Model
CoAP over UDP
Server
192.168.1.1
Client
192.168.1.2
EH
IPv4 224.0.1.187: 5683
IPv6 FF0X::FD: 5683
veryMulticast GET coap://224.0.1.187:5683/oic/res
Unicast response
[URI: /a/light; rt = ‘oic.ex.light’, if = ‘oic.ex.rw’, prop =
discoverable, observable]

GET
pera
o
Application
Resource Model
CoAP over UDP
Application
Resource Model
CoAP over UDP
Server
192.168.1.1
Client
192.168.1.2
EH
tion Unicast GET coap://192.168.1.1:9000/a/light
Unicast response
[URI: /a/light; state = 0, dim = 0]

PUT
o tion
pera
Application
Resource Model
CoAP over UDP
Application
Resource Model
CoAP over UDP
Server
192.168.1.1
Client
192.168.1.2
EH
Unicast PUT coap://192.168.1.1:9000/a/light
PayLoad: [state=1;dim=50]
Unicast response
Status = Success

OBSERVE
pera
o
Application
Resource Model
CoAP over UDP
Application
Resource Model
CoAP over UDP
Server
192.168.1.1
Client
192.168.1.2
EH
tiUonicnast GET coap://192.168.1.1:9000/a/light;
ObserveFlag = 1
Unicast response
[URI: /a/light; state = 1, dim = 50]

OBSERVE
n ation
otific
Application
Resource Model
CoAP over UDP
Application
Resource Model
CoAP over UDP
Server
192.168.1.1
Client
192.168.1.2
EH
Notify Observers
[URI: /a/light; state = 0, dim = 0, sequence #: 1]

PRESENCE: “Active
d• Sisercveorsvcearnya”dvertise themselves to
clients
• Clients can request unicast or multicast notifications
• Server coming online
• Server going off-line
• Changes to resources
•Clients may indicate interest in specific resource
types

Notable IoTivity
f•eDiasctouvreerys
• Messaging and data model
• Message switching
• Remote access
• Services
• Protocol plug-ins
• Group management
• Security

Role in the IoT
service #2
domain
service #1
domain
Local Control Remote Control Server to Server
Healthcare
Industrial Smart
IoTivity
Framework
Connectivity
Controller
Controller
Cloud Servers Cloud Servers
Things
LE
IoTivity Base &
Services
Connectivity
Abstraction
eIoTivcityosyIosT
Atpeplimcation
Application
Vertical
Profiles

Cross-platform
s•
Luinpuxp(oUrbtuntu
12.04)
• Arduino: Due, ATMega
2560
• Android
• Tizen

Embedded support: Yocto
P• hrttop:j/e/wcwtw.yoctoproject.org/
• Hosted at the Linux Foundation
• Create customized OS images for embedded targets
• Ready-to-use BSPs for multiple platforms
• Supports major CPU architectures
• Layers and recipes

meta-oic software layer for
Y• goit:c//gtiot.yoctoproject.org/meta-
oic
• Resource and Service layer samples
IoTivity
Dependencies
• APIs
• Service layer
• Resource Model
• Base Framework
• Kernel Configuration
• Protocols
• Middleware

Constrained peripherals
• Storage and memory constraints
• Lightweight IoTivity server stack
• Base framework, resource model, messaging
• Work in progress…

unit3-241119090144-4cgfhfxxfh7d92930.pptx

More Related Content

Similar to unit3-241119090144-4cgfhfxxfh7d92930.pptx

More from ravirajghodake98

Recently uploaded

unit3-241119090144-4cgfhfxxfh7d92930.pptx