Enterprise Mobile Computing with BlackBerry 10 Apps and the Internet of Things Protocol MQTT: Part 1

You may have read articles here in the BlackBerry Developer Blog written by John Murray and myself about topics like Bluetooth and NFC, and noted our occasional reference to “the Internet of Things,” or IoT.

IoT is more than just a peripheral (no pun intended!) topic for us here at BlackBerry. You may also be familiar with our concept of “Sense, Understand and Adapt.” BlackBerry smart phones are mobile computing devices that can be connected to the physical world and its contents (“things”) in many exciting ways. How? With applications that use data collected from our physical world in an intelligent manner, which enriches the user’s experience and makes genuinely new things possible.

There are many layers to the IoT onion, including connected “things” such as sensors and NFC or Bluetooth connected devices and a BlackBerry 10 devices interfacing with those “things.” But there’s another layer in the IoT onion: the cloud. The cloud is where massive amounts of data, collected by hordes of IoT connected mobile computers, will be sent for analysis and exploitation. Yes, we’re talking “Big Data” here.

This blog contains plenty of information on how BlackBerry 10 devices can work with sensors and peripherals. But what about that final layer? What’s the current thinking on how data from “things” can be collected, distributed and exploited? And what are the current use cases and future possibilities driving this area?

Imagining the possibilities

John and I sat down together one day to research and brainstorm this question. We decided to focus on a specific industry sector where BlackBerry is already well established: automotive. We researched state-of-the-art in-car technology, reviewing the research and development work the automotive manufacturers themselves are reported to be doing around in-car connected devices (such as sensors). Armed with this context and our knowledge of BlackBerry mobile computing, we asked ourselves one key question: “What if…?”

So what follows is a mix of thoughts and ideas based on fact and current capabilities, as well as things we dreamed up ourselves that have a sound basis in existing technologies and research. It’s not fantasy; consider this “food for thought” regarding mobile computing and IoT. Your homework (should you choose to accept the task) is to discuss, think, Tweet and blog about this topic, and to develop IoT applications for BlackBerry 10 that take the connected world by storm.

The Automotive IoT Brainstorm

Question 1: What sensors, systems or data might we find in a car today or in the near future?

Here is a (by no means complete) list we came up with, straight from the whiteboard, in no particular order:

• Tire pressure sensors
• Wheel speed sensors
• Rotational speed measurement sensors (e.g. cam shaft rotation speed)
• Transmission speed sensors
• Vehicle speed sensors
• Temperature sensors
• Rain sensors
• Long Range Radar Sensors (LRRS – used to maintain a safety margin to the vehicle in front)
• Collision Mitigation Systems (CMS)
• Driver heart rate monitoring, perhaps embedded in the driver’s seat
• Driver stress monitoring, perhaps via sensors in the steering wheel
• Driver glucose level monitoring sensor
• Location aware data delivered over the air to in-car systems (e.g. allergy or asthma alerts relating to the area the car is driving through)

Question 2: And what might we do with the data these devices, systems and sensors collect?

There are all sorts of possibilities here, but the ones we spent most time talking through were driving style/patterns analysis and driver welfare.

1. Driving style/patterns analysis

Premise: Corporate enterprises, especially those that operate large fleets of vehicles, like their drivers to be good drivers. Bad driving damages their reputation and brand, and very bad driving causes accidents.

Brainstorm:

• Collecting data from the whole fleet over time may help identify drivers in need of feedback or additional training. LRRS, location aware and weather related data would be useful in answering question such as, “Is the driver consistently driving too close to other vehicles?” and “Do they make adjustments in wet weather regarding stopping distances?”
• Vehicle data (such as tire pressures) collected centrally could identify standard maintenance issues that the driver is responsible for but not addressing, thus decreasing risk
• Identification of drivers who consistently drive well for purposes of rewarding
• Bad driving patterns that are prevalent across the whole fleet, which could point to a vehicle issue or simply the need for a bigger training program

2. Driver welfare

Premise: Corporate enterprises have a duty of care. A healthy and alert driver is a good and safe driver.

Brainstorm:

• System can collect driver personal health and well-being data and look for “immediate” danger signs, as well as medium and long term patterns, including stress levels, heart rate and glucose levels
• In-vehicle information and/or warnings to the driver on BlackBerry 10 in-vehicle console
• Augment with data from other wearable devices
• Augment with server-side corporate database of employee information (age, disclosed health issues such as diabetes or allergies, etc.)

In both cases of these brainstorms, data must be shared with cloud-based systems for pattern analysis, augmentation and exploitation, as well as being used directly within the vehicle courtesy of the onboard BlackBerry 10 mobile computing device.

So how would we collect vehicle and driver data for use immediately in the vehicle, and more importantly, for storage, analysis and use by enterprise cloud-based systems? The short answer is “all sorts of ways,” but the question led us to an open standards based protocol from IBM, managed by OASIS, called MQTT.

MQTT

MQTT stands for Message Queuing Telemetry Transport. It’s a lightweight messaging protocol designed specifically with IoT and M2M (Machine to Machine) scenarios in mind. It allows for the implementation of clients for devices where the code footprint needs to be really small, and works over networks where bandwidth is at a premium, where there may be high latency and reliability issues. What’s more, MQTT is not a new protocol currently emerging from a lab. It’s proven, and you probably already use it; Facebook Messenger uses MQTT. Based on these factors, we thought MQTT sounded perfect  for what we were trying to achieve!

For a full understanding of MQTT, you’ll need to read the specification. However, below are a few key points:

• MQTT is a message-oriented publish/subscribe system.
• Clients may publish messages that relate to “topics,” which are like subjects or channels. Message payloads contain binary data and so it can be anything.
• Clients may subscribe to particular topics, in which case they receive messages published by other clients addressed to those topics
• A MQTT server or message broker, which is a piece of message-oriented middleware, is responsible for handling client connections and providing the publish/subscribe service.
• MQTT defines a number of request and acknowledgement message types:

• Three levels of Quality of Service (QoS) are defined, and clients indicate which they want to apply to messages that they publish:

• Mosquitto is an open source MQTT message broker

Typically, an MQTT client will CONNECT and either SUBSCRIBE to one or more topics, PUBLISH to one or more topics, or both. When an MQTT server receives a PUBLISH message, it distributes the message to clients that have subscribed to the topic referenced in the PUBLISH request in some manner which is determined by the requested QoS.

The BlackBerry 10 MQTT Proof of Concept

From our research and brainstorming, we now believed that we could use MQTT to allow a BlackBerry 10 mobile computing device in a vehicle, itself acting as a local data collection and aggregation hub, in contact with in-car and driver attached sensors, to send and receive data to cloud based enterprise systems. MQTT would be a good choice of protocol for this use case and the kind of operating conditions it would be required to work in. This sounded like a great theory – and we like theory  – but we also very much like concrete, real-world implementation! Stay tuned for part 2 of this post, in which we implement an MQTT client as a proof of concept for BlackBerry 10 applications! Meanwhile, let us know your additional thoughts on how IoT could develop future apps!