Luke: Hello, and welcome back
to the smart metals podcast.

My name is Luke van Enkhuizen.

I'm here together with my co host.

Denis: Dennis Goncharov.

will be diving into designing
and implementing smart factories

for the metals industry, helping
you become more productive.

The topic what we dive in today
is very practical for those

that are in metal fabrication.

We're going to talk about the
deployment of a real unified namespace,

a UNS at one of my clients and how
that went using a system called

the United Manufacturing Hub, UMH.

So let's get into it.

Really excited.

Let's go!

Luke: All right.

So Let's start by describing the use case.

Denis: Sure.

Let me perhaps start with a bit
information about the customer.

The customer in question was
a Welding shop with about 50

employees based in the Netherlands.

And the factory itself
was already quite digital.

Thanks to Luke's previous work,
but they still face two problems.

Essentially they wanted to have more
visibility into their operations at two

levels on both the L4 ERP layer, via sales
orders, but also on the level three layer

on the MES, namely in their work orders.

And the challenge is really how to unite
these two different sources of data.

Luke: Yes, exactly.

So for people listening in, if you are
a fabrication company and you are doing

discrete operation, such as a welding
shop, but also laser cutting, bending

and so forth, or milling and turning,
this will be really relevant for you.

So Indeed, the business case here
was about visibility, but why haven't

we chosen for a a system like Power
BI or anything else to deal with

this kind of visibility challenges.

Denis: I think it's a
very fair point, right?

And I think it's a good approach
to always pick the simple

solution, the most minimal.

The first question you may ask is
why not just make a point to point

connection between the ERP and the
MES system to solve this problem.

Instead we opted for a unified namespace.

Look, why did we

Luke: Yeah.

Why did we do that?

Why would you go the extra mile?

Why don't you just like use a
dashboard or make a point to point?

And I think the answer lies
really in the fact of real time.

It needs to be immediate
visibility, not later.

We wanted flexibility, as in to be
able to change things over time.

Later, add more data over time.

And I think also a major
point was also, of course, the

limitations of those both systems.

The MES system, you could
not change anything in it.

It was just a off the shelf solution.

Not a single table could
be altered in any way.

And It was more about the support
of it and also the accessibility

for that data for other systems.

We want to do something with an.

alert.

And that was also very important.

So the goal was that if
something would happen on the

factory that needed immediate
attention to manage by exception.

Somebody had to be
alert about that change.

These events that happened that triggered
that alert are near to impossible

to capture into a regular ERP system
or definitely not the MES system.

Denis: Yeah, I fully agree.

You mentioned two important points.

Indeed, the existence systems are closed
systems, which means they don't play

really nice with external systems.

They don't really want
to share their data.

And as you mentioned, they don't want to
have their tables or data models altered.

A second important point you mentioned
was the future expandability.

In this project, we were limited to
only the MES and the ERP systems.

But imagine later if you want
to also integrate data from

SCADA systems or from the cloud.

Well, you would need to put
this data Somewhere, right?

That's why we decided in the end to have
a new external system that's completely

independent of the existing systems
to unify and collect all the data in

real time, ergo, a unified namespace.

Luke: Yes, exactly.

And just to add on to that, so for many
companies listening the SCADA systems are

the system that you regularly interact
with when you interact with the machine,

the machine displays and machine signals.

Fabrication companies perhaps don't even
know the definition of a SCADA system, but

that's really when you interact with the
machine itself, the dashboarding, the real

time statistics of the machine itself.

Important also to mention here is indeed
that as well as this client that we worked

with, As well as many other companies
that would have the same challenge is

that they do not have only one system
for their company, they have various

software systems and a unified namespace
is not limited to just Operational data.

It's also very suitable for things in
other business systems, such as a second

shop floor app, or perhaps you have a
warehouse solution, or something in a

CRM that is might be interesting, like
our customer relationship management,

you can think about basically anything
that could have a place in there.

And since the client we worked at had
also already like four or five different

software systems used by the staff on a
daily basis, it wouldn't make any sense

for us to, again, make a point to point
if we in the future already know we

want to access that data from the other
systems as well and do things with it.

