Denis Gontcharov: Hi and welcome to
the smart metals podcast, the podcast

where we help your manufacturing
company digitally transform.

My name is Dennis Gontcharov
and I'm here with my co host,

Yes,

today we have a special guest on
the podcast, Angelo Hulshout, who

will talk about the challenges of
implementing a unified namespace.

Welcome to the show, Angelo.

Angelo Hulshout: Thank you, Dennis.

Not that special.

I'm just another guy working
in the same domain, I guess.

I'm a software architects
for 30 years now.

I've been working in manufacturing
projects since around 2014, mainly in

the area of animal food production.

And the equipment building around that.

the equipment builders that machine
builders, but I made some, explorations

into the metal industry as well.

I think that's also where I came
across Luke the first time that

he invited me to this podcast, so.

regular listeners
probably heard me before.

Denis Gontcharov: I think the common
topic that unites us three here today is

the unified namespace and our admiration
for this new philosophy, so to speak.

According to your experience, Angelo,
what is the state of the adoption of a

unified namespace in the European Union?

Angelo Hulshout: That's a good one.

That's something that we briefly
touched on before, I guess.

But what I see is that well, unified
namespace, of course people who dive

into that will soon enough find out
that that's the source of that is

In the US, in Texas, with Walker
Reynolds, and it blew over the ocean

around the time of the Corona pandemic.

Basically that's quite a funny story.

They had internal whiteboard sessions
where he explained his ideas about

unified namespace to his team.

Cause he actually came up
with the idea already in 2006.

So they decided to put those whiteboard
sessions online and also post them

on YouTube for other people to see.

So that that's when it started
blowing over to Europe.

What I see now, and I've been at
the, in May, I was at a trade show.

What's it called?

In Parma, the name Slip My Mind.

it's a sister sister event of a
similar trade show in Frankfurt.

And I was talking to people there in
the smart industry platform to see

what they knew about Unified Namespace.

And, what I see basically confirms

there are people who know about it.

And a lot of the people that know about
it are the people that are building

software and tools, so solutions.

But what I also notice is that there
is very few people in the actual field

of manufacturing that are aware of it.

Maybe in the IT departments
of some companies, there's

somebody who knows about it.

But if you talk to the real, really
to the people in manufacturing, the

operators, the plan managers, , if they
have heard about it at all, it's just

another technical thing that they're
not really, how should I say that?

They know that they need an ERP system.

They know they need a mass system, and
maybe at some point they need a UNS,

but what it is and what it can bring
them that's outside of their view.

So yeah, basically what I see is that
a lot of technical people and a lot of

software and IT people know what it is.

And there are a few companies like
HiveMQ, for example, and a few

others that are actively promoting
their tools for unified namespace,

just like the companies in the U.

S.

do.

But in the target field, the customer
field it's not really well known.

And on top of that, the few
implementations that I'm

aware of in Europe are either.

The ones that intelligent that
Walker Reynolds company, or that's

a European company did after being
introduced to the customer by Walker

or vice versa, so there is drive.

In the technical world, there is
very little traction from what I

can see from the customer world.

And the projects that are there
are right now, basically driven by,

let's call it the source of the UNS.

But I also see, and that's maybe part of
what I've been doing in my own network,

the people that I discuss it with
are getting more and more interested.

But it's really hard to make them make the
jump and say, Okay, let's do this instead

of asking our current MES ERP vendor
to solve our problem in their product.

Denis Gontcharov: Yeah.

I just want to add from my experience in
the aluminum industry that the concept of

the unified namespace hasn't landed yet.

So indeed, again, the only people that
know about it are, I guess, the IT persons

that read my blog or my LinkedIn posts.

do you see a similar thing
in the sheet metal industry?

Luke van Enkhuizen: Yeah, of course, there
are the technology interested pioneers

that are really looking for the next
thing they are interested and I know

quite some owners of companies that are
Following along and they really understand

the pain of the point to point approach.

And they see this picture of the
spiders web with all these, little

planets around it, like with all
the solutions that you could have

in your factory, all the layers.

And then I say, yes, I want that,
but they don't know what it really

means and how to get there yet.

And they don't really understand what
event driven architecture is yet.

So they get the vision.

I think they get where it's going, but
they still look to buy a product, a

solution that does it all out of the box.

And they don't really know the steps to
get to the end vision in my experience.

But there is an interest, a
growing interest actually.

And I see it in my own customers
actually that want to start.

And I'm doing some projects right
now with some of my clients.

So it is, there's some
movement going on here.

yeah, on a large scale, I would not
say it wouldn't take so long, I think.

Angelo Hulshout: Well, that matches a bit
of what I said before, indeed, I had one

