Logical Design of IoT

The logical design of internet of things includes: IoT Functional Blocks, IoT Communication Models, and IoT Communication APIs. In this article we will learn about them in detail.

 

Watch the below video to learn about logical design of internet of things:

 

Logical Design of IoT: IoT Functional Blocks

Different functional blocks in an IoT system or application are device, communication, services, application, management, and security. They can be illustrated as shown below.

 

 

The device block contains sensing, actuation, monitoring and control functions for controlling the devices. The device block interacts with the communication block.

 

The communication block contains different protocols (wired or wireless) through which the data moves from devices to Internet and from Internet to devices. The services block acts as a middleware which can provide services like device identification, device discovery, or data processing and analysis.

 

The users of an IoT application interacts with the application block. It provides user interface with which the user can access the data sent by the sensors, perform operations on that like aggregation, simplification, etc. and visualize that data.

 

The application interface can also provide control functions for controlling the sensors, actuators or functionality of the application. The management block allows us to manage the other blocks like device, services, communication, application, and security. The security block provides different security services like confidentiality, integrity, availability, and authentication.

 

Logical Design of IoT: IoT Communication Models

Internet of things supports different communication models between the entities in an IoT system. These communication models are:

• Request-Response Model
• Publish-Subscribe Model
• Push-Pull Model
• Exclusive Pair Model

 

Request-Response Model

The request-response model can be illustrated as shown below:

 

 

The two main entities in request-response model are client and server. The client can be a web application, mobile application, etc. The client may be a browser requesting web pages or accessing an email. Each access of a resource will be treated as request.

 

The server accepts the requests from the clients, processes them and sends back responses to the clients. While processing the requests, the server might access additional resources like file, databases, etc. The request-response model is stateless, i.e., the requests in a session are not related to each other with respect to a server. Each request is treated as a new one and is completely unrelated to the previous requests.

 

Publish-Subscribe Model

The publish-subscribe model can be illustrated as shown below:

 

 

The three main entities in publish-subscribe model are publisher, consumer, and broker. The publisher always publishes messages at a pre-defined interval. The sensors in IoT can be thought of as publishers. The publishers publish data as topics. The broker is an entity that maintains different topics to which consumers subscribe. The broker is generally a server.

 

The published messages of publishers are maintained by the broker. The consumers consume the data published by the publishers. A consumer is generally the IoT application through which the users interact. A consumer can subscribe to one or more topics maintained by a broker.

 

Push-Pull Model

The push-pull model can be illustrated as shown below:

 

 

The main entities in a push-pull model are publisher, consumer, and queues. The publisher pushes messages to the queues. The sensors in IoT can be thought of as publishers of data. One or more queues store that data pushed by the publishers.

 

Unlike the publish-subscribe model, there is ordering of messages in push-pull model. The consumers pull the messages from the queues and consume the messages. A consumer is generally the IoT application through which the users interact.

 

Exclusive Pair Model

The exclusive pair model can be illustrated as shown below:

 

 

The main entities in an exclusive pair model are client and server. The client and server establish a full duplex connection for sending and receiving data. Before sending a request, the client establishes a connection with the server and then sends the request.

 

The data requests can be one or more. The server receives these requests through the same connection and sends back responses. After the data transfer is complete, the connection between the client and server is terminated. Unlike publish-subscribe model, exclusive pair model is stateful. So, the server can automatically identify that the request is coming from a previous client or not.

 

Logical Design of IoT: IoT Communication APIs

An Application Programming Interface (API) provides an unified interface to access the server resources. An API is the one which connects the things together in the Internet of Things. APIs act as a point of interaction between the IoT devices and the Internet and/or other elements within the network.

 

In IoT there two types of communication APIs. They are:

• 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 and web APIs that focus on a system’s resources and how resource states are addressed and transferred. REST APIs follow request-response model. REST architectural constraints apply to components, connectors, and data elements within a system.

 

Consider the example of accuweather.com as shown below. Users can see the weather at a given location though accuweather’s weather application in their mobiles. This application uses a REST API provided by accuweather to access the weather details. When a user selects a location in the mobile app, the application sends a HTTP or HTTPS request as shown in the figure below. Accuweather’s server responds back with the weather details.

 

 

In a REST-based communication, the client sends HTTP or HTTPS requests like GET, POST, PUT, DELETE, etc., to the server where the REST-based API will accept these requests, process them and send back responses. The responses sent back to the clients will be in Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format as shown below.

 

 

A RESTful web service is a web API implemented using HyperText Transfer Protocol (HTTP) and REST principles. RESTful web service is a collection of resources which are represented by URIs. Clients send requests to these URIs using HTTP or HTTPS methods like GET, POST, PUT, DELETE. REST architectural constraints are:

• Client-Server: As REST is based on request-response model, the communication involves two entities namely, client and server. A client sends requests and the server process the requests and sends back responses.
• Stateless: As REST follows request-response model, it is stateless. The server will not be able to associate a set of requests to a client. It will treat each request as a new request.
• Cacheable: The response sent by the server might be cached at the client side. This will allow the client to load the response faster next time when it is needed.
• Layered System: The REST architecture is layered where there is a clear separation in the functionality carried by different entities.
• Uniform Interface: REST provides an uniform interface for all kinds of applications and devices.
• Code on Demand: REST enables to access the code based on a specific request. Based on the request, the code that is going to be executed might be changed.

 

The REST-based communication can be summarized and illustrated as shown below.

 

 

WebSocket-based Communication APIs

WebSocket-based API creates full-duplex communication between clients and servers. It follows exclusive Web pair communication model. WebSocket-based communication is stateful.

 

No need to establish connection for each request. It is suitable for IoT applications that need low latency. WebSocket-based communication process can be illustrated as shown below.