Not just look at it in the past, but
actually use it in a day-to-day basis

to control things, to update things
and notify based on changes and events.

What did we choose?

We went for a very innovative solution.

Something that I think many
people don't even know about yet.

And that's actually a huge opportunity
to share because we used a system

called the United manufacturing hub.

Denis, could you talk a little
bit more about that company?

Because of course you've also
worked with them already.

So perhaps you can share a little
bit about how you discovered them and

What they do in a mission and then
tell a bit about why it's a good fit.

Denis: Yeah, they are great people.

Essentially it's a startup, although
right now they're more of a scale

up made in Germany based in Cologne.

And essentially they have open
sourced to my knowledge, the first

version of a unified namespace.

This means that their entire product,
so not a demo, but the whole solution

is completely open source, which means
it's source code is freely readable

by anyone and it can be used for free.

And the way I found about them
was essentially, I was looking

to build something like that or
to design something like that.

And then I found them, I think about two
years ago that they in fact have already

developed a solution that I was looking
for and that's also how I met Luke.

We've been working with them
for quite some time now.

I have worked with them as
well as a developer advocate

writing blogs and creating

.
And Over the years, Luke and I
became really convinced that their

solution is not only technically but
also from a business context, Very

applicable to our current client

Luke: Yes, exactly.

I am also very excited
about this direction.

The reason that it's basically open
to anybody to plug into change things.

It's kind of a blueprint with various
systems already coming together.

So if you would want to make your
own unified namespace, and of course,

if people trying this in our places,
you could, you could try all kinds

of, So you could use single modules,
use things like Node RED, Grafana.

You could bolt on an historian or an
MQTT broker that exchanges the messages.

And you could do all that yourself,
but then you have to also maintain it,

you code it and the thing that they
did so well, was to make a standard

blueprint that we could use very quickly.

So it would save us loads of time to
not having to reinvent the wheel and

rely on an enterprise grade solution.

That we could quickly tap into
for free for this community

edition project to start with.

They have a valid business model, with
very good service for enterprise, but

for our business case, this small welding
shop, this was a great start to come from.

And so this is also really unique
in its way, because there are

many other solutions Like ignition
that you could do it with.

We could use high bite and there's
a great projects by themselves,

but I think they're a bit overkill
for what we are doing here.

And they are also, I think, aimed at
a different audience in my experience.

How do you think about this?

Dennis?

Yeah.

Hmm.

Denis: we could call it
more of a proof of concept.

And in that sense, the open source
low cost or better to say, no

cost played a major factor, right?

If you compare it to like a 20 K license
from high bite for a small welding shop,

that's becomes a very simple decision.

Luke: Yeah.

Denis: One more thing I
wanted to add is that.

Look, essentially the
factor was shown to me.

I was surprised by how digital it was.

Like a lot of the colleagues on site
already use technologies like Node RED.

And as you know, these technologies are
exactly a core piece of the UMH, which

is again, one of the reasons why we chose
the UMH over let's say HiByte or Ignition.

Luke: Yes.

So this is very important
to emphasize this indeed.

I think many companies
nowadays struggle with finding.

young and motivated
people and to keep them.

I am of the strong opinion that a lot
of people have hobbies many younger

employees, their hobbies revolve
around something with technology.

If you ask around your factory, there's
probably some person working with

some home automation, some projects.

And very often these technologies, also
already contain a lot of IoT technologies

because home automation is kind of IoT.

It's just not for industrial
solutions, at the moment.

I think it's really cool that need
the company worked with, there were

already some people, some young people
there that had this Node RED knowledge.

The programming.

So to put them the company data that
they would need, like not everything,

what we selected for the project.

So work order data and sales
order data that were limited.

We made a limited exposure
because we could make our own

database in a unified namespace.

Meaning we don't have to expose the
entire ERP system to that system.

We only expose what we have imported
in our data model that we think it's

allowing them People to in the team,
to then work with that data in a

safe way in a fun way to then learn
how they can further expand this.

So this is a major thing to emphasize
here that if you put that technology

in the hands of the team, then it's a
Kickstarter for a huge transformation.

And they had already a lot of
digital solutions on the shop floor.

It's one of my clients.

