Webinar Highlights: How Olympus Controls Automates Predictive Maintenance with Telit, MQTT, and InfluxDB

By Bria Jones / Product, Use Cases
Aug 12, 2022

Unplanned outages are problematic for any organization, and can be especially costly for manufacturers when they involve parts that have a long lead time. In this webinar, Nick Armenta – Automation Engineer at Olympic Controls, shares how InfluxDB provides insights into when parts may fail to help predict the maintenance windows for their robots. Focused on robot joints and monitoring the “current,” which is essentially the force of the motor, Nick shares details of his experience using the purpose-built time series platform.

Webinar highlights

Olympus Controls overview

Olympus Controls is a hardware distribution company that primarily sells robotics and motion control technologies, but their ultimate goal is to be an engineering partner to their customers. Driven to find the root cause of a problem, Olympus Controls implements technologies and devices that can connect to a platform, such as InfluxDB, for remote IoT sensor monitoring.

Machine KPIs

In manufacturing, it is all about improving machinery uptime. By collecting and analyzing sensor metrics about machines and production, organizations want to enable better predictive maintenance of their costly machines. When successful, operations costs are reduced and machine uptime increases. Rates are critically important to establish the overall health of production lines and for Olympus Controls, they use InfluxDB to collect robot and machine health data. By using a time series platform, they have been able to automate the monitoring of industrial manufacturing plants and factories. The machines used in factories run for years, sometimes decades, so understanding when they will need maintenance is necessary.

Telit + MQTT + Telegraf + InfluxDB

Robotiq Palletizer is a solution Olympus Controls created to automatically stack products onto a pallet. Each robot has joints, similar to our wrists, and each of those joints has a motor. Nick is monitoring motor health using InfluxDB to help predict when maintenance may be needed. Robot data is obtained using a simple IO device with Telit DeviceWISE edge platform installed onto it. This gateway allows communication with any device regardless of their preferred protocol and offers built-in communication protocols such as Modbus, TCP and MQTT. This is helpful since Olympus Controls may not know which gateway their customers are using. From there, the MQTT broker publishes specific topics that robots in other locations can subscribe to provide what Olympus Controls calls “load balancing” of your automation. By using the MQTT Consumer Telegraf plugin, Nick is able to collect data from the broker and pull it into InfluxDB.

Since Nick wasn’t much of a “database guy,” he enjoyed the quick querying capabilities which allowed him to query and visualize his data. Utilizing custom dashboards is essential to manufacturing, as it makes identifying problems – and solving them, much quicker. To demonstrate an error in real time, Nick playfully interrupted the robot by “punching” it and the error can be seen in the dashboard in real time. This webinar focused on one specific robot but because scalability is easy with InfluxDB, Nick can include multiple robots and easily visualize their data to help get ahead of any costly maintenance issues for his customers.

Why InfluxDB?

Nick had very little database experience before InfluxDB and didn’t quite know where to start, but once he realized how easy data collection was with Telegraf and InfluxDB, it made the most sense. The quick querying with minimal effort on his part was a key factor as well. He also loves a good visualization tool and since the visualization component is already built into InfluxDB, it made it easy to start viewing his data.

(If you are also new to InfluxDB, check out InfluxDB University — there are free on-demand and instructor-led courses.)

Q&A

During the webinar, audience members had some thoughtful questions for Nick — here are a few of them.

Question: Is it necessary to use a separate MQTT broker somewhere for InfluxDB to collect data? What is the role of Telegraf in the schema?

Answer: We actually did some other implementations where we did not need MQTT, because we had a small local development environment and so we could send it to a local database. Once we started to go to more of an enterprise type of deployment, that’s where it made more sense, because now we need to go to a cloud instance, so we couldn’t keep that localized anymore. So that’s where the MQTT broker stepped in. But you’re absolutely right about just MQTT and the protocols. It’s not necessarily what we needed. It just made the most sense in this standpoint, because really in manufacturing, it’s all about simplicity. We did have a broker running locally, using Mosquitto, and a Docker container, as well. So it doesn’t have to be that specific endpoint. But MQTT was simple and safe to communicate, which is why I chose it in this instance. But by no means the only way.

Question: Did you face any pushback in your organization? How did you overcome that?

Answer: Yes, the number one complaint I get in factories is that they don’t have enough people. So generally people are stressed. They’ve got tunnel vision. So really pulling them back to that 10,000 foot view and saying, “Hey, if you look right here, this is a serious pain point. If we can address this, we can alleviate your stress.” And to eliminate those pain points, we need to pull data that allows us to show them where they could be most productive. So it’s really just pulling them back for a little bit, talking them off the ledge, and saying, “Let’s look at this area first.” And from there, we can start generating more traction and more productivity.

Question: Are you considering a machine learning approach, for example, using neural networks, classification algorithms, or something to predict specific events and trying to learn something from available data?

Answer: The number one problem I’ve seen is really just a lack of data availability. So step one, get a good pool of clean, formatted data. Once your data is clean, formatted, and visualized in an understandable way, you can actually make quick judgment calls and understand just by looking at a good, visualized interface. There’s a bunch of different data streams and it’s a very complex type of scenario. But when it comes to things like preventative maintenance or any kind of productivity metrics, those are pretty basic, discrete type signals we can usually look for.

Question: How do you manage loss of connection to the MQTT broker? Is there an MQTT client or other agent buffering data locally in the factory?

Answer: There are actually a couple of different ways to manage the loss of connection. MQTT comes with quality of service (QoS) levels to guarantee the delivery of a specific message. Level 0 is basically similar to UDP (versus TCP), where you send a message and you don’t care what happened. That is the default setting in the protocol. Level 1 sends back an acknowledgment, and Level 2 provides a 4-part handshake which is slower but guarantees message delivery.

There were many more interesting questions! If you’re interested in watching the full webinar to hear the rest of the Q&A, check it out here! Find the presentation here.