►
From YouTube: Kubernetes running Manufacturing systems. A perfect match? - Moritz Kröger, RWTH Chair for Lasertech
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes running Manufacturing systems. A perfect match? - Moritz Kröger, RWTH Chair for Lasertechnology
The demand of modern manufacturing machines for better quality inspection and condition monitoring has lead to an increase of sensors and cameras in these systems. Especially in the area of Laser-based manufacturing where a typical machine can produce up to multiple Gigabytes of data per second single manufacturing computers are simply not powerful enough to handle this kind of workload. A research team of the RWTH Chair for Laser technology is currently building a distributed Kubernetes based control system for Laser manufacturing machines. This system not only aggregates the generated data and controls the machine in a distributed environment, but also allows the dynamic injection of data analytics at the edge. This talk gives an overview of the current state of the systems as well as the pros and cons of working with Kubernetes to control manufacturing machines.
A
A
A
The
idea
of
the
of
the
internet
of
production
is
the
idea
of
the
creation
of
digital
shadows,
so
the
main
vision
here
is
that
you
have
the
virtual
world
and
the
physical
world
down
here.
So
you
have,
for
example,
the
development
phase
of
a
product
where
you
draw
something
or
where
you
plan
how
to
produce
something
or
you
plan,
for
example,
a
factory
and
normally
use
tools
for
that,
and
these
tools
produce
data
and
then
the
the
product
you
want
to
produce
goes
into
production.
A
At
the
moment,
the
internet
of
production
focuses
on
the
following
infrastructure
map.
It
looks
a
little
bit
scary,
but
let
me
explain
really
quick.
We
have
our
data
infrastructure
down
here.
So
basically,
all
of
our
product
data
cut
data,
simulation
data,
machine
data,
customer
feedback
data,
and
this
gets
aggregated
by
some
kind
of
middleware
plus
system.
A
That
still
is
working
progress,
of
course,
and
that
binds
or
combines
all
of
these
different
data
streams
into
smart
data.
So
here
we
can
run
different
algorithms
and
different
analytic
models
to
actually
make
sense
of
what
we
are
gathering
at
the
the
raw
data
level.
Basically,
and
all
of
that,
these
algorithms
can
then
be
fed
into
the
smart
expert
systems
which
can
help
different
people
in
different
design,
phases
of
or
in
different
phases
of
a
product
life
cycle,
for
example
during
the
development
cycle,
the
the
production
cycle
or
the
user
cipher.
A
Of
course,
we
are
not
doing
that
alone.
We
typically
have
partners
in
these
projects,
and
this
is
a
short
overview
of
our
partners,
not
only
consisting
of,
I
would
say,
typically,
manufacturers
like
bmw
or
airbus,
but
also
digitalizers,
like
siemens
and
bosch,
and
also
aws,
for
example,
for
cloud
as
a
cloud
provider.
A
A
So,
first
of
all,
what
is
our
laser
manufacturing
system?
I'm
typically
working
with
ultra
short
pulse
manufacturing
systems?
These
look
typically
in
an
abstracted
way,
a
little
bit
like
that.
You
have
some
kind
of
laser
source
that
shoots
from
the
side
in
a
scanner
system,
and
this
scanner
systems
basically
consists
of
two
little
mirrors
that
can
be
moved
by
a,
for
example,
an
fpga
system
to
then
locate
or
to
place
the
laser
light
exactly
on
some
kind
of
substrate
or
on
a
metal
plate,
and
then,
where
the
laser
hits
the
the
metal
gets
vaporized.
A
For
example,
you
can
see,
for
example,
filtration
holes
that
you
can
shoot
into
into
a
metal
surface
or
also
a
leather
surface
that
got
shot
on
a
metal
surface
and,
as
you
can
imagine,
because
the
beam
is
moving
so
fast.
A
lot
of
stuff
can
go
wrong,
so
we
typically
include
sensor
systems
into
that
process,
for
example
video
observation
systems
to
observe
the
the
process
status.
A
The
laser
beam
of
the
scanner
system
typically
moves
around
about
three
to
four
meters
per
second,
so
you
need
really
high
frequent
data
acquisition
systems
to
actually
keep
track
with
that.
A
typical
camera
system
is
around
about
1
000
pictures
per
second
up
to
15
000
pictures
per
second,
and
that's
just
way
way
way
too
much
for
what
is
it's
barely
enough
that
one
system
can
handle
that?
A
So
what
you
end
up
with
is
with
the
following
setup
is:
this
is
from
our
lab
that
you
have
multiple
laptops,
multiple
machines
connected
to
one
laser
system
here,
so
you
can
see
here
one
of
these
laser
systems
and
the
laser
beam
getting
guided
in
here
through
this
fiber.
Then
you
have
a
camera
system
here.
You
have
another
camera
system
up
here.
A
You
have
a
microphone
here
and
then
you
have
all
these
different
computers
connected
to
these
different
sensors
and
to
the
scanner
system
into
the
laser
which
are
responsible
for
aggregating
the
data
and
controlling
the
system,
and
normally
the
problem
we
run
into.
Of
course
is
how
do
you
handle
that
kind
of
workflow?
A
What
we
started
with
was
a
workflow
where
we
ran
around
in
the
lab
and
were
shouting
at
each
other,
something
like
okay,
I
just
turned
on
the
camera
and
then
the
next
one
said:
oh
yeah,
I
turned
on
the
microphone
and
then
we
were
like
okay.
Now
I
can
actually
shoot
on
my
my
substrate
with
a
laser
beam.
A
That's
basically
the
scientific
work
we
did,
which
of
course
was
pretty
error
prone,
because
a
lot
of
stuff
can
go
wrong.
Somebody
can,
like
I
don't
know
accidentally,
not
start
the
camera
system
or
accidentally
name
it
differently
and
so
on.
So
it
was
really
hard
to
to
handle
that
data
and
to
to
set
up
a
reliable
experiment
with
that.
A
So
the
idea
was
now
okay.
We
need
some
kind
of
system
which
bundles
all
of
that
together
and
we
had
some
ideas
and
then
we
thought:
okay,
let's
try
microservices,
because
first
of
all
they
are
distributed.
Anyways
and,
second
of
all,
we
can
go
completely
on
a
network
system
on
or
we
can
rely
on
a
network
and
make
it
really
really
play.
A
A
So
that's
pretty
much
the
the
motivation
of
harvard
system,
that's
where
we
come
from
now,
a
little
bit
about
the
architecture
and
the
current
labs
about
we
have
at
the
moment
we
started
with
a
really
really
general
architecture,
so
we
said
okay
cool.
We
have
now
all
these
different
services.
We
want
these
different
services.
We
want
one
service
that
controls
the
scanner.
We
want
one
that
does
the
sensor
and
we
want,
for
example,
also
something
that
analyzes
our
sensor
data.
A
As
I
said,
for
example,
the
example
with
a
shooting
a
hole
in
a
metal
plate,
and
we
want
to
make
sure
that
this
hole
is
actually
shot
through.
So
we
need
some
kind
of
analytics
service
which
takes
a
picture,
takes
a
looks
on
the
picture
and
then
tells
us
okay.
Where
are
the
holes
in
the
picture
and
do
we?
Maybe
we
run
or
need
to
rerun
the
process
or
the
laser
beam
on
that
specific
point?
A
So
the
idea
here
was
okay.
We,
we
kind
of
like
put
the
analytics
service
in
its
own
bubble
in
its
own
container
and
by
there.
Therefore,
we
can
basically
move
it
out
of
the
system,
and
then
we
have
some
kind
of
job
controller
in
the
middle
right
here
which
connects
all
of
these
different
parts
and
has
the
complete
execution
logic
bundle
inside
of
it.
And
of
course,
when
you
need
some
kind
of
job
controller,
you
need
a
job,
spawner
and
some
kind
of
user
interface
to
actually
handle.
All
of
that.
A
Is
we
came
up
with
our
three
first
container-based
images
with
a
movement
service,
a
camera
service
and
a
scanner
service,
and
all
these
different
services
can
talk
to
different,
can
talk
different
apis,
so
the
movement
service,
for
example,
can
talk
modbus,
but
doesn't
really
matter
anymore,
because
we
are
using
grpc
to
control
the
movement.
So
we
have
a
standardized
way
of
talking
to
hardware
which
then
gets
translated
into
another
protocol.
A
What
to
do,
and
this
works
really
good,
because
we
have
now
our
scanner
services
we
designed
them
stateless.
So
when
they
come
up,
we
know
that
they
are
already
configured.
They
are
already
honed,
they
are
already
well,
basically
ready
to
go,
and
the
user
of
that
system
doesn't
need
to
worry
about
it
anymore.
It
just
sends
a
signal
like
move
from
a
point,
a
to
point
b
to
the
movement
system
and
the
movement
system
does
that
same
for
for
the
laser
system.
You
just
send
the
laser
system,
basically
a
drawing.
A
So
that
was
basically
part
one.
How
do
we
can?
Oh?
How
can
we
can
we
manage
different
hardware
protocols?
Well,
basically,
we
introduce
a
new
layer
of
abstraction
by
using,
for
example,
grpc,
of
course,
rest
could
work
as
well,
but
we
wanted
a
protocol
which
is
binary
because
of
the
high
throughput
we
had,
so
we
decided
on
grpc,
for
example.
A
The
next
question
we
had
is:
how
can
we
actually
store
our
data
automatically?
For
that
we
need
to
take
a
look
a
little
bit
deeper
into
the
the
services
that
we
created,
so
we're
gonna
focus,
for
example,
on
one
of
these
hardware
controllers
now,
and
we
came
up
with
the
following
structure.
So
the
idea
was
okay.
We
have
our
our
hardware
adapter,
basically
which
controls
our
hardware.
A
So
we
have
some
kind
of
scanner
system
from
one
vendor
and
we
make
a
grpc
interface
right
in
front
of
that,
so
that
we
can
control
this
system
directly
via
a
network
call,
and
we
put
the
whole
thing
in
a
docker
container
and
we
then
introduce
the
so-called
service
controller,
which
basically
proxies
the
the
incoming
client
call
to
the
hardware
adapter.
So
what
happens?
Is
a
user
connects
to
our
scanner
service
and
says:
hey
scanner?
Please
shoot
one
point
and
this
the
service
controller
takes.
This
request,
sends
it
down
to
the
hardware
controller.
A
The
hardware
controller,
shoots
one
point
and
then
goes
to
the
service
controller
and
says
hey.
Okay.
I
just
did
that,
and
the
service
controller
will
then
save
the
call
and
the
answer
of
the
hardware
into
a
database
and
make
it
basically
lock
itself.
So
it's
basically
a
really
simple
locking
mechanism.
A
Of
course
this
is
pretty
boring
for
for
for
actuators,
but
for
sensors.
It
gets
very,
very
interesting
because
you
can
say
something
like
hey
camera.
Please
take
a
picture,
then
the
picture
gets
taken
and
then
you
save
it
into
your
database
and
you
just
hand
over
the
url
back
to
the
to
the
client
and
say
hey.
I
just
took
that
picture
for
you.
If
you
want
to
take
a
look
on
it,
just
get
it
whenever
you
want
and
whenever
you
want
to
get
it.
A
So
the
nice
part
about
that
is
that
everything
you
do
is
getting
locked
and
saved.
And
since
we
put
everything
in
containers,
so
we
have
one
container
for
our
service
db.
We
have
one
container
for
our
service
controller.
We
have
one
container
for
our
hardware
adapter.
We
can
put
or
use
config
maps
to
configure
that,
and
we
have
some
kind
of
automatic
configuration
management
which
can,
of
course,
which
kubernetes
luckily
already
provides.
So
we
don't
need
to
worry
about
how
to
handle
configuration
in
the
system
anymore.
A
So
well,
what
we
ended
up
with
in
the
end
was
basically
a
kubernetes
cluster
which
spans
not
only
from
into
a
data
center
on
a
shop
floor,
but
also
spans
onto
the
edge
directly
next
to
the
machine.
So
what
we
can
see
here
is
that
our
edge
is
basically
the
the
computer
or
the
the
server
sitting
or
directly
controlling
the
laser
beam
on
directly
controlling,
for
example,
the
camera
system.
Of
course,
since
we
are
in
a
manufacturing
environment,
we
can
go
pretty
we,
we
can
buy
pretty
large
systems
here.
A
So
these
are
normally
not,
I
don't
know
jetsons
or
raspberry
pies,
but
we
buy
real
server-grade
stuff,
because
we
have
enough
internet
connection
and
we
can
also
provide
enough
energy,
because
our
laser
system
already
needs
energy.
So
we
can
just
leverage
that,
but
we
can
also
use
or
connect
it
directly
via
kubernetes
with
our
data
center,
where
we
have
multiple
servers
running
and
the
nice
part
now.
Is
that
the
the
picture?
I
just
showed
you
this?
We
can
because
of
kubernetes.
A
We
can
shift
all
of
these
containers
around,
so
we
can
say:
okay,
cool.
I
have
a
camera
system
which
produces
15
000
pictures
per
second.
I
probably
need
the
database
pretty
close
to
the
to
the
manufacturing
system
in
order
to
to
even
be
able
to
save
that
into
a
database,
while
with
other
services
you
can
like
decide.
Okay,
maybe
it's
not
that
important.
Maybe
I
don't
want
the
hassle
of
actually
having
that
kind
of
database
right
next
to
that,
I
can
put
it
into
the
cloud,
for
example,
and
that
is
really
nice
about
kubernetes.
A
It
gives
us
the
flexibility
of
shifting
all
of
that
around
and
see
what
actually
is
happening
and
design.
Your
system
that
you
that
you
can
can
very
flexible
change
depending
on
the
data
stream
you're
using,
so
you
can
plug
in
a
new
camera
system
which
produces
a
lot
more
data,
and
then
you
say,
oh
cool.
I
just
need
a
database
right
next
to
it,
damn
there.
A
A
A
We
have
automatic
sensor
data
acquisition
with
high
support,
which
is
also
really
really
nice
to
have,
because
before
that,
we
had
to
handle
that
by
hand
basically
because
of
kubernetes.
We
have
a
single
point
of
truth
for
configuration
because
we
use
conflict
maps
for
everything,
and
that
is
really
nice,
especially
from
a
scientific
point
of
view,
because
we
know
what's
going
on,
we
can
roll
back.
If
somebody
changes
some
kind
of
I
don't
know
frame
rate
or
the
the
the
I
don't
know,
acceleration
of
the
of
the
movement
service.
A
We
see
that
and
we
can
use
git
to
versionize
it
by
the
use
of
grpc.
We
actually
prevented
a
vendor
login,
so
the
system
I
just
showed
you
works
on.
I
think
right
now,
three
or
four
different
movement
manufacturers
and
also
on
two
different
scanner:
laser
manufacturers
and
it's
also
scalable-
to
probably
a
few
thousand
of
nodes.
So
you
could
run
your
complete
shop
floor
with
that
and
you
also
get
remote
control,
which
wasn't
a
thing
till
now
at
our
institute,
which
brings
me
directly
to
that.
Well,
you
get
remote
control.
A
So,
of
course,
since
we
are
now
completely
network
based,
we
open
up
for
hackers
and
so
on.
So
but
yeah
kubernetes
is,
I
think,
a
very
nice
system
to
to
to
handle
that
it
gives
you
a
lot
more
overview
of
what
is
actually
going
on,
but
still
like.
We
are
running
a
laser
system
in
the
network,
so
yeah.
A
We
have
a
little
bit
of
risk
here,
and
this
is
especially
a
problem
when
you,
when
you
take
in
consideration
user
management
and
and
safety
stuff,
if
anybody
knows
of
some
kind
of
way
of
authorizing
or
some
kind
of
way
of
proximity
based
authorization.
Please
give
me
a
call,
I'm
really
really
interested
in
that
and,
of
course,
one
of
the
larger
problems
we
have
is
that
we
have
now
a
distributed
state
management
which
makes
stuff
a
lot
more
complicated.
A
Normally
we
had
one
machine,
one
machine
or
one
machine
connected
to
multiple
things.
That's
way
way
way
easier
to
handle
than
multiple
machines
in
a
network
which
is
running
unreliable,
okay,
the
ugly,
well,
you
run
into
a
lot
of
concurrency
problems
through
microservices
that
you
don't
have
to
handle
before
when
you're,
not
using
microservices.
A
A
I
see
the
whole
industry
is
a
little
bit
shifting,
but
it's
still
a
lot
of
windows
which
isn't
that
good
for
humanities
and
we
have
finally
automatic
testing.
So
we
can
test
our
machines
automatically
pretty
easily
summary
yeah
microservices
for
manufacturing
are
really
really
cool.
It
makes
a
lot
of
fun
programming
your
manufacturing
machines
with
that
kind
of
architecture.
A
Yeah.
That
would
be
all
from
my
side
thanks
for
listening.
If
you
have
more
questions,
please
send
me
an
email
or
ask
them
directly
in
the
question
and
answers
directly
after
that
also,
I
would
really
really
like
the
dfg
for
sponsoring
the
scientific
research
via
the
internet
of
production,
without
that
I
wouldn't
probably
be
here
today.
So
thank
you
very
much
for
that
and
see
you
in
the
comments.