So obviously little plug here, but they
had already like shop floor control apps.

And so the factory was already paperless.

They already had a system for
them for the laser cutters.

They're also fully automated,
paperless, integrated.

Uh, they had an EOP system on them.

So those things are already in place.

So the next step afterwards
would have been the.

The automation step to do more with that
data, to, you know, to analyze upon it,

make it real time and, you know, to do
all kinds of creative things that you

normally couldn't think about doing.

So yeah, that's really part of the
decision process to offer the solution.

Let's dive into the experience then.

Denis: Yes, exactly.

I mean, the first point I can
mention is that one thing that in my

opinion contributed to the success
of this project was the client's

excitement for everything digital.

Like, as you said, they were already
aware of the capabilities, the

client themselves came with a lot
of potential ideas for the future.

So, I think they had the very
right mindset from the beginning as

viewing the unified namespace, the
way we installed it as a foundation

for all their future use cases.

Luke: Yeah, yeah, definitely.

The motivation was there.

Again, it really is about, uh, doing
something that is a business case.

So a big frustration they always had was
that these systems would go out of sync.

So you have many software systems

For example, if you have work
orders that you have to produce,

they can exist in various places if
you have various software systems.

If you have a shop floor app, if
you have a manufacturing system,

every machine comes with its
own system nowadays as well.

They also need their jobs to run on to.

And so these things can get out of sync.

And the frustration I had sometimes is
that the point to point connections,

funny enough, would sometimes not work.

Disconnect, they would get behind.

There would be issues with an XML file,
having some illegal characters, which

the whole thing would then not even
arrive in the other system, leading

them to manually override the system and
forget to then clean it up afterwards.

So there would be this continuous problem
that I had to fix things that just Went

wrong because the systems themselves
were so fragile and no matter how great

you are in development with it's point
to point, there's always going to be

some pesky limitation of one of the two
systems that will cost these things.

And especially if you have various
systems, um, people can forget things.

And that is also things
you want to make visual.

So that was one of the things
that we're frustrated about.

And what their dream was, we really asked
them, what is your home run scenario?

How would this project be, you
know, for you, the ultimate outcome?

And they said, well, if we can do
something that, If one of the people on

the shop floor tells that they have an
interruption, that immediately everybody

gets notified with some kind of light
going on and if we can immediately

see if at one of their workstations,
the work order is getting late.

Or we work on the wrong work
order, that could also happen.

Then we want to be notified about it
in real time so we can immediately

make sure that schedule is adjusted and
immediately solve that interruption.

And, so it's so cool that they had
these clear ideas of wow, if that

would be possible, that would be
so cool, we just have no idea how.

And that's, I think, the best
question to answer when people

like us want to dive into it.

So, that was really great, the excitement.

Second point, why it was great.

I think that Yeah, the, the product
itself, UMH reserves a lot of praise.

It was really we're pushing
it to the edge, right?

We push it to the limits by creating
our own custom solutions in it.

We didn't do anything standard
in the sense, that we didn't

use it just as an historian.

We made a full basically a full
MES system out of it, right.

With our own tables and data models.

Can you talk a bit about that
process, Dennis, like how that went

and why we opted for that reason?

Denis: Yeah, sure.

So essentially the UMH provides the
ability to construct what we call a

data model, which is essentially the
tables you have for your data and how

these tables react between each other.

So what relationships you have?

The challenge is that every factory
is always a bit different, right?

And M.

E.

S.

As we will see in the future, episodes
should be built for your business.

In that sense, we wanted to have
the ability to create the organized

data in such a way that it makes
a lot of sense for the client.

The client can easily understand where the
data is located and how to retrieve it.

And the UMH allows us to build
essentially our own MES system with

our own tables and our own relations.

And that's what we managed to fully
leverage thanks to their technologies.

Luke: Yes, exactly.

Yeah.

So very important.

You're the manufacturing execution
system for your factory is not

the one you buy, but you build it.

And I must give credit to Walker Reynolds
from for our solutions that kind of also

nudged us in that direction more and more.

So I feel we cannot take credit where we
invented everything, but the fact that

we took this concept of a UNS and that
we took that idea of building your own.

