This is the sixth workshop in Statistical Analysis and Design of Experiments delivered by Professor Tim Matis at Xfab.
library(qcc)
## Warning: package 'qcc' was built under R version 4.3.3
## Package 'qcc' version 2.7
## Type 'citation("qcc")' for citing this R package in publications.
Today, WE runs rules:
Looking back at the Xbar chart
H0: mu = mu0, the in control average
H1: mu ne mu0, process is out of control
the 3 sigma lines are spec limits, but we have the +/- 2 sigma lines and the +/- 1 sigma lines. So we could use those to estimate where the process is headed. So even in situations where you haven’t actually gone above/below the control limits the WERRs will alert you to the fact that this will happen very soon.
Problem is that you throw away a lot of parts that are actually ok. Even when there is no shift, every 91 lots or measurements I’m going to have a false alarm.
WERR violations are shown in yellow in the Xbar charts generated by R
WERR’s are applied to Shewhart charts. Let’s look at another control chart, cusum chart . This is based in the likelihood ratios. In control is the numerator, Out of control is the denominator.
CUSUM charts have memory. Need two charts, one that looks at increases in the mean, one that looks at decreases in the mean.
We’ll do this in R because it’s messy. Looking at the definitions we can see that the memory comes from the previous measurements. If the process is in control Xbar = mu0, then Zi = 0. If the process is in control there will be a lot of points on the two charts on the axis.
Here’s why we go to the trouble to generate the CUSUM charts:
When the process is restarted we usually start with h/2, provides some memory of being out of control, fast initial response feature. Other features:
It’s not perfect though:
Not perfect:
EWMA => exponentially weighted moving average, another advanced control chart.
Let’s do an example of CUSUM:
Check out the data set with etch rates.
dat<-read.csv("C:/Users/rgale/Downloads/DoEstuff/EtchRateRetroData.csv",header=FALSE)
cusum(dat, size=5,decision.interval=4.77, se.shift=1)
## List of 14
## $ call : language cusum(data = dat, sizes = 5, decision.interval = 4.77, se.shift = 1)
## $ type : chr "cusum"
## $ data.name : chr "dat"
## $ data : num [1:20, 1:5] 4.8 5.6 4.4 4.9 5.8 4.3 4.2 4.2 4.2 4.8 ...
## ..- attr(*, "dimnames")=List of 2
## $ statistics : Named num [1:20] 4.76 4.56 4.68 4.82 4.92 4.46 4.32 4.58 4.58 4.54 ...
## ..- attr(*, "names")= chr [1:20] "1" "2" "3" "4" ...
## $ sizes : num [1:20] 5 5 5 5 5 5 5 5 5 5 ...
## $ center : num 4.52
## $ std.dev : num 0.58
## $ pos : num [1:20] 0.4323 0.0942 0.2183 0.8818 1.9306 ...
## $ neg : num [1:20] 0 0 0 0 0 ...
## $ head.start : num 0
## $ decision.interval: num 4.77
## $ se.shift : num 1
## $ violations :List of 2
## - attr(*, "class")= chr "cusum.qcc"
Math for CUSUM is tedious but in R is a piece of cake.
Not everyone agrees on this, but it is a way for customers and suppliers to talk. Biggest problem is that we don’t know apriori that the output of the process is normall distributed. Get lots of data to verify. First, Cp:
So, Cp tells us if the variability in the factory is reasonable with respect to the variability the customer will accept. It does not talk about centering the process where the customer wants it. We need Cpk for that:
This ensures that we’re close to being centered where the customer wants. Doesn’t consider the fact that the target might not be in the middle of the spec liimits. Need Cpm for that:
Example:
Data is good, set plot = TRUE and use spec limits of 45,55 as below.
newdat<-read.csv("C:/Users/rgale/Downloads/DoEstuff/ProcessCapabilityFA.csv",header=TRUE)
q1=qcc(newdat,type="xbar",nsigmas=3,plot=TRUE)#create object
process.capability(q1, spec.limits=c(45,55))
##
## Process Capability Analysis
##
## Call:
## process.capability(object = q1, spec.limits = c(45, 55))
##
## Number of obs = 100 Target = 50
## Center = 48.04 LSL = 45
## StdDev = 1.006 USL = 55
##
## Capability indices:
##
## Value 2.5% 97.5%
## Cp 1.6563 1.4258 1.8865
## Cp_l 1.0070 0.8771 1.1368
## Cp_u 2.3057 2.0306 2.5807
## Cp_k 1.0070 0.8523 1.1617
## Cpm 0.7564 0.6164 0.8962
##
## Exp<LSL 0.13% Obs<LSL 0%
## Exp>USL 0% Obs>USL 0%
Not too bad, but nice match of process capability and spec limits, but mean is way off target so Cpk and Cpm are not very good.
None of them are perfect. For that….
These confidence intervals assume the data are normally distributed. So, more data, verify normality. Looking at the histogram we might be safe assuming normality.
There was a long discussion of what would be the requirements on Cp, Cpk, and Cpm for a given defect level, say 1 ppm.