EXPERT KNOWLEDGE AT A GLANCE

Category: communication protocol

Kafka alternative – RabbitMQ

Overview

== Open Source Message Broker Software (a service that handles the distribution of messages)
– released in 2013
– implements Advanced Message Queuing Protocol (AMQP)
– meanwhile also STOMP and MQTT

Advanced Message Queuing Protocol (AMQP)

== binary network protocol
– independent of any programming language (sender and receiver do not have to understand the same programming language)

AMQP

Principle

– There is a queue between the producer and the consumer of a message. The messages are temporarily stored in this queue
– Messages == can be instructions to other programs or actual text messages
– The producer of the message does not have to take care of sending the message himself and does not have to wait until the recipient has received it
→ asynchronous procedure

Stations in the message transmission

Producer: creates news
Exchange: part of RabbitMQ, forwards messages
Queue: part of RabbitMQ, stores messages
Consumer: processes the message

Message transmission process

– Producer publishes a message; gives the message a routing key (==address)
→ passes it to the Exchange
→ distributes the messages to different queues using the routing key

Binding

– There is a so-called binding between Exchange and Queue
– this connects each individual queue to the Exchange
– defines, according to which criteria a message should be forwarded

Direct Exchange

== direct connection between transmitter and receiver
– one queue + one consumer

Topic Exchange

– addressing multiple queues

Fanout Exchange

== Broadcast (distribution of a message to all available queues, without sorting)

Header Exchange

– corresponds to the Topic Exchange
– but browsing is done via header attributes

Modbus Overview

Modbus Overview – In this article we introduce you to the industrial communication protocol, its function and its individual characteristics.

What is Modbus and how does it work?


Modbus is due to its simple usability in many automation areas a standard to couple intelligent machines in a client/server architecture, also called master/slave.
Each bus participant is assigned a unique address. Zero is always the broadcaster. Usually the master initiates a message and an addressed slave responds. This means that the message is always sent from one point to all participants.

Data can be exchanged either via a serial interface and thus in single bits (RTU, ASCII) one after the other, or via Ethernet using data frames (TCP). Depending on the data format the bus types are also distinguished

Modbus Overview – RTU-Modbus

The Remote Terminal Unit (RTU) is best described as a remote control system. Transmission is in binary form and is therefore very fast. However, to be able to read the data, it must be translated back again.


The length of the transmission pause depends on the transmission speed.
The data field contains information which registers the slave is to read. The slave then inserts the read data here and sends it to the master. In the master then an error check takes place via cyclic redundancy check, either via a CRC or by the calculation of a checksum byte.

Modbus Overview – ASCII-Modbus

Instead of a binary sequence, an ASCII code, i.e. a 7-bit character encoding, can also be transmitted. This can be read immediately, but has a lower data throughput in direct comparison to RTU.


Error checking is done by longitudinal parity checking via a line replaceable unit. The error case is usually triggered at a frame transmission pause of more than one second. However, this period is configurable.

Modbus Overview – Modbus/TCP

Data transmission can also take place via transmission Control Protocol/ Internet Protocol (TCP/IP) packets. Here, identification takes place via IP addresses.

The transmission security is ensured by a digital certificate authentication of server and client, a so-called Transport Layer Security (TLS).

Modbus Overview – Client/Server Model

What does the client/server model look like?

The following figure shows the individual steps of both bus participants.

Modbus Overview - The figure shows the individual steps of both bus participants.
Modbus Overview – Client Server Model

A client sends a request to the network to initiate a transaction.
This request is then received on the server side. The so-called indication.
The server then processes the request and creates a response, and returns it to the network.
The client side then receives the response. This step is called confirmation.

General MODBUS frame

Modbus Overview - This diagram shows a Modbus frame with its components. ADU and PDU.
Modbus Overview – Modbus Frame – PDU, ADU
  • MODBUS protocol defines a Protocol Data Unit (PDU, full message from an OSI shift)

  • Mapping of protocol on specific buses or networks can introduce additional fields on the Application Data Unit (ADU, combined command/data block)

MODBUS on TCP/IP Application Data Unit

  • Dedicated header is used to identify the Data Unit (MBAP header) -> contains fields for several information codes

Modbus Overview - This diagram shows a Modbus TCP/IP ADU, PDU
Modbus Overview – TCP/IP ADU, PDU

MODBUS vs OPC UA

OPC UA may become one of the most important unified data protocols. For years, umbrella organizations have been driving the project worldwide. Originally developed for the injection molding and rubber processing industries, OPC UA is gradually being extended to other industries. Thanks to its standardized tree structure, OPC can represent data very flexibly as hierarchical objects. This means that a lot of relationship and structure information is also transmitted.


How can OPC UA devices now be interconnected via Modbus?
The first problem is hardware based. OPC UA is usually transmitted via Ethernet. Modbus mostly via RS485. Here a first conversion is necessary.
The second issue deals with how to represent the registers and coils of the Modbus device in OPC UA.

OPC UA Native Representation

The first option is to remap the entire Modbus data space to objects. Each register and coil are thus represented as a variable attribute and are given descriptive names. Subsequently, metadata can be added. For example the data type, a maximum value or time of origin.

Modbus Native Representation

Instead of building an OPC UA address space, individual objects can be represented with Modbus registers and coils as attributes. Each register and coil can be mapped by the current register and coil number and no metadata is added.
A client can then access the new data space using UA Read and UA Write requests.

Modbus Data Transport

How can Modbus use OPC UA for data transport?
The actual Modbus message packet is sent over the network, embedded in the OPC UA transport. OPC UA wraps the standard message and adds a standard encoding and security layer.

However, this requires that the OPC UA Server recognizes that the content of a message is not a standard read or write of OPC UA attributes, but is a Modbus message. An OPC UA Server must therefore be attached to the rontend of the device. This can be done in different ways

1.

The OPC UA Server function acts as a mechanism to establish a secure and reliable connection between a Modbus client and a Modbus server. A string attribute is exposed which then contains the entire Modbus message.
For a Modbus RTU client device, an OPC UA client device can be used to write the send attribute to the target device. The receive attribute is read back.
However, nothing really changes for the Modbus devices except that the messages are passed to OPC UA instead of being put on a line.

2.

Another possibility is to create a data provider/manager for processing the Modbus message.
A message is processed through the low-level transport and the application services look at the attribute. The application service manager would notice that the namespace index points to a dedicated application process.

Where else does Modbus make sense?

Modbus is still the best solution for certain applications. It is a relatively inexpensive way to build a reliable information flow. It is a “slow response network” which is especially advantageous for temperature recording. For complex data sets, however, there are far better solutions with EtherNet/IP, PROFINET IO and EtherCAT. OPC UA, for example, can be transferred here without major transformations and detours.

Increasingly large volumes of data can now be processed faster and faster thanks to ever more efficient hardware performance. Large information networks for monitoring and analyzing almost all business processes are becoming more and more standard. uniform, fast and resource-saving data protocols are the key to Industry 4.0. If you want to know more about Industry 4.0, take a look at our article here.