Internet of Things

Introduction contd- Lec 4

Dr.Ravikiran Y
Assistant Professor
EEE Department
BITS Pilani Hyderabad Campus
Outline

● Introduction to Design of IOT

2
Introduction to Design of IOT

● Physical Design :

>Communication design - Protocols used in IOT

>IOT Devices/Sensors - will be covered later

● Logical Design :
Abstract representation of entities and processes
without going into low-level specifics

3
 Background on Communication Models
• Request-Response:
• Client sends requests to server and the server responds.
• Server decides how to respond.
• Stateless (no record, each request is independent) communication
models.
• Each response-request pair is independent of other.

4
• Publish-Subscribe:
• Involves publishers, brokers and consumers.
• Publishers send data to the topics which are managed by the brokers.
• Publishers are not aware of the consumers.
• Consumers subscribe to the topics managed by the broker.
• Brokers receives data for a topic from the publisher and sends the data to
the subscribed consumers.

5
• Push-Pull:
• The data producers push the data to the queue and the consumers pull
the data from the queue.
• Producers do not need to be aware of the consumers.
• Queues help in decoupling the messaging between the producers and the
consumers.
• Queues also act as a buffer which helps in situations when there is a
mismatch in rate.

6
• Exclusive Pair:
• Bi-directional full duplex communication method.
• Uses persistent connection between server and a client.
• Once the connection is setup, it remains open unit the client sends a
request to close the connection.
• Stateful communication.

7
PHYSICAL DESIGN
Communication Design :IoT Protocols

IoT Protocols wrt Internet Protocol Suite (TCP/IP) 9

 IOT Protocols used in Internet Protocol Suite
(TCP/IP)
• Link Layer – Protocols determine how the data is physically sent over the
network’s physical layer or medium (e.g. copper wire, coaxial cable or a radio
wave).
• Scope is the local network connection to which the host is attached.
• Hosts on the same link can exchange data packets over the link layer
using link layer protocols.
• Determines how the packets are coded and signalled by the hardware
device.
• Protocols (details - read 1.2.2 from (R1) IOT Arshdeep Bahga, Vijay M)
• IEEE 802.3 Ethernet
• IEEE 802.11 WiFi
• IEEE 802.16 WiMax
• IEEE 802.15.4 LR-WPAN
• Mobile communication : 2G/3G/4G 10
• Network Layer – Responsible for sending IP datagrams from the source
network to the destination network.
• Performs host addressing and packet routing.
• The datagrams contain source and destination addresses which are
used to route them from the source to the destination across multiple
networks
• Hierarchical IP addressing scheme (IPv4 and IPv6)
• Protocols (details - read 1.2.2 from (R1) IOT Arshdeep Bahga, Vijay M)
• IPv4
• IPv6
• 6LoWPAN

11
• Transport Layer
• Provides end-to-end message transfer capability independent of the
underlying network.
• The message transfer capability can be set up on connections, either
using handshakes (TCP) or without handshakes (UDP)
• Error control, segmentation, flow control and congestion control.
• Protocols
• TCP
• UDP

12
TCP - Transmission Control Protocol < from wikipedia>
Widely used - browsers/ SMTP/FTP
TCP is connection-oriented, meaning that sender and receiver firstly need
to establish a connection based on agreed parameters; they do this
through three-way handshake procedure.

Three-way handshake, retransmission, and error detection adds to

reliability but lengthens latency.

TCP employs network congestion avoidance.

However, there are vulnerabilities in TCP, including denial of service,

connection hijacking, TCP veto, and reset attack. 13
UDP - User Datagram Protocol <from wikipedia>
Applications that do not require reliable data stream service may use
the UDP instead, which provides a connectionless datagram service
that prioritizes time over reliability.

Useful in time-sensitive applications.

Does not provide guaranteed delivery, ordering of messages,

duplicate elimination
• Application Layer
• Define how the applications interface with the lower layer protocols to
send data over the network,
• Application data is encoded by the application layer protocols and
encapsulated in the transport layer protocol
• Enable process-to-process communication using ports.
• Protocols
• HTTP
• CoAP
• WebSocket
• MQTT
• XMPP
• DDS
• AMQP 15
 Application Layer - IoT APIs