example that couldn't nicely be solved
at unified namespace and coincidentally

that was in the metal world.

So in animal food, but you
both are aware of how these

metal factors are structured.

Of course, you have a lot of workstations
and the material goes from station to

station on a card or in a box or whatever.

What I did a few years ago,
maybe I discussed it previous

time with Lucas as well.

the owner of the factory said, Hey,
I would like to keep track of where,

because we have multiple projects running
at the same time in this factory, where

the materials for each of these projects
are, how far they've been processed

and in which workstation they are.

And I want to do that in such a way
that my plan manager in the control

room can see it in the office.

But I also want to screen with each
workstation so that each operator can

see what work is coming to him today.

And so that each operator also can
see what the status of the work

is that is coming that way because
it goes from station to station.

So we made a proposal there to
build a prototype and we also

build a prototype and we show them.

And that was basically, well, it wasn't
completely unified namespace, but it was

based on the same technology and the same
concepts that we see In the real life

examples, that are there at the moment.

So MQTT, a dashboard on top of that,
a real time exchange of information.

When an operator says I'm done with
something, every other screen in the

factory that has a need for whatever
comes out of his operation gets

notified immediately on their screen.

So a lot of it was there.

And in the end, after the
prototype, we had a short delay.

It was summer, just like now.

So we had to wait a few weeks
because the factory was closed.

And the week after the factory was
reopened, we sat together again with

the owner and the meantime, he had a
visit from his ERP vendor and the ERP

vendor said, okay, well, we have all that
information as well, so we can also do

that for you and what you immediately see
then is something that I've been running

into for a couple of years already.

Because doing something with
Unified Namespace or a new

technology is something new.

And they fall back on what
they know and trust already.

And they trust their ERP vendor.

And yes, they made something that
functionally does what I just

described, but everything goes
first to the ERP database now.

So the whole idea of having that
real time information exchange,

yeah, that's delayed there.

So the information is there, but
it's no longer really in real time.

It all goes through the ERP database.

And it's far less flexible than what
we proposed, but yeah, apparently at

that time, that's what made them happy.

I'll be meeting with them again
just after summer this year

to see where they stand now.

it's really a combination of
not knowing what it can bring.

Not knowing the technology
and then falling back on what

we trust and know already.

The classic fear of change
is also playing a role here.

Denis Gontcharov: you say that this
fear of change and not understanding

the UNS is something typical of
manufacturers EU because it's seen

that in the U S they are more risk
taking or is this just an assumption?

Angelo Hulshout: That is something
that comes up in a lot of discussions

that I've had over the past few years
about manufacturing and smart industry.

Certainly after the Unified
Namespace Became more popular.

And what I've seen before, also
before I rented the manufacturing also

industries in healthcare, for example.

The U S is known for, you know,
being much more in favor of

innovation and entrepreneurship.

a lot of new things that we got in the
last, let's say, 25 years come from the U

S because of that culture of putting money
into new companies, putting money into new

ideas and experimenting with new ideas.

And apparently that also works to
some extent in manufacturing, and

manufacturers that seem to be much
more open to try something new.

then In, Europe, we're more like,
okay, let's first see how things

work, then let's see what the EU has
to say about it in terms of rules.

And then let's see what we do.

you see that happen with AI as well.

AI is not first going to the innovations
and the applications in Europe.

No, it's first of all, going to
the European union to make sure

that everybody's privacy and
everybody's safety are protected.

So that there's, there's a cultural
difference that, that makes it a bit

harder for new things to land in Europe.

I think.

Actually, now I'm going to probably make
some of my my partners in that domain

angry, but I worked together with a
number of companies in the context of

European funded EU funded projects.

Often when I look at the proposals
for the horizon program, for example,

if there's a new set coming out
this month, I see the proposal.

I think, okay, yeah, this is new for
European companies, but if I look around

on the internet, I can find three or four,
Possible solutions that are already in

place in the U S or in Canada already.

So we're always a bit behind here.

So that's a bit of
culture that plays a role.

I have to borrow example from Walker
Reynolds again, simply because it's such

a good example of how different that is.

In one his videos, he explains
how he got his first UNS project

after he started his own company.

It was basically a manufacturer that
he knew or where he knew somebody.

I forgot the details.

They wanted to re do the automation
of two or three factories.

And they got a proposal from Rockwell
and another big vendor that were

in the area of 30, 40 million.

he was brave and said, listen,
I want to do it with my

approach with unified namespace.

This is how it works.

And I do it for one and a half million.

And he got the project because
the manufacturer simply

said, okay, I like that idea.

I like you let's try.