And then putting that into the super
innovative UMH solution and bringing

those worlds together, allowing them to
make something super cost efficient for

SMBs, allowing them to use all that.

Automation, I think it's really wonderful.

And so of course we needed to
have a lot of things in place

already, like the systems.

Second part was we needed
to get access to everything.

The client was very good in giving us
the confidence to access everything

remotely over a secure VPN connection.

And.

Last definitely should be said, I think
the community around image without

the community, we wouldn't have to
be able to pull this off for, for

a company, this size that we worked
with, it would be definitely, not in

scope to hire like dedicated consultant
of a software system to come for

a couple of days to help us debug.

We need to be able to figure out things
ourselves, check everything, and then

rely on a community that helps us out.

And of course the support from
them, but mostly it was very

important to get great help.

Denis: Yeah, that's true.

I mean, let's focus on the
development process themselves.

Like what did the actual work look
like in essence, we did not spend

a lot of time on the client's side.

I think the beauty of the UMH is that
it follows the it best practices, which

means that Luke and I managed to develop
pretty much everything we needed before

we even showed up there at the client.

And then in one single day, We managed
to completely deploy and install the

UMH as well as our use case and test it.

And by the evening, before we went
for dinner to celebrate the success,

we had everything up and running.

Luke: Yes, this is also
like a 10x improvement.

We nearly forgot about that.

Not only the cost for the client,
getting it off a 10th of the

cost that it would normally pay
for even anything close to it.

We also did it in a 10th of the time,
literally in one day, we went to the

factory to basically install everything,
create a tables and deploy it.

And it worked, that was
really a fantastic experience.

That feeling, if anybody that did
any it projects, that feeling when

it works, when this really the light
switched on, in our case, it literally

switched on, that was the best feeling.

and also for the clients, cause
they knew immediately that it was

successful, everybody knew that when
the light switched on, it would be

successful and we managed, right.

I think that's really great
way to emphasize on this.

So yes, we needed to do a lot
of work upfront ourselves.

We spent our time on that, but that's
an investment we make also because we

want to be knowledgeable about what
we talk about and great help from the

community with all our debugging of
course, but once we get all two of that

and we figure it out, we managed to
build something really awesome, I think.

Denis: Yeah.

I won't forget the moment where we
shot in some data into a message queue.

And a few seconds later, the light bulb in
the office out of nowhere just sprang on.

It was an amazing feeling to see
something in IT have an effect

on something in reality, right?

Luke: Yeah, the real I.

T.

O.

T.

convergence in real action.

So how it worked just to
clarify quickly what we did.

The system worked as following:
we had multiple data sources.

Going through Node RED, going to the UMH,
which uses Kafka as the messaging queue

system, which then was written into a
timescale database, which is a historian.

It's a Postgres database.

And That then was being monitored
by Grafana, which then checks in

the dashboard how things are going.

Grafana has a 5 second polling rate
approximately, I think we set it to.

And then, uh, then that would
trigger an alert from Grafana.

And then Grafana could alert the user.

Anything, whatever we wanted.

And that would then call a
webhook, which then would activate

a light in the factory, which
connect this into that webhook.

So that was kind of the, the whole
thing, how it comes together.

Now you could say, why doesn't
somebody switch on a light switch

by themselves and that works?

Well, of course you could do that
for one light switch, but we are

not thinking about one light switch.

We're thinking about
lots of other use cases.

And, you know, you want to make
sure that they can never forget

to switch on the light switch.

In this case, you can't because it's
an alert and it triggers and it locks.

You have a history.

You can find anything back.

So yeah, really cool stuff.

And if anybody has questions about this
project or interest in this similar

business case themselves just shoot us
a message we're happy to chat about it

because we are definitely exploring how
far we can take this open source stack

for also larger scale implementations.

So yeah.

Great.

Let's talk a little bit
about the challenges then.

What, what were the things that we had
some, yeah, some learning to do for

before we could implement it at scale.

Hmm.

Denis: there were, I mean, you can't
have innovation without some challenges

and even with some, maybe even some
frustrations and failures along the way.

And I think we ended our last
point of experience with the

great community of the UMH.