We will discuss 2 specific communication APIS

which are widely used in Application Layer in
IoT:
1) RESTful webservice
2) Websocket

16
 RESTful webservice

Is a “web API” implemented using HTTP & REST principles.

REST - Representational State Transfer is a software architecture that imposes

set of constraints on how an API should work. For more info - What is a REST API? -
YouTube

REST APIs follow request-response communication model

RESTful systems - 6 general constraints which define client-server

interactions and requests-responses.

To increase system performance, scalability, reliability, modifiability,

portability & visibility. 17
 REST - 6 guidelines
1.Statelessness:
Prevents the storage of any contextual information of the client on the server.
The session state is kept entirely on the client.
Each client request has to be self-sufficient in informing its responders about its
services and session state.

2.Uniform interface:
Method of communication client-server must be uniform.
“Resource” and a “Representations of Resource (URI)”.
When a client holds a URI it has all information to update/delete provided it has
required permissions.

3.Code on demand(optional):
Servers can provide executable code or scripts for clients to execute in their context18
 REST - 6 guidelines
4.Cacheability:
Data within a response can be labelled as:
> cacheable : can reduce interactions, as client can store data
>non-cacheable

5.Client-server architecture:
Separation of concerns
Client should not be concerned with storage of data ( concern of server)
Server should not be concerned with UI

6. Layered system:
Each component cannot see beyond the immediate layer
E.g client cannot tell if it is connected to the end server or inter-mediary node
19
20
 IoT APIs - WebSocket

Reduce network traffic & latency as there are no overheads for connection setup &
termination requests for each message
21
 Logical Design of IoT

Abstract representation of entities and processes without going into low-level specifics 22
IoT Levels and Deployment Templates

23
IoT Levels and Deployment Templates

24
 IoT Levels and Deployment Templates

E.g - home automation with 1 node controlling lights and appliances

Can be remotely accessed as well

25
 IoT Levels and Deployment Templates

E.g Smart Irrigation system - 1 single node monitors soil moisture and controls
irrigation
Cloud based app helps in visualization of moisture levels over a period of time. 26
 IoT Levels and Deployment Templates

E.g Ride service - Ola & Uber, The phone on the driver’s side will keep sending
location of driver to its cloud. The customer can see the live location of the
driver
27
 IoT Levels and Deployment Templates

E.g. Noise monitoring system in a specified area. Multiple nodes (with sound
sensors) are placed in different locations within the area.
-If a user (observer node) wants to know about noise levels in his area, he can
subscribe to this service 28
 IoT Levels and Deployment Templates

E.g. Forest fire detection - multiple nodes - measure temperature, humidity, CO2 levels in a
forest. -Coordinator node collects data from end nodes & has internet connectivity (acts as a
gateway). 29
-In the cloud - storage & analysis is done.
 IoT Levels and Deployment Templates

E.g. Advanced farm monitoring/control - multiple nodes - measure temperature, humidity, images in its vicinity (
each one is connected to cloud).
-In the cloud - storage & analysis is done.
-The centralised controller generates commands to individual nodes - to control water irrigation, pesticide system.
-Farmer can subscribe and get overall status
30
Design Methodology
 IoT Design Methodology

• Designing IoT systems can be a complex and challenging task as these

systems involve interactions between various components.

• A wide range of choices are available for each component.

• IoT designers often tend to design the system keeping specific products in
mind. But updating the system might get complicated

• IoT systems designed following a methodology will have

• Reduced design time
• Testing time
• Maintenance time
• Complexity
• Better interoperability 32
IoT Design Methodology

33
 IoT Design Methodology

• Smart IoT Based Home Automation System will be used as an

example for explaining the steps.

1. Purpose and Requirements Specification

⮚ Requirements can be:
• Data collection requirements
• Data analysis requirements
• System management requirements
• Security requirements
• User interface requirements

34
 IoT Design Methodology