And if you fail nothing is lost, I will
spend one and a half million, but I'll

find a way to Compensate that with whoever
else gets the contract after you fill.

Because one and a half million
is nothing compared to the 30, 40

million that I would spend otherwise.

That is something that's how
people there reason about money.

That I don't see so often in
the Netherlands, in Europe.

They say, oh, okay, that can be done.

Let's try.

I'll give you one and a
half million and try it.

Luke van Enkhuizen: If I can jive in
here a bit, because especially with

the, the latest technologies around
the unified namespace ,MQTT, all these

things, most of it is open source.

So the software itself technically
with enough time and effort is free

while you could buy a solution of
the shelf and pay the millions.

You just don't have somebody tend
to say, okay,, leave me a solution.

You have to build the technology
how you need it, bolt it

together, how you need it.

And I think that's the
major difference, right?

So you're at a pay, I just had like the
many millions for a project where you buy

a solution with consultants around it and
then hope that it's going to work out.

But.

It's not completely tailored to
you and then you can get it almost

for free in software terms, but
you just have to put more effort

into it, defining how you want it.

And then I think that's kind of the
distinction between the two, right?

Angelo Hulshout: And now that you
mentioned it this way, that makes

me think of something that comes
up every once in a while as well.

What are you trying to sell?

=Are you trying to sell

or a concept?

Or are you trying to sell a product?

A lot of the traditional suppliers
to the manufacturing industries are

of course, the, the, the big system
integrators that sell their own mass

product that sell their own ERP product
that sell their own SCADA product.

And they sell a product.

And for a lot of people, also,
because that's what you do at home.

If you need a solution, you buy a piece
of software, you configure it and maybe

you have somebody make some modifications
on it and that's what you have to do.

If you come with unified
namespace, you basically sell

an idea, you sell a concept.

And then in a second step, you're going to
check, okay, what is the exact technology

that we're going to use in this case?

If that's how it's approached now,
are we going to use Mosquito open

source or are we going to buy HiveMQ?

are we going to, , I forget
what that product's called.

, that's a product from, from the U S.

Luke van Enkhuizen: You
mean high bites perhaps?

Angelo Hulshout: You know, the other one

Denis Gontcharov: All this stuff.

Angelo Hulshout: I
haven't really added it.

there are a couple of commercial products.

can use ignition.

Yeah.

That's the one.

See, forgot that name last time as
well, but that's somehow that doesn't

stick in my mind, but that's a product
and they have a very nice approach.

I think high by does the same.

If you are a developer or a system
integrator, you can just get that product.

You can use it for free.

You can experiment for free, but
as soon as you start applying it in

a factory, And somebody will have
to start paying for the license.

that's a very nice model, but the
traditional vendors, the Schneider's

and SAP, they sell you their product.

And then once you have spent a lot of
money on that, they charge you extra for

the modifications and the configuration,
you're basically stuck with them

Denis Gontcharov: Yeah,

Angelo Hulshout: get rid of them.

But that same cultural issue
that I mentioned before, it seems

that in Europe, we're a bit more.

Leaning towards, okay,
we paid for the product.

So let's see what the vendor can do
to help us instead of, okay, we paid

for the product, but now we want
something new that they don't have.

Denis Gontcharov: just to
zoom in on this problem.

Would you say it's fair to say
that the vendors are part of the

problem, essentially obstructing
innovation by trying to force the

client to keep using their products?

Angelo Hulshout: I had to integrate
with a mass system and the moment

MQTT was mentioned project manager
on the other side of the table said:

oh, we have interfaces based
on XML files, that we exchanged

between our MES system and ERP.

They want to stick with what they have.

They want to stick with what they sold
to the customer and all the modifications

that they have to make there and all
the configuration work that they have to

do, that's their actual business model.

But the moment somebody says,

Oh, we want an MQTT interface.

That means that they have to start
adding something completely new to

their system and integrate that.

And of course that comes at a price.

So they will try to hold
off as long as possible.

in this case, we got our MQTT
interface and in the next generation

of that product, they're actually
integrating an MQTT interface.

They made the change, but initially
this is one example, but the

hell happened multiple times.

an integrator will first see, okay,
this is what my product can do.

And can you as the new party interface
with that instead of saying, okay, you

come with a new solution with a new
interface, we're going to adapt to that.

Luke van Enkhuizen: I just have a
question here, just so that we can explain

this to the listeners of this show as
well, so that they can follow along,

For example, we talked about MQTT.

Now, could you perhaps from your
experience as doing many of these

projects, explain to the listeners
why this is so different than for

example, standard file exchanges and
why this is so much better or perhaps.

scalable.

