Hi,
I'm
Günes Pekmezci
and
my
colleague,
Luis
Furtado.
We
are
working
at
Bundesdruckerei,
and
we
are
both
engineers
in
production
department
for
the
data
team.
Today,
we
would
like
to
present
you
a
method
to
strategically
process
data
from
industrial
processes
before
analysis
and
storage.
I
would
like
to,
first
of
all,
tell
a
little
bit
more
about
our
company.
Bundesdruckerei
is
a
government-
owned
company
that
produces
security
documents
and
digital
solutions.
We
are
getting
bigger
and
bigger
every
day.
Right
now,
we
have
3,500
employees.
We
continue
to
grow.
These
figures
are
from
2021.
In
that
year,
we
also
had
a
sales
margin
of
â¬774
million.
We
have
over
4,200
patents.
Most
profits
we
are
earning
is
coming
from
German
ID
systems,
which
I
will
talk
about
it
a
little
bit
more
in
further
slides.
Then
we
have
also
secure
digitization
solutions
as
a
bigger
profit
bringer
for
us.
If
we
look
at
the
target
markets
and
our
customers,
we
will
see,
like
I
said,
the
official
ID
documents
first.
This
means
that
we
are
physically
and
digitally
producing
official
identity
documents
like
ID
documents,
passports,
resident
permits,
and
this
is
our
biggest
market.
Then
we
also
have
some
security
documents,
which
means
that
we
are
producing
bank
notes,
postage
stamps,
text
stamps,
and
pertinent
security
features
for
the
government.
On
top
of
that,
we
have
a
growing
department
for
eG
overnment.
Here
we
are
creating
solutions
for
the
authorities,
mostly
German
state
authorities,
to
digitalize
their
public
administration
systems.
We
also
have
high
security
solutions.
In
this
department,
we
are
creating
higher
security
required
solutions
for
the
security
authorities
and
organizations.
We
are
also
having
a
target
market
in
the
health
industry.
We
are
creating
products
here
and
also
systems
for
secure
and
trusted
digitalized
health
systems.
Other
than
that,
we
also
are
active
in
the
finance
field.
Here
we
are
creating
products
and
systems
to
control
and
secure
financial
transactions,
both
in
public
and
also
enterprise
sector,
which
also
could
be
taxes,
banks
,
insurance,
et cetera.
If
we
come
to
our
use
cases,
what
we
want
to
share
with
you
today,
we
are
going
to
tell
you
about
a
use
case
that
we
decided
to
implement
for
us,
for
predictive
maintenance.
Like
every
other
company,
our
aim
was
to
create
some
use
cases
for
new
digital
area.
We
thought
about
what
could
be
analyzing
for
big
data,
predictive
maintenance,
and
things
like
that.
We
decided
also
starting
with
our
biggest
document
that
the
German
passport
. This
document
is
very,
very
complex,
and
it
has
a
lifetime
for
10
years.
We
have
a
high
production
rate
also
here,
and
we
decided
to
create
a
predictive
maintenance
use
case
for
a
process
in
this
document.
Our
process
is
punching
process.
It
was
a
good
process
for
us
because
we
have
a
good
understanding
in
this
process
and
also
which
is
very,
very
important
in
industrial
of
things
that
we
had
the
access
to
the
data
that
we
could
analyze
to
create
our
information.
Our
objective
for
this
use
case
was
to
create
a
better
product
quality
by
making
a
predictive
maintenance
for
our
tool
wear
state.
Instead
of
having
the
tool
worn
out
we
react
to
it.
We
decided
to
look
at
the
data
and
create
an
information
that
will
allow
us
to
plan
our
tool
change
time.
We
can
also
minimize
our
downtime,
minimize
our
scrape
rates.
We
could
also
use
this
use
case
in
different
machines,
use
this
as
a
long-term
behavior
of
the
process.
It
was
a
really
good
use
case
for
us
to
start
with.
I
will
give
the
rest
to
Luis
to
explain
you
further
how
we
go
into
this
use
case
and
what
we
did
exactly,
what
were
our
challenges,
and
how
we
find
solutions
for
that.
Thank
you,
guys.
I'm
going
to
present
a
bit
more
about
our
product
and
process.
In
the
case
of
product
that
we
are
analyzing
this
study
is
the
passport.
The
passport,
when
you
think
about
this,
is
a
book.
It's
like
a
sandwich
full
of
pages,
and
those
pages
has
also
a
lot
of
security
features
like
the
picture
that
is
printed,
the
data
that
is
lasered.
There's
also
the
chip,
the
antenna
from
the
chip.
There's
also
h
olography
layers.
There's
several
features
for
security
that
is
inside
of
the
German
passport.
When
you
make
the
sandwich,
there's
a
lot
of
machines
also
to
bring
all
those
features
to
the
product.
When
you
make
the
sandwich,
you
need
to
cut
it
in
the
right
size
according
to
the
norm.
When
you
cut
it,
we
separate
the
finish
book
and
also
the
borders
that
we
don't
need
anymore.
The
point
is
this
cutting
process,
we
use
a
punching
machine
.
This
tool
that
is
installed
at
the
end
of
this
punching
machine,
also
wears
with
the
time,
and
the
quality
of
the
cut
also
starts
to
be
not
very
good
at
the
end
as
it
was
in
the
beginning.
What
we
are
trying
here
in
this
project
is
how
to
make
the
assurance,
what's
the
perfect
time
to
change
the
tool
and
that
with
that
term.
Here's
a
picture
of
the
end
product,
the passport
.
Here
the
borders
that
were
cut.
I'm
going
to
present
a
bit
more
the
tales
of
a
sketch
of
the
machine,
how
that
works,
and
what
was
the
original
idea.
But
first,
we
have
our
original
architecture
of
implementation
of
the
data.
We
have
a
machine
with
several
sensors,
sensor
number
1,
2,
up
to
any
sensors
that
we
need
to
measure.
We
bring
all
the
sensors
to
the
machine
PLC,
that
is
the
controller
of
the
machine,
and
then
you
just
mirror
this
data
to
the
master
computer,
and
you
mirror
this
data
again
to
the
database.
That
was
the
first
original
implementation
that
we
had.
The
database
will
have
a
lot
of
data,
and
then
it
starts
to
make
the
analysis
of
the
machine
and
try
to
understand
what
is
happening
in
the
machine, and
in
this
case,
what
is
happening
in
the
punching
tool
that
is
cutting
the
passport
.
When
you
think
about
the
sketch
of
this
machine,
so
we
have
this
servomotor
that
turns
this
wheel
.
With
the
mechanical
linkage
here,
we
can
move
up
and
down
the
punching
tool
.
At
the
end,
we
have
the
tool,
the
cutting
tool
that
has
exactly
the
end
shape
that
we
need.
This
tool
here,
with
the
time,
we
see
it wearing.
It's
not
that
sharp
anymore,
and
then
we
start
to
have
a
not
good
quality
in
the
product
that
we
are
producing.
Then
you
need
to
change
the
tool
to
make
it
sharp
again.
Good.
How
you
can
be
sure
that
this
tool
is
good
to
cut?
We
measured
the
position
of
the
servomotor,
and
we
measure
also
the
torque
of
the
servomotor,
and
we
bring
all
the
data
from
the
position
and
the
torque
to
the
controller,
then
you
get,
as
I
presented
in
the
previous
slide,
we
mirror
the
data
to
the
master
computer,
and
then
you
mirror
the
data
to
the
database.
In
this
industrial
controller,
it's
not
continuous.
The
curve
is
not
continuous
like
here,
but
it's
discrete.
In
the
end,
you
need
to
think
about
a
measurement
of
every
CPU
cycle
or
the
clock
tick
of
the
CPU.
In
this
case,
we
get
all
this
data
and
it
transferred
to
the
master
computer.
Then
we
make
the
analysis
from
the
database.
But
the
point
is
we
realized
that
using
OPC
UA,
not
all
100
%
of
the
data
comes.
This
is
a
scenario
that
everything
is
fine.
We
have
all
the
points
inside
of
the
server,
inside
of
the
database,
but
sometimes
we
have
missing
areas.
We
have
like a
lacon
that
data
is
not
coming.
We
realized
that
we
have
only
95
%
of
the
data.
5
%
of
this
data
is
lost
when
you
have
a
CPU
cycle
of
100 hours.
Well,
this
loss
could
be
in
the
point
that
we
are
not
measuring
but
could
be
exactly
the
point
when
you
have
the
peak
.
When
you
miss
data
like
here
and
you
miss
data
like
here,
we
compromise
our
measurement
of
the
tool.
Even
with
only
that,
you
have
a
data
loss
of
5
%,
and
then
you
have
not
100
%
of
the
data,
you
have
95
%
of
the
data
coming
to
the
storage,
but
95
%
of
the
data
coming
from
storage
for
all
the
sensors
that
we
have
in
a
machine,
for
all
the
machines
that
you
have
in
the
production
process,
it's
a
lot
of
data.
Then
you
start
to
realize
that
after
a
year,
we
have
a
lot
of
database
storage
amount,
and
this
is
something
that
you
want
to
reduce.
With
this
original
implementation,
we
still
have
that
missing
data,
normally
missing
data
in
the
points
that
we
need
to
measure.
Then
you
had
open
questions
about
this
implementation.
The
first
question
is,
is
that
possible
to
measure
this
tool
in
a
reliable
way
using
the
motor
torque?
The
other
one
is
how
to
reduce
the
amount
of
data
that
you're
sending
to
the
database?
Good.
Then
the
first
idea
that
we
had,
we
decided,
"Okay,
we
won't
check
the
data
from
the
database.
We're
going
to
collect
the
data
directly
on
the
machine
with
a
different
method
that
we
won't
lose
the
data.
100
%
of
the
data
come
to
the
computer
because
you're
measuring
exactly
in
the
machine
controller.
Let's
do
this
experiment
a
lot
of
times
for
different
sets
of
the
machine.
Let's
see
if
the
curve
has
the
same
form
and
if
this
curve
changes
a
bit
in
amplitude
when
you
change
the
scenario
in
the
machine.
At
the
end,
you had
four
scenarios,
and
you're
doing
this
extensively
this
test
in
the
machine,
and
you realize
this
is
the
result
of
this
experiment.
We
tried
old
and
worn
tool,
so
the
tool
was
not
that
sharp
anymore. We
had
a
passport
with
32
pages.
We
have
two
products.
It's
a
passport
with
32
pages
and
the
passport
with
48
pages.
The
client
can
order
quarterly
to,
"Okay,
if
you're
going
to
travel
too
much,
then
order
48
pages."
We
tried
with
old
and
worn
tool,
32
pages.
We
tried
with
old
and
worn
tool
with
48
pages.
Then
we
changed
the
tool
for
a
new
one,
and
we
repeat
this
experiment
with
the
new
and
sharp
tool
for
32
and
new
and
sharp
tool
for
48-
page
product.
This
is
the
result
of
the
curves.
We
realized
that
all
the
curves
has
the
same
shape,
and
this
is
a
superposition
of
a
lot
of
curves
that
we
tried,
and
the
variation
is
very
small.
But
we
can
also
see
that
we
can
see
very
clearly
the
peak
value
for
the
old
two 48
pages
is
a
bit
far
from
the
old
two 32-
page.
Also,
new
tool
,
the
peak
value
is
shorter
because
you
have
less
force
to
cut.
This
is
about
the
torque
in
the
motor.
When
you
have
less
force
to
cut
because
it
was
sharp,
then
you
have
an
even
lower
amount
of
torque.
Good.
With
this,
we
got
some
information.
All
the
scenarios
present
the
same
shape
of
curve.
The
curve
is
in
the
same
shape,
and
we
realize
that
"Okay,
then
I
don't
need
to
record
all
the
curve.
I
can
also
only
record
the
position
of
the
peak."
This
is
what
is
interesting
for
us
for
this
new
implementation
that
we
are
proposing
here.
The
peak
value
could
be
used
for
two
different
things.
The
peak
value
could
be
used
for
the
tool wear
monitoring.
That
is
the
original
idea
that
we
wanted.
Another
thing
that
for
us
is
also
important
is
product
classification.
You
can
also
check
the
quality
of the
product
if
you
are
producing
a
32
or
48
page
is
a
safe
way
to
say
the
product
has
32
or
48
page.
Good.
Then
what
is
the
difference?
The
difference
is
the
implementation
directly
in
the
controller
of
the
machine.
The
whole
sketch
of
this
machine
is
the
same.
Then
you
get
the
data
inside
of
the
controller
in
the
same
way.
But
what
we
made
here
different.
We
preprocessed
the
data,
we
filter,
we
made
a
window
here
.
In
this
window,
we
search
for
the
peak.
When
we
find
the
peak,
we
get
the
peak
of
the
torque
and
in
which
position
of
the
motor
this
peak
happened.
Then
we
just
transfer
one
set
of
data,
not
the
whole
curve
of
the
machine.
How
that
works
in
the
end?
The
original
implementation
that
you
saw,
per
sensor
in
a
machine,
we
had
every
year,
11.7
gigabytes
per
sensor.
That
was
quite
a
lot.
When
you
think
that
we
have
several
hundred,
almost
thousands
of
sensors
in
a
machine,
and
we
have
more
machines
in
our
production
area,
this
is
something
very
critical
for
us.
With
this
proposed
implementation,
we
have
everything
very
similar.
The
sensors
go
to
the
machine.
But
inside
of
the
machine,
we
do
a
preprocessing.
We
filter
just
the
meaningful
information
that
you
need,
and
then
it
transfer
less
data
to
the
master
computer,
and
then
it
transfer
less
data
to
the
database
.
It
made
our
analysis
just
with
this
less
amount
of
data
but
the
meaningful
one.
In
this
case,
it
reduced
more
than
a
hundred
thousand...
No,
a
thousand
times
less.
Now,
it's
8
megabytes
per
year
per
sensor.
This
is
a
good
implementation.
This
was
implemented
in
JMP
and
JMP
Live.
I'm
going
to
give
the
word
back
to
Günes
,
so
she
could
keep
explaining
the
next
steps,
what
we
did
afterwards.
Thank
you,
Luis.
How
we
generated
information
in
JMP
with
this
analysis
is
like
everyone
else.
We
started
analyzing
our
data
in
the
JMP
first,
and
it
was
easy
to
analyze
also
our
huge
data
sets,
like
20
million
data
sets
in
JMP.
But
then
when
we
decided
to
get
just
the
peak
values,
we
were
able
to
create
our
reports
also
very
lighter
and
very
informational.
Then
we
decided,
okay,
when
it's
so
good,
then
we
decided
to
send
our
results
to
the
JMP
Live.
Right
now
in
JMP
Live,
we
have
the
following
reports,
and
it
is
generated
automatically
every
week.
There
is
a
meeting
every
week
for
the
machine
colleagues,
and
they
look
at
this
report
to
decide
when
is
the
time
to
change
the
tool.
Here
you
can
see
different
machines.
We
have
six
machines
of
this
kind.
Then
you
can
see
our
peak
value
for
the
torque,
and
then
you
see
the
development
through
the
weeks.
Here
you
can
also
see
when
we
have
a
tool
change
in
machine
1
and
2,
you
c
ould
automatically
see
next
week
the
values
of
the
peak
starting
again
from
a
lower
point
of
view,
which
Luis
already
explained
why
is
it
happening.
This
is
our
JMP
Live
report
that
we
create
our
planned
change
time
for
the
tool.
If
we
go
to
the
method
that
we
are
proposing...
I
want
to
tell
you
again
how
we
started
going
toward
this use
case.
We
started,
like
every
other
use
case,
first
of
all,
defining
our
project
requirements.
Then
we
took
all
the
data,
like
many
of
the
other
industries
also
trying
to
do
in
industrial
of
things.
We
said,
"Okay,
we
need
all
the
data."
We
tried
to
take
all
the
signals
from
the
machine.
We
analyzed
it
somewhere
different.
Then
we
looked
at
the
data
and
we
said,
"Okay,
is
this
good
enough
for
our
quality
of
the
information?
Does
it
meet
our
project
requirements?"
It
wasn't
meeting
our
project
requirements
because
of
this
missing
data.
With
the
missing
data,
we
weren't
able
to
see
the
right
data
to
have
the
relevant
information.
Then
we
said,
"Okay,
let's
go
to
the
machine
and
understand
the
process
a
little
bit
better.
Why
is
this
happening?
What
can
we
do
about
it?"
Then
we
started
doing
these
experiments
that
Luis
explained
on
the
machine
directly,
and
we
collected
the
data
locally.
Then
we
come
back
to
our
analyze
process,
and
then
we
said,
"Yeah,
now
the
data
is
good,
the
quality
is
good."
Now,
we
also
ask
the
question,
"Okay,
is
this
all
the
relevant
data?
Is
there
a
way
to
reduce
the
storage
without
reducing
the
data
quality?"
Then
we
decided
to
implement
this
preprocessing
algorithm
directly
at
the
machine
to
reduce
the
size
of
the
data.
What
we
are
suggesting
for
you,
too,
is
when
you
start
a
use
case
for
the
production
processes,
after
defining
your
project
requirements,
it
is
better
directly
go
to
the
machine
and
start
doing
experiments
there,
and
then
collect
the
data
locally.
When
you
first
do
this
step,
you
will
spare
yourself
a
lot
of
time
to
create
the
architecture
to
be
able
to
get
all
these
data
somewhere
else.
Also,
you
will
spare
yourself
lots
of
money
because
you
maybe
don't
need
that
much
space
in
your
servers
and
et
cetera.
If
you
start
directly
here,
you
can
go
all
the
other
steps,
and
then
you
will
be
able
to
get
a
result,
a
use
case
that
works
the
best,
and
you
will
have
less
time
for
that.
If
we
summarize
our
lessons
learned
and
benefits
for
the
use
case,
we
can
definitely
say
an
application-oriented
approach
is
very
good
implementing
use
cases
for
production.
You
really
need
a
deep
process
and
machine
understanding
for
the
industrial
of
things
use
cases.
It
will
definitely
will
be
better
for
you
if
you
create
a
team
of
engineers,
people
who
are
working
at
the
machines,
and
also
the
data
people
together,
because
you
need
a
really
deep
understanding
of
what's
happening,
what
you
exactly
need
to
be
able
to
get
a
benefit
out
of
it.
Our
personal
benefits
for
this
specific
use
case
was
to
create
a
method
that
we
can
use
for
other
machines
and
processes,
which
we
are
also
sharing
for
you
today,
and
hoping
that
you
can
also
use
it
for
your
processes.
Then
also
this
method
that
we
created
for
us
was
able
to
use
in
other
machines
and
other
punching
processes
that
other
machines
have.
Also,
we
had
a
really
good
knowledge
at
the
end
of
this
use
case
about
the
tool
wear
state
for
us.
We
could
also
increase
our
downtime
because
instead
of
waiting
for
a
tool
to
be
worn
out,
we
were
able
to
plan
our
downtime.
That
means
automatically
that
we
were
also
decreasing
our
costs.
On
top
of
it,
we
were
also
able
to
use
this
method
and
this
analysis
for
a
long-time
behavior
of
our
tools,
which
also
a
great
thing
because
at
the
end,
we
were
able
to
have
a
predictive
maintenance
use
case.
A
s
a
cherry
on
the
top,
we
were
able
to
reduce
our
data
storage
needs
significantly.
In today's
world
where
we
talk
about
the
energy,
it's
very
important
to
have
just
the
relevant
data
in
our
servers
because
it's
more
sustainable,
it's
more
energy
efficient.
We
were
really
happy
with
our
results,
and
we
are
hoping
also
you
will
get
some
inspiration
out
of
our
method,
and
maybe
you'll
be
able
to
use
it
for
yourselves.
Thank
you
for
your
attention,
and
this
was
our
method.
Have
a
nice
day.
