Message Bus Communication Between Controllers

Today we will take a look at a use case for communication between Automation Controllers.

Topics#

1. Overview
2. Use Case Overview
3. Use Case Implementation
4. Bonus

CAUTION: Just because you can, doesn’t mean you should. Using the Message Bus as broadcaster between controllers can be very useful and powerful, but in a sense it’s an anti-pattern. It bleeds over functionality between Controllers and bypasses the MES. Also, if not correctly setup it may be broadcasting payloads to a large number of active subscribers. The bigger the payload and the bigger the number of subscribers, the bigger the impact on the traffic in the network. You should always, only send exactly what you need and be as Peer to Peer as possible. Also, this is not transaction, this is an asynchronous method of communication. Even though we can send messages and wait for a reply.

Overview#

Connect IoT supports multiple architectures to best adapt to the integration scenario. When a machine has multiple interfaces, typically we can have one controller that orchestrates multiple drivers. The MES typically holds and persists the key process information and orchestrates and enriches the Connect IoT as needed, this way being able to save history, provide analytics and being more transparent to the end user.

Nevertheless, there are scenarios, where communication between controllers is needed, in a close to synchronous fashion. Where the push of information for a particular controller is not the machine nor the MES but the other controller. Critical Manufacturing provides a tool for just this type of broadcasts, the Message Bus. This tool enables us to subscribe to topics and to broadcast messages. This scenario is also very helpful for interactions between the GUI or in pipelining DEEs for the Connect IoT.

This tutorial will focus only in a very simple example in MQTT. Other scenarios may be addressed in future posts.

Use Case Overview#

The use case for demonstrating this type of interaction, will be two lines. Where one controller is focusing on controlling one particular line. The Line 1 Controller will receive a PartsFinished and will then forward that information to the Line 2 Controller, which will iterate and set the value for the property partsToBeProduced. It will also perform a Line Clear that will clear the counter on Line 2.

This is a very simple interaction, but you can imagine the case, where you want segregation between two lines, and which are functionally different, but according to some logic you want the following line to be informed immediately on what hast been produced and is now to to be produced on the next line. Some parts of this, of course may make sense to represent in the MES and to not only broadcast a message but also, to persist in the MES this information.

Use Case Implementation#

For this implementation we will use an MQTT broker Mosquitto.

First, let’s create the Automation Protocol, just keep the default values:

Now we need to create two different Automation Driver Definitions. For Line 1 we will have two events, one for the PartFinished and in Line 2 we will set a property value.

For Line 2, let’s define the property that we want to set:

Line 1 Configuration#

Now we need to create two Automation Controllers, starting on the Line 1. Leave the Setup as default and create a new page Part Finished. For Part Finished we will receive an Event and broadcast a message to our new topic Cmf.Line.PartsFinished.

To try and make our solution a bit more generic, lets add context to our event and instead of just being a passthrough, lets also add the line as a context. This is done in the task Expression Evaluator.

Checking Message Bus Message through the GUI#

In the Administration/MessageBus section, we can generate and subscribe to Message Bus messages. If you want to subscribe all messages, use the special character >. For our use case we can see the message being broadcast by adding a subscription to Cmf.Line.PartsFinished.

Line 2 Configuration#

Leave the Setup as default and create a new page Receive PartsFinished. In this page we will subscribe to the message bus topic Cmf.Line.PartsFinished and we will retrieve the last value sent and set the property with the last value.

IMPORTANT: In this case we are using the context to filter messages that are from line 1 with a Switch, this allows to be more dynamic, on what messages to consume or not, this can also be done by generating unique topics that only the two peers know, allowing for a peer to peer communication. It’s very important to try and minimize traffic in the network, so you want to as most as possible to only broadcast the message to who you want as a consumer.

Getting it to Work#

Create an Automation Manager and Connect the Automation Controllers. In my case, I have a manager called the MQTT_Manager.

First, let’s start the broker with mosquitto.

.\mosquitto.exe -v

We will need a publisher to broadcast the message of the parts finished and a subscriber to receive the parts to be produced.

.\mosquitto_sub.exe -h localhost -t "Line.2.PartsToBeProduced"

Start the Automation Manager, this will start both Controllers and Drivers.

Let’s start sending messages and see how the system behaves. For now, we will send two messages with 1.

.\mosquitto_pub.exe -h localhost -t "Line.1.PartFinished" -m "1"

You can also see the value changing on the subscriber.

Right, now we already have a communication between both controllers through the Message Bus.

Bonus#

Let’s implement a Reset, so the use case would be to have a line clearance, where you want to cascade reset the counters.

In the driver definition create a new property for the topic Line.1.ClearLine and create a new event OnLineClear. For the Line 1 Controller create a new page Line Clear. In this page we will receive an event and activate a Message Bus Message for the topic Cmf.Line.Clear, in this case we will not add context.

In Line 2 we will now have a new page Reset Counters where we persist the value of the counter as 0 and set the property as 0.

Author#

Hello 👏 , my name is João Roque ✌️#

I’ve been working for some years at Critical Manufacturing. I split my time working in the IoT Team and working with the project’s teams. You can visit me at https://j-roque.com/ or check me at LinkedIn

Skills: Connect IoT / DevOps