And maybe that is also making it
better, but just continue to explain

why this is such a big thing.

Angelo Hulshout: I can try it.

It's a combination of, of two things.

One, one is the traditional stack
that we, the software stack that

we see in manufacturing automation.

At the bottom, you have the PLCs.

On top of the PLCs, you may have
A-A-P-C-S or a SCADA system.

On top of that, you have mass to
manage the manufacturing process.

Across the whole factory and SCADA
is, yeah, basically just combining

all the different PLCs that are in
a different machines to make visible

what happens in the physical world.

The, the planning and everything on top
of that resource management is a MES.

And then on company level, you can
put an ERP on top to do management

of the stock and the purchasing and
the sales, et cetera, and translate

that into whatever needs to go into
the factory in terms of production

planning and production results.

If you want to see more about what's
going on in your factory and you talk to

the vendors of those systems, what you
end up with is that all the data that you

need, all the information that you need
is either on the machine level, so in the

PLCs or on the SCADA level on top of that.

And in order to make it visible, you
have to go up at least to the MES level.

And often also to the ERP level to, yeah,
to be able to visualize all that data.

So what you get is all the data that
you want to get out of your production

line has to go up through SCADA, up
through MES, up through ERP optionally,

and then it ends up on your dashboard.

So making a change there, because
you want more information from your

production line means that you have
to make changes in the PLC probably.

You have to make changes
in the Scala layer.

You have to make changes in the MES layer.

And then on top of that, you can
finally make whatever it is that you

want to see visible in a dashboard
or an historian database on a report.

While with unified namespace and
especially with technology model

that underlies can just make direct
connections on all these levels.

And instead of making changes to
all these different layers, pull

out the data that you need and make
it visible immediately in a place

that has access to all the sources.

And that's what I explained earlier
with that factory where they wanted

to see in real time what the status
was of all the pieces of a project

that go to the metal workshop.

If you do that to a unified namespace
using MQTT, What you can do is every time

an operator says, okay, I'm done with this
piece or I'm starting with this piece.

There's a little MQTT Message going
from that workstation to the unified

namespace and all other systems
are listening to whatever change

comes by on that unified namespace.

And they make that visible
on the other screens.

While in the approach that they
have now, that signal doesn't go to

all the other screens through MQTT.

No, it goes to the ERP system
through a database call.

And then every X seconds, the other
screens will pull that ERP database to

make visible what actually happened.

So the real time effect is gone.

There are extra tables in the
ERP database now, very likely.

And there are dedicated interfaces for
that databases and all the screens.

Well, with MQTT, what you do is you make
a generic interface and you can make

adapters for that or you can build it
into the product or maybe it's already

in there to say, okay, whenever something
changes the value of a sensor or a new

production order comes in just put
that on an MQTT Message, send it out.

And everybody who's listening to the MQTT
system can immediately pick up on that

change or that Message and make it visible
or do whatever it needs to do with it

instead of having to go to a database
and then pull that database every

few seconds to see what's going on.

If I had prepared for that question,
I could have made it even a

little bit more clear, but it's
basically the difference between.

What happens in the current case
is that everybody, everybody knows

that game where you have to with
per sentence and other people's ear.

And then have to give the same
sentence to the next person,

Denis Gontcharov: think
it's called telephone.

Angelo Hulshout: that's a telephone,
but this is a game that people play.

It sounds very simple.

What you want is that the sentence
changes in a controlled way and

in the game it's uncontrolled.

So the last person in the row
will say something completely

different than the first one.

In this case, what you do is you give the
sentence to somebody, they translate it

to something that fits in their world.

And then they give that
translation to the next person.

So the PLC has something, it tells
SCADA, hey, I have something.

SCADA translates that to its own
words, gives it to MES, translates

it to its own words, and MES gives
it to ERP or to the dashboard.

understand.

And what you do with the Unified
MQTT approach is, you send that

Message once to a central system,

You broadcast it on television
or on radio, and everybody's just

listening to that Message gets to
hear that exact Message that you

released and it's immediately in
the language that you want to know.

There's no translation in between.

There's no interfaces in between.

Everything goes straight to
the same person immediately,

Denis Gontcharov: I
think very good analogy.

Yeah, I want to bring the
question back to the UNS adoption.

I think Luke raised a very good point
earlier, trying to explain this problem

to let's say less technical crowds
who are often the decision makers.

I think Angela's expression
here was very clear.

And often after hearing that they would
say, Oh yes, now I understand the benefit

of a UNS, but it's somehow still not
enough to make them pull the trigger.

So they acknowledged it's important,
but they always counter with the

question, but what can it do for me?

So how can we answer this
question to hopefully drive

