Figure 1: One of the most common IoT architectures, using the MQTT protocol.

© DataArt

MQTT - the favorite

It is obvious that the guidelines are created in the most universal and best applicable way. The MQTT protocol can be found in most of them. AWS IoT, Azure IoT and Google Cloud IoT are based on MQTT messages. A popular open source message broker, Eclipse Mosquitto, also uses MQTT for message exchange.

An example: In a project realized by DataArt in the field of heavy industry, data from sensors had to be delivered from the field. It was to be used in a digital twin solution to predict metrics and values of possible future conditions. The solution was built on AWS. Figure 1 shows the original architecture offered.

However, such architectures can often be simplified. This can be seen in another project involving thermostats and HVAC systems. Here it is practical to send and receive commands via the same channel and even automate some logic on the MQTT broker side. When the thermostat changes state, an MQTT message can be fetched directly from the HVAC device that has subscribed to the corresponding MQTT topic. As these devices are connected to a local gateway that also acts as an MQTT broker, the entire system can continue to operate without a connection to the cloud, i.e. completely locally. However, such solutions require an advanced firmware upgrade system for all devices in order to make changes to the logic of the devices.

Figure 3: Only the costs for the data lake are incurred. The MQTT brokers do not need to be maintained. This is a double win situation.

© DataArt

Save AWS costs

Everything can be made a little easier by sending the data directly to a data lake. Since

AWS GreenGrass is already in use, there are credentials for AWS and the boto3 library on the gateway side. So why not exclude MQTT and Lambdas from this project to save AWS costs? You can give the data lake the "Insert only" authorization and simply insert the data from the gateway side. The architecture is shown in Figure 3.

The calculations for 10,000 devices now look like this: Each device sends a message once per minute. In the case of AWS IoT, the connection costs must be paid: 432,000,000 connection minutes correspond to 34.38 dollars per month. Then there is the fee for the messages: 432,000,000 messages per month is 432 dollars. And the payments for AWS Lambda calls, which in the case described amount to 288 dollars. In total, you can save 750 dollars per month for 10,000 devices. And that's even without further DevOps optimizations, simply because the right decision was made in the design phase of the solution.

Nikolay Khabarov is Senior Architect, IIoT and Industry 4.0 at DataArt

© DataArt

Room for optimization

Most digital twin/IIoT projects only need to collect data. This allows simpler protocols such as direct access to the data lake or even HTTPS requests to be used to deliver such data. However, the choice always depends on the requirements. There are no one-size-fits-all solutions and there is always room for optimization.

Reducing operating costs is a trend in modern IIoT innovations. Above all, this shows that the industry has reached this stage of maturity. The introduction of innovations requires detailed planning, thorough ROI calculations and a deep understanding of every aspect of an evolving solution. It's important to realize what a 20-30% OpEx difference would mean to your business - and that 20-30% savings is just the average overhead DataArt has seen in recent optimization projects. So no, it's not always about MQTT.