Skip to content

Communications protocols

The information provided below is intended to be complementary to the project script and is not required reading.

Motivation

A communications protocol consists of rules to which the sender of a message and its receiver must comply in order to communicate. In practice, in each layer of the OSI model level, specific rules are established (which may refer to aspects such as information packaging, the format of the data frame, its length or how error control is managed) and A protocol is defined for each layer.

The following figure shows a communications scheme between two devices (Host A and Host B) and the correspondence of protocols for each layer. The notations to the right (APDU, PPDU, SPDU, etc.) indicate what name the communication units in each layer receive.

In any application in which a communication flow between equipment and applications is necessary, one or more communication protocols are used. It is necessary to know the most important characteristics of these protocols to identify the parameters that must be provided to them (IP addresses, memory map addresses, read/write codes).

In the second part of the project, which consists of implementing the CPS architecture, you will work directly with the Modbus protocol when reading data from a PLC. On the other hand, you will notice that some of the software that is going to be used accepts encrypted requests according to the HTTP protocol.

Next, we present some communication protocols of the application layer that are used in the field of industrial automation:

  • Modbus.
  • Hypertext Trasnfer Protocol o HTTP.
  • Message Queuing Telemetry Transport o MQTT.

As an example, in an application over the protocols TCP for the transport layer, IP for the network layer, and Ethernet for the network interface layer, the layers are distributed as follows:

Modbus

Modbus is an industrial communications protocol, created by MODICON in 1979 and open, developed to make possible the transmission of information between its PLCs. Modbus is an application protocol, which means that it can be implemented on different physical layers (with their respective protocols). There are versions of the protocol for serial port and Ethernet (Modbus TCP/IP), and other protocols that are derived from TCP/IP. In industrial automation, the use of the Modbus TCP/IP model is very common.

Modbus networks use a master-slave (or client-server) architecture. The master initiates communications (e.g. a SCADA) through a function code that requests data from a slave (e.g. a PLC), which returns a response based on the code it has received. The port reserved for the Modbus protocol is port 502.

Modbus data model

Modbus originally supports two data types: a Boolean value and a 16-bit unsigned integer. In many cases sensors and other devices generate data in different types (e.g. floating point values). It is common for slave devices to convert these larger data types to registers. As an example, a pressure sensor can divide a 32-bit floating point value between two 16-bit registers.

In SCADA systems, it is common for embedded devices to have certain values defined as inputs (e.g. gains or PID parameters), while other values are outputs (e.g. the position of a valve). Modbus data values are divided into four ranges:

Memory block Type of data Teacher acces Slave acces
Coils Boolean Reading/Writing Reading/Writing
Discrete inputs Boolean Only reading Reading/Writing
Holding register 16-bits unsigned word Reading/Writing Reading/Writing
Input register 16-bits unsigned word Only reading Reading/Writing

Modbus function codes

Function codes determine how the master accesses and modifies data. When a slave is asked to perform a function code, it uses the function parameters it has received from the master to perform specific actions.

The most common function codes are named after the range of data they modify or access. Here are some examples:

Code Function
Decimal Hexadecimal
02 0x02
06 0x06
16 0x10

The following link leads to the official website of the developers of the Modbus protocol:

https://modbus.org/

In the following link you can find the technical specifications of the Modbus protocol, which offer detailed information about:

  • The data format recognized by Modbus.
  • The addresses used by Modbus.
  • The function code categories.
  • The descriptions of each function code.
  • The exceptions generated by Modbus.

https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

Node-RED Compatibility

Within the Node-RED palette you can find several libraries that allow you to send and receive communications in Modbus format. The library used in the project that you will develop is the following:

https://flows.nodered.org/node/node-red-contrib-modbus

HTTP

The characteristic that defines the HTTP protocol is its ability to transmit information in hypertext format, which allows other resources such as videos, graphics, audio, etc. to be included in the encoded information. The links that can form part of a message in hypertext format They are called hyperlinks.

As is the case with Modbus, HTTP is based on a client-server architecture. The client issues HTTP requests and the server returns an HTTP response with a response code, which may be accompanied by additional information if the request requires it. As an example, a web browser can act as a client and an application running on a server that hosts a web page can act as a server.

The format of HTTP requests and responses is very similar and is predefined. Knowing the type of requests that a server expects to receive and the responses it generates allows, from the point of view of a client:

  • Generate requests that conform to the request format that the server you want to work with can receive.
  • Adapt the client application so that it is capable of receiving the HTTP responses that the server will return.

HTTP requests and responses are encoded as a string in ASCII format, which allows the data to be sent as a frame encoded in hexadecimal format. Next, you can see an example of an HTTP response and its equivalence as a hexadecimal data frame:

At Atenea you can access two videos that we have generated specifically to present the HTTP protocol:

  • The video Video1_HTTP.mp4 covers the most important features of the HTTP protocol, as well as the formats of HTTP requests and responses.
  • The video Video2_HTTP.mp4 presents practical examples of communications through the HTTP protocol implemented on the Node-RED tool. In this second video, the concepts presented in the first video are considered known.

MQTT

MQTT is a protocol that is based on publish-subscribe relationships and, thanks to this, it greatly eases communications between devices, since information is only sent when specific events occur and therefore the necessary resources in terms of bandwidth are much lower. This information is encapsulated in the form of objects called messages. The publish-subsrcribe relationships are defined when a hierarchical tree of topics is defined, in which some devices (referred to as nodes) can subscribe or publish. On the other hand, all communications are managed by a central node (referred to as a broker).

This operating mode allows you to isolate the applications that publish in a topic from those that are subscribed to it. Some implications of this are as follows:

  • Applications do not need to share any parameters with each other or be aware of each other's existence.
  • The apps do not need to be in sync.
  • It is not necessary for the applications to be connected at the same time. It is possible for an application to publish a message, in a specific topic, with a parameter that tells the central node to retain it, so that subscribed applications receive it when they are connected.

All of this greatly facilitates the scalability of the system since the topics hierarchy can be modified at any time and new publisher/subscriber nodes can be declared.

The following link leads to the official website of the developers of the MQTT protocol, where you can find all the technical information:

https://mqtt.org/

Specifically, in the following link you can find the technical specifications of the protocol:

https://mqtt.org/mqtt-specification/

  • At Atenea you can access two videos that we have generated specifically to present the MQTT protocol:
  • The video Video1_MQTT.mp4 introduces the MQTT protocol and develops a very simple theoretical example with the aim of giving context to the most important theoretical concepts: nodes, topics, etc.
  • The video Video2_MQTT.mp4 implements the theoretical example presented in the first video on the Node-RED tool.