Identifying failure signatures of machines and modeling them to predict problems well before failure occur has been of great interest to reliability and maintenance engineers, primarily because of the unparalleled advantages like improved equipment up-time, lower maintenance cost, and reduced safety risk. Production critical machinery often requires intelligent real time monitoring and an unplanned interruption can have high cost implications. To address this, we utilize the on-board sensor data and develop a near-real time prediction system to identify anomalies and failure patterns of assets. Development of such data driven system will help improve reliability engineering strategies by modeling system dynamics and predicting equipment health problems.
one question regarding your system, could you please remark on capabilities of the system to adapt to changed system states and still deliver meaningful results? I think of situations where some damage has occurred that changes system response patterns, but usage continues and needs to be accompanied by correct feedback from the sensor system - correct for the new system state, too.
Does your system encompass such capabilities, or if not, which possibilities do you see to implement them?
Kind regards,
Dirk Lehmhus
Thanks for taking out time to go through our work.
First of all, adaptability in our system comes from the fact that it is an incremental training process and the state transition matrix is updated on every pass.
In order to explain this -
Lets say something goes wrong.First thing we will notice is - Singular values in that time window will change. Now, depending on the f-norm threshold we set,either merging to existing state ( if f-norm is less than threshold it is considered similar to one of the preoccured states) or addition to training set as a new state will take place. Effectiveness of this algorithm really depends on variety of factors including how much training data is available(the more the better), how many failure patterns, signatures or states have been observed in that available training data.
You may point out, what if, while working with live data stream, a different state was observed and it just got added to the system and it happens to be a failed state or a problematic state, a failure which hasn't been observed before. Two things could be done at this stage, every time a new state is added, we can flag that as anomaly and ask for feedback from the user and mark it as a failed or normal state based on the feedback received or have an integration with Maintenance repository and keep checking it on every pass, if found failed, state will be marked as failed and will be accounted for next time it happens.
Regards,
Gurpreet
