Recent advancements in digital tools allow us to dig into the vast amounts of data we have available and reveal patterns we weren’t able to detect earlier. We are able to build richer analytics and create digital solutions enabling us to monitor and predict future states of our equipment, and thus improve our uptime and reduce costs. However, how many sensors do you need to get started with machine learning?
WHAT’S A SENSOR?
First of all, sensors are the foundation of the industrial internet of things (IIoT). Sensors are used to either detect or measure some input from the physical environment and convert it into desired output. IIoT sensors are smart and have the ability to communicate with other sensors and connected devices. There are hundreds of sensors available for all sorts of industrial assets. Sensors are usually very specific and the sensor data gathered range from:
- distance, etc.
Finding the right sensors to monitor your most critical assets will provide you with a wealth of data.
EDGE ANALYTICS, EDGE COMPUTING, AND INDUSTRY EXPERTISE
Even though you’ve connected sensors to your equipment, this doesn’t necessarily mean you’re gathering lots of data. You need to be able to access and analyze this data, even in remote locations. As mentioned in earlier blogs, this is where edge analytics and edge computing comes in. You can learn more about this in our whitepaper about edge analytics:
Moreover, regardless of the IIoT solutions and data you’re able to gather, you still need deep insights into your processes and industry too. Enabling the decision-makers to make good decisions requires a complex orchestration of continuous analysis of sensor data from one or more physical assets combined with other types of historical or real-time data and domain expertise. Your operators need clear insights into what actions to take, and why.
HOW MANY SENSORS DO YOU NEED?
I’m guessing you read this post in hopes to learn the exact number of sensors you need. Unfortunately, I’m not able to give you that answer because it depends.
WHAT BUSINESS PROBLEM ARE YOU TRYING TO SOLVE?
It depends on the business problem(s) you’re trying to solve.
Do you want to
- reduce downtime?
- improve performance?
- detect failure?
- predict failure?
But this isn’t enough. You need to dig deeper than that. For instance, when you say, predict failures, what do you mean? Do you mean you want to know when that failure occurs? Do you want to know what specific failure is happening? Do you want to know if it's about to happen? Do you want to know which component it’s happening on?
Decide on the actual business problem you want solved and what value you want out of it. Do you want to remove existing pains by automating manual processes of for instance detecting what’s normal or not? Thus reducing the time to do this? Or do you want to put in place a system of comprehensive models to reflect all your equipment’ components and have a “digital engineer” monitor your equipment?
TRANSLATE YOUR BUSINESS PROBLEM INTO A TECHNICAL PROBLEM
When you know which business problems to solve, you need to translate each one back into a technical problem. You need to translate it into something that you can actually implement and execute. Once you have a technical problem, you can start investigating the technical requirements, one of them being data. What’s the minimal data set you need to solve or help solve the problem?
Here are some examples to consider:
In some cases, where the problem is very specific you might just need one KPI or one condition monitoring model taking in 2 signals. A simple example of this can be automating what the engineer is doing when a crane has failed. He’ll get a service report and ask for more data, for instance two pressure signals. He’ll start looking for patterns. If he can visualize that the signals were misaligned or that they started to deviate from each other where they shouldn’t - is this why the crane failed? If that’s true, we could automate what he’s doing using these two signals.
In a more extreme and complex example of anomaly detection on compressors, you could have 100 sensors and you want to be notified about any suspicious behavior. You’re not looking for anything in particular like in the first case. You're looking for anything that looks out of the ordinary. Here you’d use all the available information and given that you know what “normal” behavior is, you’d use that to train the algorithms to detect what isn’t.
Start off with the business problem you need solved. Moreover, it’s important to get started with projects that are feasible today using the systems of record and data sets that can be accessed easily. Capture a few quick wins to build value, competency, and momentum before you take on more ambitious digital initiatives.