Scribd
Upload
35 views22 pages

IOT Logical and Physical Design

adjsajkjhd

Uploaded by

Virat D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
35 views22 pages

IOT Logical and Physical Design

adjsajkjhd

Uploaded by

Virat D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

IOT Logical and Physical

Design
Logical Design Of IOT
• The logical design focuses on the high-level structure and
functionality of the system's components
• Focuses on how the system's components, like sensors and
computers, should be arranged to perform specific functions.
• It's more conceptual and abstract than the physical design, and
doesn't go into the details of how each component is built
• Logical design of IoT system refers to an abstract representation of
the entities & processes without going into the low-level specifics of
the implementation.
Logical Design Of IOT
Logical Design Of IOT
• The logical design of IoT is composed of:
• 1. IoT functional blocks
• 2. IoT communications models
• 3. IoT communication APIs
IoT Functional Blocks
• An IoT system comprises of a number of functional blocks
that provide the system the capabilities for identification,
sensing, actuation, communication and management.
• functional blocks are:
• Device: An IoT system comprises of devices that provide
sensing, actuation, monitoring and control functions.
• Communication: Handles the communication for the IoT
system.
• Services: services for device monitoring, device control service,
data publishing services and services for device discovery.
• Management: this blocks provides various functions to govern the
IoT system.
• Security: this block secures the IoT system and by providing
functions such as authentication , authorization, message and
content integrity, and data security.
• Application: This is an interface that the users can use to control
and monitor various aspects of the IoT system. Application also
allow users to view the system status and view or analyze the
processed data.
IoT Communication Models
• Request-Response Model
IoT Communication Models
• Publish-Subscribe Model
Publish-Subscribe Model
• Publish-Subscribe is a communication model that involves
publishers, brokers and consumers.
• Publishers are the source of data.
• Publishers send the data to the topics which the broker
manages.
• Publishers are not aware of the consumers.
• Consumers subscribe to the topics which the broker
manages.
• When the broker receives data for a topic from the
publisher, it sends the data to all the subscribed consumers.
Push-Pull Model
• Push-Pull is a communication model in which the data
producers push the data to queues and the consumers Pull
the data from the Queues.
• Producers do not need to be aware of the consumers.
• Queues help in decoupling the messaging between the
Producers and Consumers.
• Queues also act as a buffer which helps in situations when
there is a mismatch between the rate at which the producers
push data and the rate rate at which the consumer pull data.
Push-Pull Model
Exclusive Pair Model
• Exclusive Pair is a bidirectional, fully duplex communication
model that uses a persistent connection between the client
and server.
• Connection is set up it remains open until the client sends a
request to close the connection.
• Client and server can send messages to each other after
connection setup.
• Exclusive pair is a stateful communication model and the
server is aware of all the open connections.
Exclusive Pair Model
IoT Communication APIs
• REST-based Communication APIs

• WebSocket-based Communication APIs


REST-based Communication APIs

• Representational state transfer (REST) is a set of architectural


principles by which we can design Web services that focus on
systems’ resources and how resource states are addressed
and transferred.
Architectural Constraints of REST
• Client-Server: This constraint dictates that a client and a
server need to be independent of one another so that either
can be modified without impacting the other.
• For example clients should not be concerned with the
storage of data which is concern of the serve. Similarly the
server should not be concerned about the user interface,
which is concern of the clien. Separation allows client and
server to be independently developed and updated.
Architectural Constraints of REST
• Stateless – Each request from client to server must contain all
the information necessary to understand the request, and cannot
take advantage of any stored context on the server. The session
state is kept entirely on the client.

• Cache-able – Cache constraints require that the data within a


response to a request be implicitly or explicitly leveled as cache-
able or non cache-able. If a response is cache-able, then a client
cache is given the right to reuse that repsonse data for later,
equivalent requests. caching can partially or completely eliminate
some instructions and improve efficiency and scalability.
Architectural Constraints of REST
• Layered system – layered system constraints, constrains the
behavior of components such that each component cannot
see beyond the immediate layer with they are interacting.
• For example, the client cannot tell whether it is connected
directly to the end server or two an intermediary along the
way.
• System scalability can be improved by allowing
intermediaries to respond to requests instead of the end
server, without the client having to do anything different.
Architectural Constraints of REST
• Uniform interface – Uniform interface constraints requires
that the method of communication between client and
server must be uniform. Resources are identified in the
requests (by URIsin web based systems) and are themselves
is separate from the representations of the resources data
returned to the client. When a client holds a representation
of resources it has all the information required to update or
delete the resource you (provided the client has required
permissions). Each message includes enough information to
describe how to process the message.
• Code on demand – Servers can provide executable code or
scripts for clients to execute in their context. this constraint
is the only one that is optional.
WebSocket based communication API
• Websocket APIs allow bi-directional, full duplex
communication between clients and servers.
• Websocket APIs follow the exclusive pair communication
model.
• Unlike request-response model such as REST, the WebSocket
APIs allow full duplex communication and do not
require new connection to be set up for each message to be
sent.
WebSocket based communication API

You might also like