Good
morning,
everybody.
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.
