An IoT solution hinges around the parameters as the parameters make up for the data used for analytics. Moreover, deciding on which parameters are required to be logged also depends on the deliverables to the client. The final deliverable to the client is the major influencer for selecting which parameter and their logging intervals.
A continuously changing parameter will require logging at minimum interval while the constant parameter can be logged with substantial intervals. The logging intervals make for the packet data and unnecessary logging can consume more data and storage space on the server, but again care needs to be taken to ensure no data is lost owing to high logging intervals. Hence the need for judicious decision on deciding the logging intervals of each parameter in the IoT solution.
Once the client gives the go ahead on the availability of the parameter on either the PLC or the sensor, then the logging interval can be calculated and logic can be applied for the analytics. It is imperative to get it right, else the analytics output will be wrong and the value for the client will be lost. We encountered one such scenario where the analytics was required to calculate the water delivered by a pump every minute.
The logic was defined and the parameter was captured as “PUMP ON” from the client’s PLC. The logic was set to capturing the log to check if the pump was on at a logging interval of a minute. But due to a goof up in the logic, the data captured reflected that the pump was on for only a second for every minute. Once enough data was populated and the analytics was checked, the results were shocking! The output mentioned in the analytics not even close to the system specifications.
This was followed by an active investigation of the problem which led to the discovery of a huge misinterpretation of the data due to the logic setting where instead of considering the pump to be on for the entire minute, the pump was deemed to be on for only the second when the logging occurred. This led to a horde of wrong calculations of all the dependant parameters and led to an incorrect analysis for the client. Further, the corrective measure was conducted and the system since has been functioning as expected.
One thing to be noted here is that the issue might have never occurred if minimum logging interval was applied. But that might have resulted in increased data costs and unnecessary server load. In order to save data and server space, this technique was applied. Furthermore, with the new data logger, a new LOG ON CHANGE functionality has been added which ensures such situations do not arise. This ensures each relevant parameter can be captured more efficiently, thus saving data costs and server space.
After all, the client derivables is what defines which parameters need logging and their intervals. Understanding the need of the clients and delivering what they need is what makes a good IoT solution and for the best end-to-end IIoT solutions, get in touch with EcoAxis.