Meaning of data from IoT sources
If you have ever read Hitchhiker’s Guide to the Galaxy, you would know that “The answer to the ultimate question of life, the universe, and everything is 42.”
When looking at IoT data from a machine, we are often quite pleased to be presented with a value from a sensor, PLC, or some other “important” reading.
But what does the value 42 coming from that sensor mean? Does this meaning change over time? Does the meaning remain the same for all your connected “things”? What happens if another unit of measure is applied because the “thing” is used in another region? What context exists in or around your “thing” when a certain sensor value is reported?
The above are just some of the questions which are relevant when we start talking about the meaning of data from IoT sources. You would be wise to consider what other elements of context might be valuable to your use case and your “things”.
In industrial settings for IoT, we are often presented with an opportunity to connect to PLCs (Programmable Logic Controllers). Using a tool like PTC’s KepServerEX to connect to PLCs is quite easy; the challenge arises when you are trying to understand what the contents of each of the “tags” in the PLC really mean.
If you are very lucky, you may be able to obtain some specification documents that the PLC programmer (often reluctantly) produced. But this is quite a rare find, and you are more often left guessing. Depending on the PLC you use, you may be fortunate enough to have a symbolic name assigned to a tag. This may be something like “belt speed” for a production machine on a line.
What is a reasonable range that you can expect? Might it run in reverse and present a negative value, or would it always present a positive value regardless of the direction? What unit of measure has been used or might it just be a raw digital pulse reading?
PLC programs are there to control the process (or equipment). The PLC needs to deal with important elements like safety (both equipment and humans), and control loops are designed to a functional specification that focuses on these requirements.
It is only of late that we started looking at using external systems to read data from machines. Investigating data from a remote machine requires more context against which we can interpret the values from key variables.
If condition monitoring is a use case you are trying to solve, you may need to add additional sensors to mechanical components. This will also require you to update the PLC program, control system, or data acquisition tools. While you are at this, it may be wise to consider what other internal control variables may be useful for condition monitoring and to expose these variables.
There are many more considerations and I would love to hear what additional context may be useful for your equipment and how that supports your use case.
