Imagine you’re the manufacturer of industrial equipment — perhaps you supply power generators to war zones, or monster excavators to mining projects, or perhaps you make sensors for monitoring pipelines.
The equipment that you produce is inherently big and complex — which means that it’ll be packed with gizmos and sensors to monitor its health, performance and to detect faults/errors.
If a sensor fails in the forest, and nobody is around, does it make a sound?
Herein lies the problem. Your equipment isn’t around the corner — you can’t just pop over to check it’s ok. If it’s truly remotely deployed, it may require several days travel and a helicopter to check!
Clearly this isn’t a sustainable or practical solution — so what about remote monitoring? It’s unlikely that you’ll be within cellular coverage, and if you are it’s likely to be patchy and unreliable (it’s like that even in the middle of London sometimes)!
In this instance, the only viable option you have for remotely monitoring your equipment is via satellite. Today, there’s a multitude of satellite operators and terminals available, each with their respective pros/cons in respect of physical size, operating cost, power requirements, communication speed and bandwidth etc.
For our hypothetical scenario, let’s assume we make monster excavators used to extract lithium from remote Australian mines. They’re super-computers on wheels and are packed with sensors, measuring things like: temperature, pressure, vibration, movement and location. There’s a ready supply of power but physical space is limited. Being able to monitor this data in real-time is invaluable for things like performance and safety monitoring.
Introducing Ground Control’s RockREMOTE
The RockREMOTE is an Iridium Certus IoT terminal, providing both IP connectivity and IMT-based messaging from anywhere on the planet. Its IoT Gateway enables easy integration with other equipment and applications through the lingua-franca of the IoT industry — MQTT.
How do we connect the RockREMOTE to a monster excavator?
In our scenario, we’ve got an onboard network connecting all the sensors to a central data logger which stores the sensor readings. The sensors themselves speak to the data-logger via the industry-standard CAN bus protocol as is commonly used in the automotive industry.
The data logger is simply connected to the RockREMOTE via Ethernet cable.
Yes that’s a child’s toy — no expense spared artist’s impression showing the system end-to-end
Data Logger > MQTT > RockREMOTE (IoT Gateway)
So we’ve got our readings gleaned from the onboard sensors; they’re currently stored in a simple database on our data-logger. This is a proprietary system developed in-house, so we’ll need some developer-smarts to send the data to the IoT Gateway on the RockREMOTE.
Side note: it’s at this point that everyone’s system will vary. In the event that you’re not already utilising MQTT, some development work will be unavoidable. Fear not: due to the ubiquity of MQTT, it’s very widely supported and there’s established libraries for most platforms and programming languages.
Our data-logger runs Linux so we have a multitude of tools at our disposal; the simplest and easiest being a basic Python script (as shown below):
import time
import paho.mqtt.client as mqtt
#Connect to RockREMOTE
client = mqtt.Client()
client.username_pw_set("username", "password")
client.connect("192.168.250.1", 1883, 60)
while True:
data = get_data_to_send_from_data_logger() #Get data from database
client.publish("lithium/truck01", data) #Send the sensor readings
time.sleep(60) #Sleep for 60 seconds
This snippet will diligently send the sensor readings to the IoT Gateway every 60 seconds. That’s it — pretty cool 😎
What do you mean that’s it — we’ve not even mentioned Satellites?
This is where the RockREMOTE IoT Gateway comes into its own!
RockREMOTE x IoT Gateway
So let’s pop the proverbial hood and let’s see what’s actually going on here.
On the surface, IoT Gateway exposes a standard MQTT broker — nothing special or proprietary — this means any existing MQTT client/library can connect and publish messages.
Security specialists: on this interface it utilises basic username/password authentication; so there’s no certificate authentication with which to concern yourself. No one wants to charter a helicopter to update an expired certificate, and if the monster excavator is physically compromised – well, you’ve got bigger problems to worry about…
There’s no restriction to the message payload that you publish — you can send text or binary; anything you like — most popular for IoT applications is JSON or Protobufs. The only limitation is that the total message size must not exceed 100 Kb — more on this in a second.
Not sure what MQTT is?
It’s pretty straightforward. MQTT is an industry standard which describes a simple Pub-Sub protocol whereby: clients connect to a broker and PUBLISH messages — other clients connect to said broker and SUBSCRIBE to receive the messages when published — that’s pretty much it!
To keep things organised it utilises the concept of TOPICS — whereby a message is published to a named topic — typically these take the form of a directory structure (e.g. /site01/sensor10/temperature) but you can use anything you like.
It does a few other things, but that’s all you need to know for now!
In the same way there’s no restriction to the message payloads, there’s also no restriction to the topics that you use. This is super convenient if you’re migrating from an existing MQTT solution — no need to change your topics!
So to recap: you can use any MQTT client/library, send any message payload to any topic you like. It’s almost as if Ground Control have taken a monster excavator to any possible barriers or hurdles to using this!
C’mon — what about the satellites?
So we’ve PUBLISH’d our inaugural “Hello World” message to IoT Gateway — what happens next? How do I get hold of these beautiful ones and zeros?
It’s magic. Or it may as well be, we don’t actually need to do anything more — the IoT Gateway takes care of all the heavy lifting. But since you’ve come this far — let’s dig into the wizardry…
The RockREMOTE is an Iridium Certus 100 IoT terminal. This means that it can talk to the Iridium satellite network to send/receive data. It has truly global coverage and works anywhere on the planet at any time of the day.
Zeroing in further, the IoT Gateway makes use of the brand new Iridium Message Transport (IMT) service. Read the deep-dive into how IMT works and how it differs from other IP Connection-based services.
In essence, this is a message-based service for sending/receiving messages up to 100 Kb. You’re only charged for the data you successfully transmit, so you’re not charged for protocol overhead, handshaking or bloat 😎
Sending the Message
Anything you PUBLISH will be automatically packaged and sent to space. IoT Gateway takes care of managing the connection, message queuing, retries etc — truly fire-and-forget!
Thud!
That’s the sound of your “Hello World” message landing down to earth.
This time instead of being in a remote Australian lithium mine; it’s in sunny Tempe, Arizona (where Iridium’s ground station resides). From here it’s whisked to Ground Control’s omnipresent platform, Cloudloop.
Your message, still cold from its brief stint in space, is reconstituted and published to their secure cloud-based MQTT broker (not to be confused, with the broker mentioned earlier, that resides on the RockREMOTE).
Again, this completely standard MQTT interface can be securely connected to with any MQTT client or library, allowing your cloud-application to consume the messages published from IoT Gateway.
Back to the monster excavator…
Recap: we’ve used a Python script running on our data-logger to relay sensor data (via MQTT) to the IoT Gateway every 60 seconds. For the alert readers, you’ll recall this data was published to the lithium/truck01 topic. The data has gone via satellite and has now been re-published to the MQTT broker residing in Cloudloop.
We’d now like to present the sensor data in real-time on a dashboard screen we’ve got setup in the office. For this, we’ll need to SUBSCRIBE to the relevant topics to get this information automatically pushed to it.
We’ve got two options — use an existing IoT Dashboard (e.g. Thingsboard) or create something ourselves. We’ll take a look at how we might get the data ourselves here.
To consume the messages from Cloudloop MQTT:
import paho.mqtt.client as mqtt
my_topic_name = "iot/ACCOUNT-ID/lithium/truck01"
def on_connect_callback(client, userdata, flags, rc):
client.subscribe(my_topic_name)
def on_message_callback(client, userdata, msg):
print("NEW MESSAGE: " + msg.topic +" " + str(msg.payload))
client = mqtt.Client()
client.tls_set(caPath,
certfile=certPath,
keyfile=keyPath,
cert_reqs=ssl.CERT_REQUIRED,
tls_version=ssl.PROTOCOL_TLSv1_2,
ciphers=None)
client.on_connect = on_connect_callback
client.on_message = on_message_callback
client.connect("mqtt.cloudloop.com", 1883, 60)
client.loop_forever()
Side note: the message was technically published to iot/ACCOUNT-ID/lithium/truck01 — this is because it’s a multi-tenanted environment and the prefixing nicely provides account-segregation.
In this scenario, we’ve been working with a single excavator — but there’s nothing stopping this working with multiple. You can easily see by changing the topic name (e.g. cobalt/truck32) we could support multiple sites and multiple excavators 😎
What about sending messages to the monster excavator?
So far, we’ve only spoken about data originating from the monster excavators (Mobile Originated in satcom parlance) — but what about sending messages to the excavator (i.e. Mobile Terminated)?
No problem, it works in exactly the same way — just in reverse.
Simply PUBLISH a message to Cloudloop MQTT and it will be sent via space and picked up by the IoT Gateway; the data-logger would just need to SUBSCRIBE to that particular topic to receive the message.
Would you like to know more?
