Where industrial equipment, like sensors and control systems, utilised protocols such as Modbus, BACNet, Ethernet/IP, we continue to see the adoption of newer (I stress the new-er bit for good reason) communication protocols and standards such as MQTT.
To be clear: MQTT is not the same as these previous protocols – while it is being used to solve some of the same problems, predominantly communication between devices, it is different for a number of reasons…
What is MQTT?
MQTT is a communication messaging protocol, designed to send and subscribe to telemetry from devices – it is used for Machine-to-Machine communication and continues to be adopted across the internet of things space.
In short: It is a protocol that allows devices to send and receive data from each other.
Examples of systems that utilise this protocol in practice:
- Industrial Process Automation Controllers and SCADA systems
- New types of sensors – Temperature, Humidity, Pressure
- Energy Sub-meters – Gas and Electricity
- Building Management Systems
MQTT allows systems and applications to subscribe to the data they are interested in, in a much easier fashion with added security and efficiency benefits that the previous protocols mentioned don’t necessarily cater for.
The protocol differs from the typical request/response topology such as Modbus (RTU and TCP). MQTT uses a publish/subscribe topology. This means that devices or systems publish their data (on request or periodically) and other devices that are interested in the data listen to and receive the data.
The devices producing the data, such as sensor or process information, typically publish this on a named topic and the interested subscribers are configured to listen to that specific topic for the corresponding data.
This does mean, however, that all devices and their subscribers must communicate through a central point – in MQTT terms, this is known as a broker of which many can be used. The broker is simply a piece of software that can run on a computer, a server, in the cloud, on-premises, and even on a small Raspberry Pi if you want to try it at home.
Unlike, for example, Modbus networks, where there is a single device that is responsible for requesting information from devices on the network, the devices will respond to those requests on demand. In this case, there is no broker required here but there is no way for other systems to easily to subscribe or access that information without going through the primary device.
What does MQTT enable?
MQTT is quite prolific outside the industrial sector, especially in the smart home and automation space. Even communication between cloud applications is known to use it for data interchange.
It’s allowing teams of people to access and subscribe to mission-critical data securely and in-realtime while mitigating many cybersecurity risks that previously were a concern. This brings us nicely to the next big question:
Is MQTT secure?
With anything to do with cybersecurity, the answer is, it depends on how it is configured.
MQTT by default runs over TCP/IP and therefore has the ability to run over TLS – Transport Layer Security – which adds a layer of encryption and cryptographic authentication. This means that at the transport layer (i.e. over the network) the data can be encrypted in transit. TLS also has the added benefit of features that allow the device to be certain that the broker it is communicating with is who it says it is – an attacker cannot impersonate the broker and intercept communication.
It’s important to note: MQTT brokers and devices need to be set up and configured to support this – by default many systems are not configured like this – there are challenges to this in itself.
Compared to older protocols that predate TLS technology adoption – yes this is a more secure option – in practice though it is important to remember the point above.
Device Interoperability with MQTT Challenges
Over the last 4 years, we’ve worked with lots of devices that publish to MQTT brokers – devices in all shapes and sizes that push data to the Hark Platform via MQTT(S). For example:
- Energy Storage Systems
- Energy Meters
- SCADA and Process Control Systems
- Tridium Niagra BMS Systems
The challenge with MQTT and these devices is the data format of messages coming from all these devices – they are almost always different shapes and sizes.
Many devices send their data in JSON format, many send just single numbers, some send their data in binary format and very occasionally others send them in a proprietary format (oh dear…).
This is challenging because some of these devices that need to listen to data over MQTT aren’t actually able to interpret it because the message format between devices and manufacturers is different. It’s something that we are dealing with at Hark by using the Hark Platform to mix and match different systems together for customers without worrying about interoperability issues.
Pros and Cons of MQTT
Pros:
- MQTT is lightweight and easy to use with a myriad of devices old and new. It’s also very fast due to how lightweight it is.
- MQTT has better configuration options for encryption and security by using TLS.
- MQTT brokers (including the Hark Platform) have the ability to authenticate, authorise and log traffic for detailed security monitoring purposes.
- MQTT implemented correctly, can be used to give secure access to sensor data to devices and teams of people in order to generate insight without comprising industrial security – on-premises or in the cloud.
- Minimal network requirements make it a great choice for networks that have very little bandwidth such as mobile networks and event low power radio networks
- There are lots of software and tools available for free to assist with deployments of MQTT devices.
Cons
- MQTT requires a broker, there are many to choose from – they must be configured well for security and other scalability factors.
- Messaging formats between devices can add integration challenges between devices and increase the cost of deployment (best case).
- Scaling MQTT brokers can be challenging as it is a stateful protocol – this means that the more devices and messages going through a system the more compute resource required.
- MQTT uses topics (which is arguably a pro) but with thousands of devices and lots of data this can become unruly to manage.
- It can be a challenge setting up the security and encryption correctly, sometimes devices in the field may not support the best practice security options that MQTT can be configured with due to TLS certificates.
- New specifications of the MQTT protocol will come out (this is a good thing) but devices in the field will likely not be able to support them straight away and at the very least not without an upgrade.