And I think it's so important to
highlight this here again, because

thanks to the UMH being open sourced
and having a big community around it,

we managed to get the right help at
the right moment when we needed it.

Because as you can imagine, whenever
you use a technology for the first

time, even though we both knew the
UMH, there were some components, like

for example, the bentos, UMH bridges
that we haven't really used before, but

together with the community, by sharing
our mistakes, we managed to co create,

for example in essence, a solution
that worked and get the help we need.

Luke: Yeah, definitely.

It was weird.

The bridges, building the bridges is
what it's called, but we were literally

building bridges between the old and the
new world, but we also actually building

data bridges, which was, I think the most
challenging part to define your database

structures, how you want things to be.

And then to relate them to each other,
make the schemas, and then defining how

that would fit into the bigger picture,
if you want to change things and that

they actually would work and update.

It's a lot of more technical stuff we
did as well, like with confirmations

of imports and updates and changes
and deletes with MQTT there, so

you could also update other systems
if our database would update.

It's also important that we
could forward these messages, but

yeah, really, really interesting.

I'm super excited about that.

That's a nice bridge, pun intended.

This is a nice bridge to what lessons
learned are, uh, what will be your number

one lesson learned from doing a hands on
UNS implementation using open source UMH?

Denis: I would say it's the
importance of community.

It's just really nice to know that when
you get stuck, that you can get help.

And in terms of help, both during the
project, but also it works both ways.

After the project, we had a debrief
call with the CTO of the UMH

Germany, who was actually really
interested in our results in our work.

And this allows us to give feedback, which
in turn improves the product even more.

Luke: yeah.

That really shows the
mutual interest for success.

And I think that's great.

My second lessons that I would add
to this is that you don't need a

specific business problem to initiate
a discovery project, because funny

enough, I think we discovered.

10 other business problems we could
solve while we started building

this first iteration of it.

That was really a fantastic idea just
to see everybody in the rooms, like

seeing the light bulb go on literally
and thinking, wow, if I can do this,

then I can do this, this, this.

And the next day I actually got an email
from the customer with like 10 other

ideas he had for the upcoming year that
he would want to implement over time.

Which is just, that's the best feeling
because like, it's just excitement.

It's not frustration.

It's not like with an ERP implementation.

Oh, this isn't working right.

This is not working right.

Here is a bug.

This database isn't reading well.

No, no, it was really genuine excitement.

Like, wow.

Now we have this in place
look what we can do.

I think it's a completely
different conversation.

So.

Lesson learned is that you don't need
to start with the perfect business case.

I think a direction is enough
for a proof of concept.

And by having the ability to start
so small and so low budget you know,

we are like below 10K for the total
spent for the you know, for the setup,

for the initial proof of concept.

Uh, that's wonderful, right?

That's, that's where you
can really experiment.

That's when there's also almost no risk.

And then the customer
and you get creative.

To then look at what's possible.

Further project might be a bit
more work and maybe take a bit more

investment to, do it completely,
but then, you know, where you stand

and what's possible that it works.

So that was for me a
really great motivator.

Denis: Yeah, precisely.

And I this is a great segue into the last
lesson learned from my side is that the

UNS, the unified namespace, works, right.

And very important to keep in
mind what we have delivered.

Yes, we did solve the use case we defined
at the beginning, but in my opinion,

even more importantly, we built the
future digital foundation infrastructure

for this client, which means that
whenever he now has an additional

idea in the future, we already have
everything we need in house to make it

possible even faster than this project.

Luke: Yes.

Yeah, exactly.

You have a a framework.

You are freed from the shackles of the
limitations of your past systems where

you have to bring all these different
software companies together then to

see what the limitations of each.

No, are just saying we are making those
connections once, once to the EFP, once to

the MES, once to the other shop floor app.

Once to whatever comes next, and of
course, you will expand it by various

endpoints is what you call them.

So you can, of course, expand
what is exchanged here and there.

But in the essence, once
these connections are made.

You don't have to go back to the drawing
board to get that connection made again.

If your data is yours, you can
do with it whatever you want, and

you're in full control with it.

And you can therefore go like 10x faster
for sure, if not faster with any digital