the UNS adoption in Europe?

Angelo Hulshout: Yeah, and that that
is one that almost comes back to from

my point at least to two basic sales.

Don't don't sell the product, but
sell a solution for a problem.

Simple example: one time
I was visiting a factory.

And the operational director told me, Hey,
I have one very specific problem here.

I can't bill all the hours that my
people spend on a project for a customer.

it was also a project workshop.

They did metal and plastic and they
delivered sub assemblies for among

others for a big healthcare company.

Why can't you bill the hours?

How does it work?

So it was very simple: we have
customers that want us to, uh,

deliver a part Of that product.

In this case, it was the example was
the tables that are in MRI systems,

the table that you put the patient on.

They make those tables for that
healthcare supplier, big Dutch one.

Okay.

Then everybody can guess which one it is.

It says, well, we make those
things, but we sell, we sell

them for a price per unit.

plus a price per hour that we
spent on the assembly and on

certain specific operations.

And he was pointing at one of the
workstations in the factory and says,

okay, this one's a good example.

This operator is there for
eight hours a day, two shifts

of four before and after lunch.

And he works on multiple
projects during the day.

And he has a screen where he can
indicate, okay, now I'm working

on this, and now I'm working on
this, and now I'm working on this.

a bit like the situation in
the other example that I gave.

But the problem is, he
forgets to press that button.

And then he clocks in in the morning
and he clocks out in the evening.

So I can see that he worked for eight
hours and that he clocked out and

in before and after lunch as well.

But for a large part of the eight hours,
I don't know which project he worked on.

So I can't bill those hours.

I need a solution for that.

Ah, you can solve that in multiple ways.

In this case, you could tie it to a
MES system or you could tie it to the

time registration system, maybe do
something , in the mechanical world

to make sure that when the material
for one project leaves and for another

project arrives, that he is forced
to do something on the screen before.

But if unified namespace is part of the
solution that like it was in our proposal

for that, that other prototype, then you
can sell him a solution for his problem.

Now, listen, if we do this
and this for you, then.

That information will be
collected more easily.

It will be easier for the operator
and it will automatically end up in

the place where you want it to be.

I'm not saying that in this case, unified
namespace would be the ideal solution,

but that's what they want to hear.

I have a problem and I need a solution.

Can you solve it for me?

They don't want to hear, Hey we
make unified namespaces or part of

unified namespaces, often also spark
plug bridge to talk to the PLCs.

We have our own spark plug bridge.

We can solve your problem for you.

Then you have to first explain
what a spark plug bridge is.

Well, what you actually want to explain
is how does it solve your problem?

So you have to start from the
part, okay, what's your problem?

And can I solve it for you?

Denis Gontcharov: hmm.

Angelo Hulshout: And
then how can I solve it?

Like other, you end up trying to sell
a hammer, a saw, and a piece of wood

to somebody who actually wants to
replace the door posts in his house.

Luke van Enkhuizen: Yeah.

It's like people don't
want to buy a drill.

They want the hole in the wall.

sayings.

I think you raised some very
interesting topics here.

Also a very interesting example
,cause I recognize this one,

that the time record station on
batches or projects or in discrete

manufacturing, it could be orders.

it's quite important to effectively
track like how long, A certain part or

a project or batch took to go through
a certain step, and you mentioned some

examples of how you could indeed register
that either mechanical, software,

=but what's perhaps this may be
important to really dive a bit deeper

into why would this Unified namespace
approach be making this even better?

Because I can imagine that if you would
ask this to their ERP vendor, they

would say, sure, we can make your shop
for a control or shop for operations

app that is connected to your ERP.

So it's right in the same database and
you get just one report, and you're done.

You don't need anything So
we can code this for you.

Shall we start tomorrow?

and then how do we then come with
our story and saying, listen,

That would maybe work for the first
steps, but then it's not scalable.

So how would you answer that?

Angelo Hulshout: a nice one.

Let's use another example for that.

That also makes it more lively
for the less technical people.

Let's say that we're just mixing what
I just said before with something

else that we did a few years ago In
a very funny factory in Italy, where

they make the metal parts for all the
metal shiny parts for the belts and the

shoes and the bags that you get from
the expensive Italian fashion brands.

Well, one of the things that
happened there is that they work on

different projects during the day.

So what we proposed there was,
okay, let's make sure that let's say

that we're talking about cufflinks
or how do you call these things

that are on the front of a belt?

I forgot the English word, the

Denis Gontcharov: A buckle?

Angelo Hulshout: the buckle
yet the buckle for belts.

They go from one workstation
to another in a trade.

So it's like if we put an RFID reader
on the entrance of each workstation and

