Introduction to MQ Telemetry

Overview

Telemetry is the automated sensing, measurement of data, and control of remote devices. The emphasis is on the transmission of data from devices to a central control point. Telemetry also includes sending configuration and control information to devices.

IBM® MQ Telemetry connects small devices by using the MQTT protocol, and connects the devices to other applications by using IBM MQ. IBM MQ Telemetry bridges a gap between devices and the internet making it easier to build “smart solutions”. Smart solutions unlock the wealth of information available on the internet, and in enterprise applications, for applications that monitor and control devices.

People, businesses, and governments increasingly want to use IBM® MQ Telemetry to interact more smartly with the environment we live and work in. IBM MQ Telemetry connects all kinds of devices to the internet and to the enterprise, and reduces the costs of building applications for smart devices.

Introduction

IBM MQ Telemetry is a feature of IBM MQ that extends the universal messaging backbone provided by IBM MQ to a wide range of remote sensors, actuators and telemetry devices. IBM MQ Telemetry extends IBM MQ so that it can interconnect intelligent enterprise applications, services, and decision makers with networks of instrumented devices.

The two core parts of IBM MQ Telemetry are:

The IBM MQ Telemetry service that runs inside of the IBM MQ server.
IBM MQ Telemetry clients that are distributed to devices together with the applications.

What can it do for me?

MQ Telemetry uses the MQ Telemetry Transport (MQTT) to send and receive data between your applications and the IBM MQ Queue Manager.
MQTT is an open messaging transport that allows MQTT implementations to be created for a wide variety of devices.
MQTT clients can run on small footprint devices that might have limited resources.
MQTT works efficiently on networks where the bandwidth might be low, where cost of sending data is expensive or which might be fragile.
Message delivery is assured and decoupled from the application.
Application programmers do not need to have communications programming knowledge.
Messages can be exchanged with other messaging applications. These may be other telemetry applications, MQI, JMS or enterprise messaging applications.

How do you use it?

Use the IBM MQ Explorer and its associated tools to administer the IBM MQ Telemetry feature of MQ.
Use MQTT clients in your applications to connect to a queue manager, publish and subscribe for messages.
Distribute your application with the MQTT client to the device where your application is to run.

How does it work?

The MQ Telemetry service turns an IBM MQ queue manager into an MQTT server
The MQTT server understands the MQTT message transport and can receive messages from and send messages to MQTT clients.
MQ Telemetry ships with a number of Telemetry clients that implement the MQTT message transport. These are often referred to as MQTT clients.
A basic Telemetry client works like a standard MQ client but can run on a much wider variety of platforms and networks.
An Advanced Telemetry Client acts as a network concentrator to connect an even greater number of MQTT clients to a single queue manager. It can also provide store and forward for small devices that lack a means to buffer messages during short network outages.
IBM MQ Telemetry daemon for devices is an Advanced Telemetry client that is part of IBM MQ Telemetry.
MQTT is a publish subscribe protocol:
- An MQTT client application can publish messages to an MQTT server.
- When an IBM MQ queue manager acts as the MQTT server other applications that connect to the queue manager can subscribe for and receive the messages from the MQTT client.
- An MQTT client can subscribe for messages that are sent by applications that connect to an MQ queue manager.
- The queue manager acts as router distributing messages from publishing applications to subscribing applications.

Messages can be distributed between different types of client applications. For instance, between Telemetry clients and JMS clients.

IBM MQ Telemetry replaces the SCADA nodes that were withdrawn in version 7 of IBM Message Broker and runs on Windows, Linux, and AIX.

Background and history

IBM MQ is the market-leading integration product for message-oriented-middleware (MOM) and has been so since the 1990s. The benefits of the MOM approach of loosely-coupled interfaces, reliable delivery and cross-platform ubiquity have demonstrated huge value in the enterprise application space. This is both technically in terms of more reliable and efficient IT systems and commercially in terms of reduced cost of ownership and vendor dependency.

By the early 2000s, with the advance of embedded device technology, a market began to emerge for extending the MOM style of integration to the edges of the enterprise. In the field of industrial automation, Supervisory Control And Data Acquisition (SCADA) systems provided the means for industrial organizations to both control hardware at and gather data from remote, unmanned installations such as power stations and oil pipelines. This allowed companies to have greater operational control and insight on their business at its furthest extremes.

Whilst delivering value, these systems were typically highly proprietary to particular hardware vendors resulting in single-vendor lock-in, lack of integration with other ERP systems and also a high cost of extension and modification. Applying a MOM approach to SCADA would allow cleaner separation of the hardware from the data link layer, and a smoother path into the flexibility of general purpose enterprise middleware. This would mean that not only could devices from multiple vendors participate in the SCADA systems, they could also integrate directly with rest of the enterprise integration layer.

To fulfill this need, IBM developed the MQ Integrator SCADA Device Protocol (MQisdp) to extend its MOM software specifically for the requirements and constraints of the SCADA environment such as:

Fragile, low bandwidth and/or expensive networks.
Limited processing power at the remote sites.
Low memory capacity in remote embedded systems.

MQisdp was made available as the SCADA nodes in the MQ Integrator product which later became known as IBM Message Broker (WMB), then IBM Integration Bus (IIB), and now IBM App Connect Enterprise. IBM also published the protocol specification, to encourage third-party adoption of the MQTT protocol by third-party device vendors and software houses. This also provided a degree of reassurance to SCADA customers who were nervous of wholly proprietary products and technology.

The MQisdp protocol gained traction in other industries with similar demands, in particular the field of telemetry, leading to a change of name to MQ Telemetry Transport (MQTT). Since then, MQTT has been successfully deployed in a variety of industries from energy and utilities to retail. In IBM Smarter Planet terminology, MQTT deals with the link between “instrumented” and “interconnected” tiers.