transformation project afterwards.

And I'm absolutely
convinced this is the case.

This is speeding up things.

, and I've done my fair share of projects
in the last like eight to 10 years of

being on my own as a consultant, it's
really like, I know exactly where they all

struggle and that's exactly in that part.

Like you have a great idea.

But your data gets stuck somewhere.

Something's not really possible.

Something needs to be debugging.

You just need the right person
at the right time from a certain

company to help you out, which
of course isn't always available.

And, the knowledge is very
proprietary about this product,

products you, you interact with.

So it's just way more efficient
to get everything out and

find how you can write to it.

And that's it.

And then, you know, let
the systems do their thing.

I see definitely a lot of potential also
now to start hooking up machine data.

And also combine the O.

T.

I.

T.

Systems even further, right to really
see what's happening on the factory floor

for each work order and continue that

great.

So last topics on this episode,
Dennis, what would you think?

For any manufacturer that is interested
in this, what questions would they have

and what kind of questions should they
have before they consider doing this?

So who is this for kind of question?

Denis: Yeah, frankly, I would to prevent
making it sound scary because in reality

it's not, I think this is a really
last look as mentioned, a very low

risk, minimal time investment project.

So the question that you should
really be asking yourself

is what are you waiting for?

What are you afraid of?

I just identify one small problem.

It doesn't have to change your
whole factory and just give it a go.

I don't think you have a lot to lose.

Luke: Yeah, exactly.

Cause you don't replace your
systems you built on top of them.

Even the company that
has already was so far.

Everything kept running.

Matter of fact, there was already
some kind of Power BI dashboard.

It just wasn't good enough and not
having something good enough is a

great place to start 'cause you have
something that you can always go back to.

You can only make it better without
having to overhaul everything without

going to like multi-year project.

No, we are looking here about a month,
maybe 30 days perhaps if you want to

kick it up a notch and do a workshop, you
could add include two other months with

training and getting more above the speed.

But.

And we're looking in essence here
at like a 10 X time safe and cost

safe to just get this in the hands.

And yeah, we did a fair share of
research with looking at alternatives

to find out, would it be better to
use any of the other names mentioned?

And like I said, they are great products.

You can do a lot with a
lot of other platforms.

You can do great things
with, uh, visual automations.

You can do a lot of great things
with generic ERP systems as well.

But they have their
limitations either in price.

You cannot compete to that.

You cannot compete with its
openness, its flexibility.

It's not open source.

So.

You know, there is going to be
limitations in any of these choices

that you would still rather use
that for your first initials steps.

Also think about it.

If you have to pay for licensing,
that money is basically the money you

would save that you could put directly
into a project and to get even the

licenses, you have to first buy it and
go through the whole sales process,

which already takes way too much time.

So why not just start?

So that's also where I'm a bit.

Yeah.

Denis: Yeah, essentially.

Yeah, I agree.

I mean, to answer your question more
directly, in essence, this is a great

opportunity for any small to medium
sized business manufacturer, right?

To get access to enterprise grade
software at a very low cost.

So to answer your question more concretely
if you're unsure if this would be a

good technology for your business,
just reach out, ask your questions.

We will share our knowledge.

And this way.

We can see if the unified namespace
is a great solution for your company.

Luke: Yes, exactly.

So if you're even if you're not in the
decision making position yet, that's

great because matter of fact, I think,
you know, more about the project than

anybody else, and that's awesome.

So we are here just like
the community helped us.

We want to work with the community
we want to definitely can help you

get started if you're in metals.

And if you are in SMB, your company
could be a bit bigger, and you are having

about doing something with a UNS our
contacts are below and we are happy to

have a chat with you about your digital
transformation and how that would fit in.

I think that's it for this week, Next
episode is upcoming looking forward to do

interviews with various industry experts.

we have a word with maybe the customer
himself the guys from UMH, uh, what else

will we have in the upcoming pipeline?

We can expect various deeper dives
in also the, yeah, the system

you would need on a daily basis.

What can you do when you have a
UNS and for the rest, stay tuned.

Denis: Stay tuned.

Thank you for listening.

bye.

Luke: bye.

bye.