we put an RFID tag on the boxes that
you use to transfer those materials from

one operation to another, then we can
keep track of the progress of a project.

In the sense of the example that
we had before, the trigger for

an operator starting work on a
specific project would be the arrival

of that box at his workstation.

And one of these workstations, they had
to, do some post processing on material

that came from a cutting machine.

They were cut out except
for two small corners.

So they basically got in the
box, they got a metal plate.

With these little pins cut
out, except for two corners.

And then they had to manually cut out
those last two bits, and then put them

in a box for the next bit of processing,
which was probably the sanding or

the painting, I don't remember.

But sometimes course, some of the
products would get slightly damaged.

If we go then back to that example
of scalability and extensibility,

of course, you can build something
into your system that says, okay,

The box arrives or the plate arrives.

I read the RFID and the operator
is now working on that project.

Time registration solved.

Now, a month later, two months later,
they suddenly realize, Hey, we also

want to keep track of many of these
pins are actually discarded by the

operator, because during the cutting
out, he also checks which ones are

okay and which ones are not okay.

let's Say that a SCADA vendor
built a solution or a mass vendor.

They go back to the mass vendor
and say, Hey, can you add

that functionality as well?

What do you have then?

Another project and these companies
charge by the hour, they have to make

the software specifically for you because
they never had that request before.

So the meter starts running and it's going
to take a couple of weeks or a couple

of months before we have a solution.

If you have a unified
namespace based solution.

You can just say, okay, whenever
that box arrives, we send a Message

to whoever subscribes to it.

So that could be the MES system
who keeps track of the progress of

the work in the, in the factory.

It could be a dashboard that you show
in real time on the control room.

It could be anything.

You send one Message and everybody who
needs to know picks up that Message.

But that information about how much
is discarded and how much is not

discarded has nothing to do with mesh.

That's for quality control.

And all quality control has is a dashboard
to show in real time how much is being

discarded, because they may need to
produce more if there's a problem.

And they have a distribute database
to make some statistics for that.

I say that we build it based on
a unified namespace and MQTT.

We get that same question
after two months.

Hey, can you also build in that
discard or accepted the thing?

Yeah, sure.

What happens there?

If they discard it, it goes to
a box on the left of the desk.

If it goes to accept that it goes
to a box on the right of the desk.

Okay.

Let's put two rings there.

Okay.

And make sure that they throw
these things through the rings.

Denis Gontcharov: Mm

Angelo Hulshout: I know I have
one plate coming in and I know

from the project description that
there are 100 pins in the plate.

So I know that the next 100 pins
have been picked up for processing

time registration is arranged.

And now I see from that moment on
until the moment that the next one

arrives, I see 99 pins going to the
right and one going to the left.

I can show it in real time on the
dashboard for quality control,

because every time that happens, I
simply send a Message and it's shown.

And when it's shown on the dashboard,
it's also put in the database.

The difference is I don't have
to go into a project for months

and months to arrange that.

All I do is Install those
two capacitive rings.

And whenever one of these two rings
says, Hey, I detected that something

went true, I send an MQTT Message.

The only thing you need for that
is something that has a little

bit of intelligence in it, PLC,
or a simple controller board that

connects to those capacitive rings.

PLC

So we could do that.

And you add a little bridge between the
PLC and the MQTT server to make sure

that the signal is picked up whenever
something goes to the ring and your

dashboard is updated in real time.

It takes a week, max, and you don't
have to go through the project

office of a system integrator.

You don't have to make big
changes to a mesh system.

So it's, very flexible in that sense.

Whenever you want a new event that
you're interested in, you just add a

Message for that to your MQTT system, to
whatever topic you want to send it on.

And every system that you want to
do something with that data can

subscribe to that instead of first
having to go into an expensive

monolithic system to to change it.

Denis Gontcharov: Maybe we can close the
podcast by highlighting some ways they

could get started that would be low risk.

In other words, what would you advise the
potential manufacturer who is interested,

but still hesitant about adopting a
unified namespace at his or her plant?

Angelo Hulshout: Okay.

Yeah, that's a nice one.

Of course, it depends on what specific
question they have, whether unified

namespace is a good solution or not.

But let's focus on the simple basic case.

We just want to keep track of what is
going on in our factory in real time.

That sounds very complicated,
but it's actually very simple.

Because what that typically means
is that you want to know the kind

of things that we discussed before.

Which production order is running at
this point in time what part of the

order has been processed, the parts
that is being processed, where is

it and what is the status of that?

A lot of that information is displayed
traditionally on the dashboards

that you get with your MES system.

But only after the steps
that we discussed before.

So if, if you want to do that in
real time, then it's relatively cheap

