My name is Chris Jackson.
I am an Applications Engineer for Centrotherm.
We design and build point-of-use gas abatement systems
for use in the semiconductor and other industries.
Today, I have the opportunity to give a short presentation
on how we found a space for JMP in our part of the industry
and how it helps us both in troubleshooting
for industrial applications
as well as for assessment
and justification of continuous improvement initiatives,
engineering changes, things like that.
A little bit of background just to get everyone on the same page,
I want to say a couple of words about what point-of-use abatement systems are.
I've got a little cutaway of one of our tools here on the side.
The short version is this:
you've got a manufacturing tool up on the factory floor
doing whatever it's doing in the semiconductor manufacturing process
that produces harmful gasses as a byproduct,
greenhouse gasses, toxic gasses, flammable gasses.
Generally, things you don't want to go in the atmosphere.
Then our tools take those waste gasses in,
they destroy them through thermal energy,
they wash them out,
and you release clean air to the factory exhaust.
Because these tools are safety and environme nt-critical,
a fault in one of them
means that your production line is at least in part shut down.
If you can't treat your byproducts, then you can't run.
In a high- volume manufacturing environment,
as so many semiconductor FABs are,
even small delays are incredibly costly.
We as suppliers and servicers,
have to have a means to quickly identify problems
and bring the tools back online.
Historically, troubleshooting usually means
opening the tool,
looking visually to identify failing components
often after some period of root cause analysis.
But with a modern FAB environment
and the data generated by SCADA or IoT systems,
we have mountains of data available to investigate faults
before we ever touch the equipment.
That gives us a way to guide troubleshooting in the field,
and in some cases for intermittent faults,
it even lets the factory keep running while we investigate digitally
rather than physically
minimizing the time lost to troubleshooting and investigation.
The problem with this mountain of data is a scale issue.
The higher the resolution of your data,
the better look you can get at what's happening instantaneously
in any of these pieces of equipment.
That higher resolution however, comes with an overhead.
You need more and more computing resources to effectively analyze it,
and that's where JMP comes in for us
with the capacity to handle very large data sets,
and it becomes a tool for visualization and exploration
that can really drastically improve troubleshooting.
It lets an engineer or a technician
quickly explore and visualize important parameters
within your data sets,
and these data sets are at a scale sometimes that are just unmanageable
for a lot of other visualization tools.
With that, I want to jump right into the first example case we have here,
and we're going to identify an intermittent single- component failure
just through data visualization.
No statistics, no modeling,
just the ability to sift through and visualize the data.
Here we've got a chart showing ionization current versus time.
It's one of a number of parameters, ionization current,
that we use as a health monitor for the equipment.
This tool was having issues in which it would run for a couple of days
and then seemingly randomly fail and shut down.
For context, this current should be a flat horizontal line at 25.5,
so it's pretty clear from the outset that we have a problem.
It's also pretty clear what I was talking about
regarding data set size.
This data set right here is almost six and a half million rows.
Six and a half million rows with,
when you pull in all of the tool parameters,
500 columns.
The file for this data set is about 20 gigabytes in size,
absolutely massive amounts of data.
Before we even do any statistical analysis, like I said,
we can start to do some problem- solving off of this data set
just with visualization.
Initially, it doesn't really look like there's any clear shape to this data.
We know something's wrong, but we don't know what.
But when we zoom in,
all of a sudden we start to see some structure.
This looks pretty periodic to me.
We zoom in a little bit more
and we see that it is in fact very periodic.
Each one of these little spikes down, disregarding magnitude,
is timed five minutes almost exactly from each other.
That immediately begs the question then, do we have some component,
a valve, a flow controller, a motor,
something that actuates every five minutes?
We identify that component.
Now we have a really likely troubleshooting culprit.
The troubleshooting plan changes from open the tool and investigate,
which could take a couple of hours,
to open the tool and change this one targeted component.
We just shrunk the actual time that we need to be in the equipment
from a couple of hours looking at everything
to see what might be failing
to a single hour, get in there, change this part, get back out.
In this particular case, that was the failing component,
we were able to identify it.
Problem identified, plan made without ever having to open the equipment.
We were able to get there with just the conclusions
that we were able to draw from visualization.
Of course, JMP is not just a tool for visualization.
It also has at its core a very robust suite of statistical analysis platforms.
If we start to apply those to the data,
we can get even more exciting and interesting results.
I'll just jump right into the second case here.
In this case,
we're looking at a specific tool, which is working fine most of the time,
but it does have occasional problems with buildup,
sometimes we got to draw our PM in a little earlier than we would like.
We want to take a look at our health parameters
and see if there's any abnormalities, any optimizations we can make.
The approach that I use here
is applicable for, really, any industrial application
that has defined operating modes.
Because we can draw those modes out of the data very easily
using clustering.
In this case, our abatement has, or this specific abatement,
has three pretty well- defined operating modes
based off of these two input gasses.
I use K Means clustering.
You could use whichever version of clustering you prefer.
But I run that over the data to sort a ll of our rows, all of our points
into these three operating modes.
If you have more than three operating modes,
obviously, you can use more clusters.
But it also gets interesting,
what if you don't know how many modes you have?
Maybe they're customer-defined,
or maybe there's a suspicion that,
"Hey, could there be some interstitial mode here?"
Maybe the transition state between two of these operating modes.
If you want to investigate that way, you can use iterative clustering.
I did that down here.
You just run from, I used 3- 10 clusters,
and the software will identify what the optimal number of clusters is.
Looking at this, it is correctly identified.
It gives us these cubic clustering coefficients,
identifies the optimal one,
that, yes, as suspected, three is the optimal number of clusters
to sort this data into.
I'm not really worried about these state transitions.
I'm really more focused on the states themselves.
We take that data, we get a readout of it,
and we throw it up onto this 3D scatter plot.
We take some of our tool health parameters,
and we color everything by what cluster they're in.
Immediately, we start to see some interesting results.
We talked about ionization current should be solid at 25.5,
and we see that we have some variability here.
It's dropping below that.
Immediately we know that we have a problem.
But what's more interesting is that every single one of those points
is grouped into a single cluster,
cluster two, which corresponds to this
lowest input gas one, highest input gas two.
Now from an engineering perspective,
if I'm looking to make optimizations or I'm looking to improve tool health,
I immediately can say,
"Hey, this is the operating mode that we need to look at."
That's what I need
in order to start looking at concrete next steps for improvement.
I'm not looking at the tool as a whole.
I've already managed to focus my search to one operating mode.
The last thing I want to talk about then,
having looked at two of these use cases here is,
what are the other advantages with JMP?
Why JMP?
My customers are collecting all this data.
They have ways to view it.
They have scatter systems and monitoring systems in place.
They have ways to parse it.
So why do I, as a supplier/ servicer,
need this platform to view and parse the data?
The answer for me, at least in my case, is the cross- platform compatibility.
If I'm reliant on my customer to chart and generate data views for me,
I'm now taking up their time and their resources
to troubleshoot a problem that I'm responsible for fixing.
With JMP, as long as they can give me the raw data,
I can do all of it myself.
Not only is that freeing up their sources,
it gives me the ability to do my own investigation
independent of whatever system they're using for data analysis.
It doesn't matter if they're using proprietary monitoring system A or B or C,
or if they're using their own IoT monitoring system
from their control engineers.
It doesn't even matter
if they have multiple data acquisition systems
from different vendors.
With JMP,
I can import and manipulate whatever data they give me
and perform these kinds of analysis, sour ce-independent,
do the investigation that I need to do for my customer support
with all the tools for visualization and statistical analysis
that JMP provides.
With that, it looks like we're pretty much at time here.
I know this isn't the traditional use case necessarily for JMP
from some of the folks that I've talked to,
but I hope it was helpful for people.
I'd just like to thank Adam Stover, our CTO,
and Gordon Tendik, our Director of Apps and Technology,
for helping me put all this together and reviewing the work that I've done.
Thank you for your time.
