Subscribe
Share
Share
Embed
"Smart Metals Podcast," hosted by Luke van Enkhuizen and Denis Gontcharov, offers a clear and practical look into the metals industry's journey through digital transformation, Industry 4.0, and the integration of the Unified Namespace. Listeners can expect in-depth discussions that break down these complex topics into understandable segments, actionable insights, and real-world applications. Luke and Denis bring their expertise to the table, guiding you through the evolving digital landscape with advice on leveraging technology for streamlined operations. Each episode aims to empower metal industry professionals with the knowledge needed to confidently adopt digital innovations and understand the impact of the Unified Namespace in creating a more connected and efficient production environment. Join us to navigate the future of the metals industry with clarity and confidence.
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.