to do that with a unified namespace
solution, because we would simply

install a bridge between the PLCs that
control the production line and the

MQTT system, assuming that we use MQTT,
and connect the dashboard to that.

The first thing that you can do
there is make visible what is

already visible on your mass system.

Because that's derived from that
same information that you would get

from the PLCs on the production line.

And then on top of that, you can
very easily add the specific things

that your MES system is not showing
you, that you would like to know.

An example that we were discussing
last week for example, is

in the animal food industry.

We create batches for, let's say they
work with production orders of a couple

of tons and a number of ingredients
are traditionally dosed manually.

One of our customers we are working they,
they invented the system that automates

that, that manual dosing process.

And what they do is instead of dosing
things by hand into the main production

line, they dose it automatically
into smaller boxes, which are then

tipped into the main production line.

And one thing that we want to
know, wanted to know that from the

start was, okay, for each batch, we
have to produce one or more boxes.

What's the status of these boxes?

Are they ready?

Yes or no?

And it's very basic.

That's there.

No problem.

Later on, you want to know, okay,
but there are different materials

being dosed into those boxes.

We want to know how many dosings
have been performed per box already.

Now, who knows that?

The PLC knows.

He knows what he dosed
in that box already.

So the box is standing there, all the
ingredients go in and every time he knows,

okay, I'm putting in material A, B, C, D.

So it's very simple if you have a unified
namespace to add one little extra Message

that not only says the box is finished,
but that between the moment that the

box arrives and the box is finished,
it also sends a Message every time it

completes the dosing for one material.

And then in five minutes you can,
you can, you know, almost literally

five minutes you can build something.

That extends the dashboard that
gives pro progress on production

with an extra level of detail.

it's small examples like
that, that that can help.

You can set up a prototype for
that in a day, two days, and

you can add these extra details.

And depending on how complicated the
system is, you can add them in a time of

between five minutes and a day, maybe.

Luke van Enkhuizen: Right.

Angelo Hulshout: Cause you can do that
outside your, yeah, outside the world of

making changes to our existing system.

Luke van Enkhuizen: So
this is, this is excellent.

And in the metals industry.

So going from the start of actually
the metals manufacturers all the

way, two metal fabricators in the
whole spectrum of this industry.

Which of them do you think would benefit
the most from this approach first?

Where do you think the
impact is the highest?

where would it make the most impact?

Angelo Hulshout: That's a good one.

you're more aware of what's
going on in the metal world

than I am in detail, I think.

The biggest impact of using unified
namespace in the metal world.

Luke van Enkhuizen: Yes.

Like the examples you mentioned
prior, where you're using a different

architecture for the factory and which
industries would be the first to saying,

okay, which is where I would start with
projects where I think most impacts to

make could also be that they are equal.

Just what do you think about this?

Angelo Hulshout: The thing is that you
know, of course, it depends on what is

the problem that they're trying to solve?

And then it depends on which
company you're talking to.

But unified namespace based solutions,
assuming that you can make a bridge

between your existing system and the
simple MESaging system that it actually

is there are three places based on what
I've seen in the past few years that

come to mind that could have a nice
impact because you would get a relatively

cheap solution for something that could
bring you or save you a lot of money.

One I mentioned already,
that's the time tracking.

The second one is waste and we have
somebody working on, everything

that has to do with waste, how much
can you recycle, how much waste

can you prevent in other ways?

What I've there, that was really
also in a metal company was in

Italy, manufacture of the metal
parts for the what do you call them?

And in Italy, we call them the things
that you put in front of the window.

.
And one of the things that we found
when we were there, it was 2021, I think,

was that a lot of material was wasted.

simply because they MESed up
the setup of their systems.

That's a very specific example.

And then the real reason that was
that they were doing the setup

of the machines manually while
they also had software for it.

the first four or five and this
were the axles for the for the

top parallel that were coming out.

The first four or five after
a new setup, they had to throw

away because the setup was wrong.

The holes were drilled in the
wrong place and things like that.

Of course, the software
can solve that for you.

But in terms of unified namespace
they could set up a dashboard in

which you monitor how much material
you throw away on a weekly basis.

And then later on, extend that with, okay.

After you solve that, you
can go to the next level.

How can we prevent waste?

First of all, in this case,
by changing the setup.

And also, how can we prevent waste by
not buying more material than we need?

And make also visible on your
screen, okay, how much do I buy?

How much do I actually use?

And that's again, the same story of
adding a simple Message to register when

something comes in, and when something
is thrown away, and when something is

actually considered the correct product.

But in terms of money, that
can make a huge impact.

If you have more competitors,
you want to keep your costs down.

