Identifying Parameters Drift into Nonconformance

[#1]

Hi community,

I have a data of power which is increasing with the run number until it crushes.

What should be a good statistical way to identify it some runs before it crushes in order to avoid the crush with fixing it on time?

attached, sample of data.

BR,

Yoav

[#2]

Hi, Yoav!

There are probably a very large finite number of "good statistical ways" to signal runs in data.

One way is to use Nelson rules in the Analyze pulldown, >Quality and Process>Legacy Control Charts>Levey Jennings.  After casting the variables into their roles and clicking OK, a control chart is made.  Under the little inverted red triangle (LIRT), choose Tests>All Tests.  You get something that looks like this:

I demonstrated all the rules, but you could use whatever rules you deem appropriate to detect specifically what you wish. Enclosed are a couple of reference articles from Lloyd Nelson that details the rules and their justifications.

Of course, you could even make your own rules, should you so desire, and implement them with JSL.  And, like I mentioned earlier, there are many other tests for runs in data.  Choose one that reliably detects what you wish.

Good luck!

[#3]

Dear @YGerchman , as we can see in the SPC chart of @Kevin_Anderson the power always increases before crush. You can find a rule to detect the crush before it happens. I could not get any reasonable result with the SPC rules that are in the platform, but you can also calculate an upper limit to reach before the crush happens, and use that to fix the power before the crush happens. See example in screenshot.

• I first deleted the 0 power rows (because you do not know them before it crushes)
• then I made a column formula to calculate the mean and stddev of the power in that phase
• then I compare it to the current value
• When current value > (mean(power) + 2 x stddev(power)), it is just before the crash

This works for the current data, it may need much more data, to show if this rule is reliable.

Also all depends on costs of having a crushed run, and costs for fixing the problem before.

BR

[#4]

Hi @YGerchman ,

  In addition to what both @Kevin_Anderson and @Georg have provided, I would add the following:

  Another option is if you have additional data that goes along with the power, you can use the model driven multivariate control charts platform (under Analyze > Quality and Process). This platform reduces the multidimensional data (assuming you have other process parameters that are recorded along with the power) using PCA and reports back the T^2 value and by looking at the outliers, you can find out what part of your process was going out of control. This is often helpful in circumstances where there are many process parameters like speed, temp, mixing rate, power, etc. that are all part of the process. Sometimes, it can be that the temp changes, resulting in a larger current draw, thereby changing the power, so depending on the situation, it could be that it's a mixture of factors, and the MDMVCC platform is very helpful for that.

  Considering that the failure tends to happen as the batch number goes up, that would suggest something is going on during the process that is changing with time. You can see that right before failure, the power goes up before the crash for both phases, so if you have data from additional processing inputs, this might help to catch a latent factor that is the root cause of failure. Also, there is a big change in power outputs between phase 1 and 2. Did settings change or did the failure from phase 1 impact the power during phase 2?

  Bringing in more data might help to determine the cause.

Good luck!,

DS

[#5]

thanks for your detailed answer. regard to the last question - the second phase got it setup fingerprint and isn't affected by phase1 crash. it could be also higher than the first phase.
the data is a simplified example to what I really managed with. in fact - we got thousands rows of data and as I explained before - I am searching for some test that could warning to the engineers some processes before the tool fail. i am sure it can be done because it can see from run chart also with naked eyes.

[#6 · Accepted solution]

Hi @YGerchman ,

  Do you also have many columns of different data sources: e.g. tool speed, or tool temp, or something? The thousands of rows is good, but also having other data to bring into the analysis might help. To me, it really sounds like there is a latent factor that is the root cause of the failure and not necessarily the power itself, more like something else is going out of control that ultimately causes the power to spike and the tool to crash.

  One thing you could do is consider a moving average of the last three or five measurements and estimate where the last reading is before a crash and find the relative change in power -- let's say that if the power starts increasing by more than 20% of the set point, this indicates the tool is headed to failure. Since the average setting in phase 2 is lower than in phase 1 and it still fails, it seems like it's more a relative change in power to the set point rather than an absolute change.

  But again, if you can bring in other data and look at any correlations or similar spikes/drops at a crash point, this might help to find a latent factor.

  I'm interested to hear what you find.

Good luck!,

DS

[#7]

Hi DS,

It's looks like moving average of last 5 points can give me quite good warning. I still have to find the exact changing set point for alerting but it seems that this is a good way. unfortunately, I cant share online much detailed data. 

another option which I believe that can be done is finding the "trend-force" with moving average and looking for strong trend breakage (strong change, increasing, of the trend)

Best regards,

Yoav