When we hear the term edge, depending on who we are and what experiences we have had, we tend to think of many different scenarios. However one of the main themes in all of those scenarios, besides the fact that edge is usually outside of the data center and filled with potential physical and environmental constraints, is the need to capture telemetry data from all of those devices. The need to understand the state of the systems out in the wild and more importantly to be able to capture more detail in the event the edge device goes sideways. Now the sheer numbers of fleet devices will produce a plethora of data points and given we might have network constraints we have to be cognizant of how to deliver all that data back to our central repository for compliance and visibility. This blog will explore the possibilities of MQTT providing a solution to this voluminous problem.
For those not familiar with MQTT, it is a protocol developed back in 1999. The main requirement for the protocol was the transfer of data in networks with low bandwidth and intermittent connections. MQTT was developed primarily for system to system interaction which makes it ideal for connecting devices in IoT networks for either control action, data exchange or even device performance. Further it implements a bi-directional message transmission so a device can receive and send payloads to other devices all without knowing those other devices network details. Perfect for use cases like planes, trains and automobiles where the ipaddress state might be dynamic and change.
MQTT has three primary "edgy" features:
- Lightweight
- Easy to implement and operate
- Architecture of a publisher-subscriber model
Let's explore a bit about each of these features. First its lightweight and that means the protocol is able to work on low-power devices like microcontrollers, single board computers to systems on chip (SoC). This is definitely important since some of these devices are small and operate on battery power. The lightweight aspect also imposes minimal requirements and costs on the data moved across the network. This quality is provided by a small service data header and a small amount of actual payload data transmitted. And while the maximum size of the transmitted data in MQTT could be 256Mb, usually data packets only contain a few hundred bytes at a time.
The second feature of MQTT is the simplicity of the implementation and operations. Because MQTT is a binary protocol which does not impose restrictions on the format of the data transmitted, the engineer is free to decide what the structure and format of the data. It can be a number of formats like plain text, csv or even the common JSON format. The format is really dependent on the requirements of the solution being built and the medium the data transmission rides across. Along with the openness of how the data is transmitted the protocol has both control packets to establish and control the connection along with a mechanism based on TCP to ensure guaranteed delivery.
Finally the architecture of MQTT differs from other classic client server configurations in that it implements a publisher-subscriber model where clients can do both but do not communicate directly with other clients and are not aware of each others existence on the network. The interaction of the clients and the transfer of the data they send is handled by an intermediary called a message broker. The advantages of this model are:
- Asynchronous operation ensuring there is no blocking while waiting for messages
- Network agnostic in that the clients work with the network without knowing the topology
- Horizontal scalability which is important when thinking of 10k to 100k devices
- Security protection from scanning because each client is unaware of the other clients IP/MAC
Overall the combination of the primary "edgy" features makes MQTT an ideal transport protocol for large amounts of clients needing to send a variety of data in various formats. Thus making MQTT attractive in the edge space for device communication.
MQTT could also be perfect for telemetry data at the edge and to demonstrate the concept we can think about edge from an automobile perspective. Modern cars have hundreds of digital and analog sensors built into them which generate thousands of data points in a high volume of frequency. These data points are in turn dumped as a broadcast onto a vehicles Controlled Area Network(CAN) data bus which in turn could be listened to with a logger or MQTT client to record all of the messages they are sending. The telemetry data itself can be divided into three general categories:
- Vehicle parameters
- Environmental parameters
- Physical parameters of the driver
The collection of these data points in those sub categories enables manufacturers and users of the vehicle to achieve goals like monitoring, increased safety of the driver, increased fuel efficiency, time to resolution on service diagnosis and even in some cases the state of the driver themselves.
Given the sheer volume of the data and the need to structure it in some way compounded by the number of cars on the road MQTT provides a great way to horizontally scale and structure data. The design details will be derived based on requirements of the telemetry needs and where constraints might exist along the path to obtaining the data points.
Take for example how we might structure the data for MQTT from the automobile sensors. In one case we could use MQTTs topic structure and have a state for each item we want to measure and transmit:
schmausautos_telemetry_service/car_VIN/sensor/parameter/state schmausautos_telemetry_service/5T1BF30K44U067947/engine/rpm/state schmausautos_telemetry_service/5T1BF30K44U067947/engine/temperature/state schmausautos_telemetry_service/5T1BF30K44U067947/engine/fuel/state schmausautos_telemetry_service/5T1BF30K44U067947/engine/oxygen/state schmausautos_telemetry_service/5T1BF30K44U067947/geo/latitude/state schmausautos_telemetry_service/5T1BF30K44U067947/geo/longitude/state schmausautos_telemetry_service/5T1BF30K44U067947/geo/elevation/state schmausautos_telemetry_service/5T1BF30K44U067947/geo/speed/state schmausautos_telemetry_service/5T1BF30K44U067947/geo/temperature/state
This option relies on MQTTs ability to create a semantic structure of topics. Each topic is specific to a particular sensor and can be accessed individually without the need to pull additional data. The advantage of this option is that both the client and broker can transmit and access respectively the indicators of interest. This reduces the amount of transmitted data which reduces the load on the network. An appropriate option where wireless coverage is weak and/or intermittent but parameter control is required because transmitting a few bytes of parameter data is easier then a full dump of data.
A second option for the same type of data might be using the JSON data format and combining all of the sensor data into a single hierarchical message. Thus when accessing the specific vehicles topic the whole of all vehicle data is passed in a key pair value format. The advantage of this method is that all parameters are available on a single request. However because of this and the potential for large data sized messages it will increase load on the network. Further it will also require something to serialize and deserialize the JSON string at he client ends of the MQTT interchange. This method is more useful when there is a reliable network connection and coverage.
schmausautos_telemetry_service/car_VIN/state
{
engine: {
rpm: 5000,
temperature: 90,
fuel: 80,
oxygen: 70,
},
geo: {
latitude: 45.0101248,
longitude: -93.0414592,
elevation: 2000,
speed: 60,
temperature: 65,
},
...
}
Either option again based on constraints in the requirements could be valid and useful. But overall they show the flexibility of MQTT and its ability to handle both the sheer scale and the amount of telemtry data coming in from the vehicles multiple sensors and sources multiplied by the number of vehicles in the fleet.
Hopefully this blog provided some insight into MQTT and its use for telemetry at the edge. MQTT while an old protocol was designed from the beginning for these edge type use cases. Use cases that require low power consumption, easy of operation and flexibility to consume and present data in many formats. And while we explored using MQTT as a method for telemetry data there are certainly more uses for MQTT in the edge space.