And if you want to keep your costs
down, you don't want to waste material.

Wasting material means you don't
want to throw it away, but you also

don't want to buy more than you need.

And what they typically did was
buy a lot of material because they

knew that some of it was going
to be wasted, but not how much.

So in the end, they would end up with
a pile of rubbish, a pile of products,

and a pile of material that they
weren't sure when they were going to

use it again, because they didn't know
how long it would take to sell the

products that they made already and
when they would get orders for new ones.

And so in terms of material waste.

There's a lot to win simply by adding
signals when something is coming

in, when something is used, when
something is wasted in whatever way,

thrown away or damaged or, and so on.

that translates to money.

And is there a third, then
what else costs money?

Material costs money and time if
you can solve problems in that

area, you have a huge impact.

And if you use unified namespace and
the underlying technologies to address

those things can make a lot of impact
already with a relatively cheap solution.

Luke van Enkhuizen: Yeah, the third
one would be for me particularly

it would be what's also cost a lot
of money is searching for things.

I mean, many companies know that
they have somewhere a supply of a

certain product or remainders, as
you said, and the searching for that.

Searching in a warehouse, checking
if it's there, keeping inventory,

updating inventory, making sure
it doesn't break inventory.

Those things also cost time and money.

And that will be

also one you could track.

Angelo Hulshout: That's something
in the company that made the metal

parts of the fashion products.

We discussed that one as well, indeed.

But there we said, okay, they make
products to order, but they know

that certain customers also will come
back with similar orders later on.

So some of the parts that they had to
produce whenever they got an order,

they would produce 10 or 20 percent
extra and put that in the warehouse so

that they had it available already next
time, speed up the production process.

And That we made a proposal and
he thought, okay, how are we going

to trace that material and how are
we going to keep track of that?

Whenever it's produced or whenever it's
discarded, you can raise those events.

So you have in real time, you have all
the information about what you have

to use and what you have in stock.

And in that case, we made a proposal
that went so far that we had Not only

an RFID tag on each box, but on the
boxes that would go to the warehouse,

but these fat parts, we were also going
to attach a Bluetooth tag because we

had a system that in mind that we could
have bought for them, but we didn't

in the end, which keeps track of the
location of these Bluetooth tags in 3D.

So they wouldn't know exactly, , how
much they had in stock based on the

production data that we gathered,
but they would also know exactly

where it was in the warehouse.

But that was a step too far for
them, so we stuck with keeping

track of the stock amounts only.

So for the time being, we can manage with
the screws are in row one and the pins are

in row two and the, the, the, whatever,

they didn't have nuts, of course,
but the nuts are in row three.

And then we just look up the product
number to see which one it is.

But yeah, then traceability is
also important because you have to

know how much you have in stock.

You have to know where it is.

Denis Gontcharov: Yeah.

I like the approach of breaking it down
to its basic principles of trying to save

money, save time or improve traceability.

I feel as we could fill an entire
episode with potential opportunities

of a unified namespace and
maybe we should in the future.

But yeah, I think we should definitely
do a second episode to delve deeper.

On this subject.

I think for now we can agree that we
have discussed the challenges of the

adoption of a unified namespace in Europe.

We also highlighted in particular,
Angelo, what companies can do

to start without fearing losing
everything, that there are ways to

do a small use case and get started.

Lucas, anything you want
to add to the episode?

Luke van Enkhuizen: No, thanks Angela.

It was as always a
pleasure to chat with you.

You're really someone who's knowledgeable
about this topic and actually does it.

And you're working on this on database.

I can highly recommend also to listeners
to check out his company Shin Choco

the link will be in the Link below
episodes, because I probably pronounced

it wrong, but I'm not Japanese.

Not my first language.

Anyway, so it will be in the footnote
and you have some great articles I

would like to refer to because , you
really make some things quite clear.

I think, especially if you're more
technical, maybe you want to know about

some publications, I recommend that.

And also took some interesting
things away from this.

I was writing this down and
you did primary use cases.

Finding out where you can make
the biggest bang for buck.

where can you make the most impact
on the smaller scales where these

things would be able to launch quickly
next to the business or building

on top of the business without
having to exchange systems therefore

giving more options to actually
experiment and having these less risk.

Yeah.

I think this is a great thing
to take with home with me for

this episode to, to work upon.

Angelo Hulshout: Glad I could inspire
you and ask some new ideas based

on the questions that you asked

Luke van Enkhuizen: Great.

Denis Gontcharov: that's great.

We'll see you in the next episode
of the smart metals podcast.

Angelo Hulshout: Definitely.

Luke van Enkhuizen: bye.

bye.