In case Predictive Analytics fails, revisit the way you define the faults .

In case Predictive Analytics fails, revisit the way you define the faults .

Lately, manufacturing industries (and other industries) are actively capitalizing on Predictive Analytics to their benefits, to avoid unplanned events, to serve their customers better and in decision making.

Predictive Analytics is the process of using data to forecast future outcomes. The process uses the data, machine learning, artificial intelligence, and statistical models to find patterns in the data that predict future behavior. Predictive Analytics (PA) is expected to foretell the likely future events such as failures/fault/fraud/leaks etc., in the system or a subsystem. This way, PA helps to uncover risks and future opportunities. For example, in manufacturing, Predictive Analytics is widely used to forecast time to failure (Remaining Useful Life (RUL)) of a component/part to know state of health of the system.

Figure 1. Remaining Useful Life

In-depth business understanding and accurate definition of the faults that the PA is expected to predict is critical to build a robust Predictive Analytics(PA) solution. Many times faults that we want to predict through PA face the risk of inaccurate definition due to different reasons. For instance they are — shortage of experienced experts interacting with the team, human stress, lack of time, poor communications, etc. Also, some faults are the domino effects of other faults, articulating the root cause and dependencies of the fault is an uphill task for the subject matter experts.

PA building requires different supporting artifacts and documents to articulate the business requirements. There are several different ways to represent faults and the lifecycle of a fault in predictive maintenance, depending on the specific equipment or systems being monitored and the types of problems that are most likely to occur. Common ways used by the subject matter experts are control charts, Fault Tree Analysis and Failure modes and effects analysis (FMEA).

Figure 2. Control Charts and Fault Tree Analysis

Another representation that is used is a UML- state transition diagrams which is a graphical representation that shows the different states that equipment or systems can be in and the transitions between them. This can help to identify the different stages of a fault, from initial detection to failure. State transition diagrams are also called as state machine diagrams.

Every system has a life cycle of its own. Understanding and listing different states that the system goes through in its lifetime, is crucial. Describing transitions between those states helps to gain deeper insights on the behaviour of the system. Figure 3 depicts a typical Lifecycle of a System, where blocks represent different states and the edges connecting to the blocks are the possible transitions. Different states of a typical system depicted in figure 3 are — Initialize, Ok/No Fail, Fail, Recovering and Recovered. Transitions are annotated with the conditions to be met for the system to get into the next state and the list of affected attributes due to such a transition. Also, every state may have its own attributes. The system transitions between different states with the progress of time.

Figure 3. State Transition Diagram

Further, from the above mentioned state transition diagram, we can define faults in terms of sequence of states that the system goes through when it occurs. For example-

Fault definition1: In system A — a fault can be defined as 1st occurrence of the fail post initialisation of the system. The sequence of states used to represent such a Fault = {Initialize, Running,Fail, Recovered, Running}

Fault definition2: In system B — a fault can be defined as consecutive 3 fails in 24 hours, post initialisation of the system. Fault= {Initialize, Running,Fail ,Fail, Fail, Recovering, Recovered, Running} % in 24 hours%

Fault definition3: In system C— a fault can be defined as 3 fails in 6 months duration. Fault= {Initialize, Running,Fail, Recovering, Recovered, Running … Fail, …, Fail} % in 6 months %.

and so on. Such many realistic definitions can be represented based on the defined different states of the system. Such a systematic pictorial representation in terms of state transition diagram, provides you the unseen perspective of a) System state transitions when fault occurs, b) latent details such as attributes affected and conditions under which fault occurs and c) better articulation of the fault.

State transition diagrams are very close to Marcov chains (aka Marcov Process). Marcov chains are mathematical systems that hop from one state to another, and are used to statistically model random processes and represent statistical models of machine learning. State transition diagrams are widely used in the Computer Science domain and in the other domains too. Also, such fault definitions help in ingest the required data and analyse the patterns of the faults. Further, it can guide us to choose the machine learning (ML) algorithms and deep learning (DL) architectures as they are nothing but patterns and sequences.

Conclusion:

A typical data sciences and machine learning project team consists of data science specialists, data engineering specialists and domain specialists. Data scientists and data engineers who are from outside the business domain, are guided by the domain specialists — Subject matter experts(SME) to articulate the business requirements and business knowledge required to build the data science solutions. In collaboration, the team defines business hypotheses, assumptions, business attributes and data resources to build the expected data science solutions.

Different representations to depict faults of the system help non business domain team members to understand the system and faults better. As the application of ML and DL are maturing in many domains such an additional information depicting faults would help to build robust predictive analytics models and lessen the rework due to unclear goals.

References:

[1] Jeble, S., Kumari, S. and Patil, Y., 2016. Role of big data and predictive analytics. International Journal of Automation and Logistics, 2(4), pp.307–331.

[2] Eckerson, W.W., 2007. Predictive analytics. Extending the Value of Your Data Warehousing Investment. TDWI Best Practices Report, 1, pp.1–3.

[3] Wang, Y., Zhao, Y. and Addepalli, S., 2020. Remaining useful life prediction using deep learning approaches: A review. Procedia manufacturing, 49, pp.81–88.

[4]http://projanco.com/Library/Systems%20Analysis%20and%20Design-An%20Object-Oriented%20Approach%20with%20UML-2015.pdf

[5] https://brilliant.org/wiki/markov-chains/