Predictive Maintenance for Industrial IoT Devices at the Edge

Predictive Maintenance for Industrial IoT Devices at the Edge | SPONSORED

Getting your Trinity Audio player ready...

Working at the edge

In industrial operations, time is money. The more efficient processes and machinery are, the better it is for business. Providing proactive monitoring and maintenance of industrial machines, however, is not an easy task. This is especially true as these machines become increasingly complex and distributed. It’s not possible to have maintenance crews on site for every asset in a distributed system.

The edge is where the physical world meets the digital world. As more organizations push workloads to the edge and resources at the edge increase, having so many devices in so many places make it necessary to automate monitoring to streamline operations and to optimize a limited workforce.

Edge monitoring tools

Fortunately, for industrial IoT (IIoT) and Operations Technology (OT) practitioners, InfluxDB provides tools designed specifically to address this need. Telegraf is a plugin-based, open source data collection agent that can collect time series data from virtually anywhere. The open source version of InfluxDB is a lightweight database that can run on or near edge devices to store and analyze that data close to the source.

These tools help manage data at the edge, but in a distributed system it’s often necessary to create centralized views of all the edge devices to create a holistic view of the operation.

For example, let’s say there’s a solar energy company with solar panel facilities distributed across the country. The company can use InfluxDB at the edge to monitor each individual installation, and then automatically send that data to InfluxDB Cloud for centralized storage and analysis. InfluxDB Cloud, enables users to analyze data in real-time to create visualizations, predictive maintenance models, and more.

Set up Edge Data Replication

Edge Data Replication (EDR) is a feature in InfluxDB OSS 2.x that creates a durable queue on disk and automatically sends that data to a cloud instance of InfluxDB.

To get started, you need to install InfluxDB on or near an edge device. Telegraf is a great way to get data into InfluxDB, but once you configure Telegraf to ingest data, you don’t need to do anything further with it for EDR.

Create a connection

Once you have an InfluxDB instance, you need to create a remote connection. In this context, the local source is at the edge and the remote device is the cloud. The name of the remote can be whatever you need it to be. Let’s say that our solar company is aggregating this data for use at their headquarters, so we’ll name the remote hq so anyone working on the edge knows where the data will end up. You need to get the org ID, URL, and API token from your Cloud instance and plug them into the following commands.

influx remote create
--name hq
--remote-org-id "id"
--remote-url "url"
--remote-api-token "token"

This returns a remote-id that represents a connection between that specific edge instance of InfluxDB and the instance of InfluxDB Cloud. You can use the same remote connection on multiple buckets in the same edge instance because you’re going to specify those details in the next step.

Specify data

Still working on your edge instance of InfluxDB OSS, you need to identify the source and destination of the data you want to replicate.

influx replication create
--name solar_station_sw1
--remote-id "id"
--local-bucket-id sw1_data
--remote-bucket sw_regional

Because there are multiple solar facilities, we’re naming this connection as solar_station_sw1 because it’s located in the southwest region. We need to enter the remote-id we received when creating the connection in the –remote-id flag. Finally, we’re going to identify the source and destination buckets for our data.

In this case, let’s say all the data from the entire SW1 station goes into a single bucket in the OSS instance, with the bucket-id sw1_data. Because the analysts at HQ collect data from multiple regions around the country, they segment it to keep track of it more easily. There’s a sw_regional bucket in the Cloud instance where we’re sending this data.

Once activated, all the raw data collected by the devices at the SW1 facility automatically replicates to the Cloud. If the connection breaks, the OSS instance continues to collect data and flushes the queue once re-established, reducing the likelihood that we lose any data. (The queue size is configurable.) Once in the cloud, we can leverage the full power of InfluxDB IOx to generate value from our data.

If we want to manage our replications, we can use the following options.

##Management commands
##Display a list of all replications
influx replication list
##Update replication configurations
influx replication update
##Delete a replication
influx replication delete

Optimizing EDR transfers

This setup works well, but it’s also potentially sending a lot of data over the wire. Having all that granular data available at the edge is helpful there, but HQ doesn’t necessarily need that high granularity data. It can get by with a coarser granularity data.

We can utilize downsampling on the OSS InfluxDB instance to maintain the shape of our data, and transfer less data, freeing up throughput bandwidth and saving costs.

InfluxDB OSS continues to support Flux language, and you can use a simple Flux script to aggregate your data.

We can create a new bucket in our InfluxDB instance. Let’s call it sw1_data_ds.

Now we use that bucket as the destination for our downsampling script. Let’s say HQ cares most about total energy produced, expressed in wattage.

from(bucket: "sw1_data")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => (r["_measurement"] == "energy_prod"))
|> filter(fn: (r) => (r["_field"] == "wattage"))
|> aggregateWindow(every: 60s, fn: mean, createEmpty: false)
|> to(bucket: "sw1_data_ds ")


This script takes the data from our original bucket, sw1_data, filters it to include just the wattage value. Then averages that value over a 1-minute interval and writes that aggregation to our new sw1_data_ds bucket.

With that script running, now we have two buckets of data on our OSS instance: one that has all the raw data, and one that only has wattage data, averaged over 1-minute intervals.

HQ needs to create a new bucket in the cloud instance called sw_regional_ds, which is where we’ll send this data.

At this point we can delete the replication for all the raw data and create a new one for our downsampled data.

influx replication create
--name solar_station_sw1_ds
--remote-id "id"
--local-bucket-id "insert-bucket-id"
--remote-bucket sw_regional_ds


Analysis and visualization

Once this data reaches the cloud, users at HQ can use InfluxDB Cloud to run real-time analytics and create visualizations for it. They can use this data to detect issues, schedule their technicians, and even forecast maintenance so that they can perform proactive maintenance in a controlled environment that doesn’t impact end-users or create other disruptions.

Fortunately, because you configure EDR at the edge, it’s very easy to update an existing replication that serves an instance of InfluxDB Cloud running on the TSM engine, to one that’s running on the IOx engine. The goal here is to get your data from the edge to the cloud so that you can derive more value from that data.

So, give EDR a try for your distributed industrial systems and let us know about it. We’d love to hear your story.

About the author

Originally this article was published here and it was written by Jason Myers. He is currently a Content Marketing Manager at InfluxData. He earned a PhD in modern Irish history from Loyola University Chicago. Since then, he has used the writing skills he developed in his academic work to create content for a range of startup and technology companies.

Sponsored by InfluxDB