A home automation system that allows controlling the lights remotely using a web
Purpose
application
Home automation system should support two modes: auto and manual
Auto: System measures the light level in the room and switches on the light when it is
Behavior
dark
Manual: Allows remotely switching lights on and off
System
System should provide remote monitoring and control functions
Management
Data Analysis System should perform local analysis of the data and determine if it is too dim

Application
Application should be deployed locally, but should be accessible remotely
Deployment

Security Should provide basic security like user authentication

35
 IoT Design Methodology -
2. Process Specification

Process Specification for home automation IoT System 36

 IoT Design Methodology -

3. Domain Model Specification

• The domain model describes the main concepts, entities and
objects in the domain of the IoT system to be designed.

• Domain model defines the attributes of the objects and

relationships between objects. The domain model is
independent of any specific technology or platform.

• Using domain model, system designers can get an

understanding of the IoT domain for which the system is to be
designed.
8/24/2023 37
 IoT Design Methodology -

• The physical identifiable objects in the environment

• IoT system provides information about the physical entity (using
Physical Entity
sensors) or performs actuation upon the physical entity
e.g. the room to be monitored and the light appliance to be controlled.

• Virtual entity is a representation of the physical entity in the digital world

Virtual Entity • For every physical entity there is a virtual entity
e.g. virtual entities for room, light appliance.
• Devices provide a medium for interaction between physical and virtual
entities
• Devices are used to gather information (sensors) OR perform actuation
Device
on physical entities OR used to identify physical entities(tags)
e.g. a single-board mini computer which has light sensor and actuator
(relay switch) attached to it.
38
 IoT Design Methodology -
• Resources are software components which can be either on-device or network-
resources
• On-device resources are hosted on the device and provide sensing or actuation
(eg: operating system)
Resource • Network-resources include software components that are available on the
network (eg: database)
e.g. OS that runs on the single board mini computer.

• Services provide an interface for interacting with the physical entity

• Services access resources to perform operations on physical entities/access
resource
e.g. a service that sets mode to auto or manual;
Service
- a service that sets the appliance state to on/off or
retrieves the current state;
- a controller service that runs as a native service in the computer according to
the mode - 1 service per mode.

39
 IoT Design Methodology -

4. Information Model Specification

• Information model defines the structure of all the information in
the IoT system.

• Does not describe how the information is stored and

represented.

• To define the information model, we first list the virtual entities.

Later more details like attributes and relationships are added.

41
 IoT Design Methodology -

Information Model for home automation IoT System

42
 IoT Design Methodology -

5. Service Specifications
• The service specification defines the following:
• Services in the system
• Service types
• Service inputs/output
• Service endpoints
• Service schedules
• Service preconditions
• Service effects

• For each state and attribute in the process specification and information
model, we define a service. Services either change the state of
attributes or retrieve their current values.
43
 IoT Design Methodology -

Controller Service of the home automation IoT System

45
 IoT Design Methodology -

Service specification of the home automation IoT System – mode service

46
 IoT Design Methodology -

Service specification of the home automation IoT System – state service

47
 IoT Design Methodology -

6. IoT Level Specifications

• Based on the requirements
we will choose the IoT
application deployment
level.

• The deployment level for

home automation system is
level 1.

48
 IoT Design Methodology -

7. Functional View Specifications

• The functional view defines the functions of the IoT systems grouped
into various functional groups.

• Each functional group provides functionalities for interacting with

concepts in the domain model and information related to the concepts.

• The functional groups in a functional view include: Device,

Communication, Services, Management, Security, and Application.

49
 IoT Design Methodology -

Mapping deployment level to functional groups for home automation IoT System

50
 IoT Design Methodology -

9. Device and Component Integration

• In this step the devices like sensors, computing devices and other
components are integrated together.

51
 IoT Design Methodology -

Schematic diagram for the home automation IoT System showing the device,
sensor and actuator integrated 52
 IoT Design Methodology -

10. Application Deployment

• Using all the information from previous steps, the application (code) for
the IoT system is developed

Home automation web application

53