Understanding Logical Design of IoT! Discover IoT Functional Blocks, IoT Communication Models, IoT Communication APIs and Much More...

Abstract:

The logical design of an Internet of Things (IoT) system entails the creation of an abstract representation of entities and processes, steering clear detailed implementation specifications. It relies on the utilization of Functional Blocks, Communication Models, and Communication APIs to effectively establish a functioning system. We discuss Logical design of Internet of things. Logical design of IoT system refers to an abstract representation of the entities & processes without going into the low-level specifies of the implementation. 

For understanding Logical Design of IoT, we describes given below terms.

IoT Functional Blocks

IoT Communication Models

IoT Communication APIs

1 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.

The 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.

Fig 1 : Functional blocks of IoT system

2 IoT Communication Models

2.1 Request-Response Model

Request-response model is communication model in which the client sends requests to the server and the server responds to the requests. When the server receives a request, it decides how to respond, fetches the data, retrieves resource representation, prepares the response, and then sends the response to the client. Request-response is a stateless communication model and each request-response pair is independent of others.

HTTP works as a request-response protocol between a client and server. A web browser may be the client, and an application on a computer that hosts a web site may be the server. Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.

Fig 2 Request-response communication model 

2.2 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 are managed by the broker. Publishers are not aware of the consumers. Consumers subscribe to the topics which are managed by the broker. When the broker receive data for a topic from the publisher, it sends the data to all the subscribed consumers.

3 Publish-Subscribe communication model

8.2.3 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.

Fig 4 Push-Pull communication model

2.4 Exclusive Pair Model

Exclusive Pair is a bidirectional, fully duplex communication model that uses a persistent connection between the client and server. Connection is setup 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 stateful communication model and the server is aware of all the open connections.

Fig 5: Exclusive Pair communication model

3 IoT Communication APIs

Generally we used Two APIs For IoT Communication. These IoT Communication APIs are:

REST-based Communication APIs

WebSocket-based Communication APIs

3.1 REST-based Communication APIs

Representational state transfer (REST) is a set of architectural principles by which you can design Web services the Web APIs that focus on systems’s resources and how resource states are addressed and transferred. REST APIs that follow the request response communication model, the rest architectural constraint apply to the components, connector and data elements, within a distributed hypermedia system. The rest architectural constraint are as follows:

Client-server – The principle behind the client-server constraint is the separation of concerns. 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.

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 requires 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.

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 intermediaryalong 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.

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.

A RESTful web service is a ” Web API ” implemented using HTTP and REST principles. REST is most popular IoT Communication APIs.

Uniform Resource Identifier (URI)

GET

PUT

PATCH

POST

DELETE

Collection, such as https://api.example.com/resources/

List the URIs and perhaps other details of the collection’s members.

Replace the entire collection with another collection.

Not generally used

Create a new entry in the collection. The new entry’s URI is assigned automatically and is usually returned by the operation.

Delete the entire collection.

Element, such as https://api.example.com/resources/item5

Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.

Replace the addressed member of the collection, or if it does not exist, create it.

Update the addressed member of the collection.

Not generally used. Treat the addressed member as a collection in its own right and create a new entry within it.

Delete the addressed member of the collection.

3.2 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 coonection to be setup for each message to be sent. Websocket communication begins with a connection setup request sent by the client to the server. The request (called websocket handshake) is sent over HTTP and the server interprets it is an upgrade request. If the server supports websocket protocol, the server responds to the websocket handshake response. After the connection setup client and server can send data/mesages to each other in full duplex mode. Websocket API reduce the network traffic and letency as there is no overhead for connection setup and termination requests for each message. Websocket suitable for IoT applications that have low latency or high throughput requirements. So Web socket is most suitable IoT Communication APIs for IoT System.

Conclusion: 

The logical design of an Internet of Things (IoT) system entails the creation of an abstract representation of entities and processes, steering clear detailed implementation specifications. The logical design of an Internet of Things (IoT) system involves the use of functional blocks, communication models, and communication APIs. The functional blocks, including application, management, services, communication, security, and device components, collectively contribute to the operation of the IoT system. Communication models such as the request−response model, publish−subscribe model, push−pull model, and exclusive pair model enable effective communication between entities within the system. REST−based communication APIs follow the principles of Representational State Transfer, providing a standardized and uniform interface, while WebSocket−based communication APIs facilitate full−duplex communication for ongoing interactions. Understanding these components is crucial for building efficient and secure IoT systems.

References 

Internet of Things for Architects

Learning Internet of Things

IoT edge solutions for cognitive buildings

The Fourth Industrial Revolution

Trillions

IoT capstone project

The Silent Intelligence: The Internet of Things