OPC UA vs. MQTT – Getting data out of 100+ machines

Madeleine:

Hi and welcome, dear friends of IoT. This is your podcast about real-world implementation of IoT and IIoT projects. I'm your host Madeleine Mickeleit, trained as a mechanical engineer, and many of you tell me the same thing: Your machines are old, from many vendors, and every one speaks its own language. So what's the best way to get the data out?

And today we look at a real customer project in Finland, part of an international manufacturing group, and they have more than 100 machines in one plant, built over many decades. The team has one big question: How can we connect and move all this machine data? And today in the podcast, for the very first time, we are looking at MQTT versus OPC UA. MQTT and OPC UA are two great ways to connect the machines, but which one do you use and when? And is it really one versus the other, or can you use both?

Pyry, my guest today, has a clear view on that, and that may surprise you. Pyry Grönholm is CEO of Prosys OPC. He is in the field for almost 30 years, an absolute expert, so a great session with him. And we also had a great discussion about AI: how AI can set up the variables of a new machine in your IoT platform, so you don't have to do it by hand. Pyry's team tested it, and he has some really nice insights about that. So have fun with this episode. Let's go!

Hi Pyry, welcome to the show. Great to have you. How are you today? And by the way, I hope I pronounced your name correctly.

Pyry:

Thanks, Madeleine. It's really great to be here. And don't worry, my name is hard to pronounce for foreigners, but you're doing great compared to most of the others.

Madeleine:

I'm so happy that you're here today in the podcast. You are the CEO of Prosys OPC and an absolute expert of IT/OT integration, also AI for OT and OT security, OPC UA, of course, and MQTT. So I'm very happy to have you here in this specific episode today. By the way, where are you based? Because you're not in Germany, right? Where are you based right now?

Pyry:

Prosys OPC is a Finnish company. We are based in Espoo, Finland. It's in the Helsinki metropolitan area. This is the technology hub of Finland, so a lot of small and big companies, but especially the technical universities nearby. In this area, some of the most hyped Finnish companies nowadays, like ICEYE or IQM, are located.

Madeleine:

Then shout-out and greetings to everybody who's listening from this area – or maybe you're listening in the car, while you're doing sports, anything like that. So welcome, and great to have you all in this episode today. For those who don't know Prosys: You're a leading provider of OPC UA and OPC software products, with over 30 years of experience in this field.

Pyry:

Yeah, if I may, I would say that OPC UA is the core technology that we master. But eventually OPC UA is just the technology. It doesn't really bring value for the customers by itself, but utilizing it the right way does. And we at Prosys OPC try to use OPC UA, but also MQTT and other technologies together, to make as good solutions as possible for the end customers for their IT/OT integration. So eventually we are about IT/OT integration, but of course how we solve it is using OPC UA when it's feasible.

Madeleine:

So yeah, as you were mentioning, it's just the technology, and then it's about what customers do with it, and why they need the architecture for different use cases. When we talk about OT/IT data integration – I mean, you are in this topic for so long. You also write a lot, you're publishing blog posts, I guess almost every few weeks. And I would love to learn from your experience: What's the biggest thing you were maybe wrong about, that you've had to learn or to unlearn in the last years?

Pyry:

I try to always be on top of the edge. Whenever something new comes, I try to understand it. And I also use the blog to sort things out for my own thinking. When you publish something with your own name, then you know that you do it in a way that it's quality stuff that you publish.

Madeleine:

So what's the biggest thing you were maybe wrong about back then?

Pyry:

I've actually been in the company for 29 years, and I started as a trainee. It was very handy: Our office is located near the university, so I could go back and forth between the office and the university those days. But the industry hasn't changed too much within these years. The first thing I did was an OEE reporting for a digital printing press. And nowadays, for example in this case that we are presenting, we are still coming back to the same topic. We are creating OEE reporting as well.

But if I would say that there is something that me and the whole company have been wrong about, it has always been the speed of the adoption of new technologies in manufacturing. We have put a lot of effort into OPC UA, for example, for almost 20 years, but right now I think it starts to get the adoption that it deserves.

And there are a lot of new technologies that could be very good, but nowadays I have probably learned: Don't go too fast with these new technologies. The investment cycles in manufacturing are like 20 years. They don't welcome new stuff that well, because they want to be able to run old machines and systems for another ten years or something like this anyway.

Madeleine:

Yeah, that fits what I see. I've worked in the market for about eight years now, and on the shop floor, connectivity has not changed that much. But every month there are new products and new buzzwords that providers are pushing into the market. So from an OT/IT view: What has really changed in your opinion in the last years, and what is maybe just a new name for an old idea?

Pyry:

Well, I still hang a little bit on these new buzzwords coming. And that's exactly what I mean: I have learned that even if there is a new buzzword, it doesn't mean that it gets adopted very easily. I would say that, for example, I'm extremely enthusiastic about the Web of Things right now, but I still know that it will take a few years before it gets adopted, if ever. But still, it's supported by our products, and it would enable automated asset onboarding. So it would really speed up the IT/OT integration a lot.

Madeleine:

Now you're mentioning Web of Things. Web of Things is used across many domains, from smart home to industry, and I hear very different definitions of it. So what do you mean by it in an industrial setting, and what does it change when you onboard, for example, a new device?

Pyry:

Web of Things is actually a standard. It means that whatever asset you put in the plant, it comes with something called a Thing Description. That is an information model and configuration instructions for that asset. If you have, let's say, a system like our Prosys Forge – but it could be any kind of client software in the IT/OT integration – and you upload this Thing Description and you support it, then you just give the IP address of the device, and it will be automatically onboarded. So it creates all the variables, all the context and the connectivity for the device for you. There are already at least Siemens products that are shipped with the Thing Description.

Madeleine:

So it's what I normally have to do manually, for example in my asset management application, where I say: Okay, I have a new sensor, I have a new gateway, whatever. I have to do what you're mentioning, all the variables, I have to put them in. So all this manual work would not be necessary because I have this feature.

Pyry:

Yeah. And quite frequently, let's say if it's a Modbus device, there are no variable names, there are just registers – register 1, 2, 3, 4, 5, basically. So now the Thing Description will tell you, for this register, what the name of the variable is, what the actual value is, what the engineering unit is. In some cases you even need to tell whether it's an integer or a string or a float in that register to be able to utilize it. So it gives all that information. Instead of having some specs or an Excel where you look it up and then type it into your system, it just does all this work automatically.

Madeleine:

I see. That's quite interesting. In episode 242, we talk with Cumulocity about a related problem. Their AI agent reads the raw data of a new device and proposes the mapping, so nobody writes it by hand. By the way, if you want to hear more about that, listen to episode 242 and follow this podcast, because there are more AIoT projects and customers coming who tell how they do it.

But now back to the topic. You and the company work a lot with those open information models. Have you tested AI for this at Prosys? How well did it work, if you have?

Pyry:

Yeah. You could use AI to create these Web of Things descriptions for your assets. You give it the documentation that you have about the asset, and then you just tell it: Hey, this is the standard, please create me the JSON file for the asset. And then you could just upload it, and it would be onboarded automatically. So in a sense you can use it. But we actually did a master's thesis within the company about this AI-assisted data harmonization.

Madeleine:

What was the outcome?

Pyry:

The outcome was that, at least with the models that we used at that point – it was half a year ago, which is like a decade in AI – the results were something like 60, 70 % correct. It depends a little bit on how you calculate, because we categorized them: those that we were certain about, those that were likely okay, and those that were most likely wrong. So the system automatically mapped something, then it gave you something as an input for the end user: Can you check that this is correct? And then it discarded some variables totally: I cannot find anything for this. And together about this – but still not perfect.

Madeleine:

Right, right. We will have new and better outcomes in the end. But now we're at the new topics here directly – very interesting. We will talk about your product Prosys Forge in a second. And also, if you're listening now, we will talk about OPC UA and MQTT in a second. Do you have any project we could talk about today, more in practice? Can you set the scene for us, to learn what your customer is doing?

Pyry:

Yeah. In general, of course, our customers vary a lot. We serve basically all the industries, process and discrete: heavily regulated pharma, a little bit less regulated like aerospace and defense, and food and beverage, and just basic machine builders.

But today I was about to talk about one of our recent cases. I unfortunately cannot tell the end user's name, but it's a machinery plant in Finland that is part of an international manufacturing group. Discrete manufacturing. And the challenge in that case was that it's a rather big factory, and the machine park is very diverse. It was built along the decades, I would say. So there are machines from several vendors, and they actually do very different things. Even the CNC machines are from several different vendors and different generations.

And the starting point was such that we had machines that had very nice and easy connectivity. Then we had machines that didn't have any connectivity right away, but it was easy to figure out a way to create the connectivity for them. And then there were machines that were kind of abandoned – for these ones, we were just not able to easily get any decent connectivity, at least in the first phase.

Madeleine:

Okay. Do you have any examples of which vendors these are and what type of machines? Bigger machines, smaller machines?

Pyry:

Well, I probably wouldn't like to say too much about the names of the vendors.

Madeleine:

Like the typical ones: Honeywell, Siemens, WAGO, you name it, ifm sensors.

Pyry:

Well, the CNC machines were mostly based on SINUMERIK. The actual vendor could be different, but the connectivity was mostly to the SINUMERIK. But there were all kinds of machine types: There was cutting, welding, presses, there was painting, and in total more than 100 machines.

Madeleine:

Okay.

Pyry:

Quite much. And honestly, I haven't seen them all. But of course the most valuable machines were the CNC machines, and we also concentrated a lot on those. Also the presses were important, in the sense of OEE, which was the starting point of the project.

Madeleine:

I see. So OEE was one example project where you started with them?

Pyry:

This was the starting point. Actually, what initiated it, that they wanted to work with us, was that they knew that the new MES project was starting in a couple of years – actually less than that, in two years. At the same time, they understood that they don't really have a very good understanding even about the connectivity. And even if they had, they knew that they don't have the connectivity for all the machines that would be required.

So what we started to build in the first place was – what we have with Prosys Forge is one platform where you bring in data from all of your machines. Then you harmonize the data using OPC UA information models. And then you open up the different IT protocols – or of course OPC UA can be used as well, as it will be towards the MES, but for other systems you use REST or MQTT or whatever. Anyway, they felt that they need to prepare somehow, so that the MES project in the future would go smoothly. But then we started to think about that: Okay, well, it's very hard to work with the connectivity if you don't have a project where you should do something with the data.

Madeleine:

For the business outcome.

Pyry:

Yeah, outcome. So this is why we then realized that their old OEE system was outdated and didn't give them the data that they were looking for. So we proposed: How about we start creating an OEE system that replaces the old one, that would give you more accurate data, more standardized data compared to the old one?

Also, they asked us to create a dashboard of all connected devices, so that they would know the status – whether they are running, stopped or in an error status at the moment – as well as some kind of trend of the statuses. Whoever is running a part of the plant could have their own view and see right away how it's going in their department. And that's how we started, and then we started to add machines one by one to this system. And for both OEE and the dashboard, we had one information model, an OPC UA information model, where we put the data and then integrated it into either Power BI or the Grafana dashboard.

Madeleine:

To bring that into your product, which is Prosys Forge – it's an IT/OT product, I would say. So you could connect all your devices from the OT and then bring them to the next level in the IT area. Why did you choose OPC UA here? And what did you do with machines that are not so easy to connect, for example really old machines? Because it's a challenge for everybody working on the shop floor to get the data out, maybe also from old machines which are not OPC UA ready. How did you do that, and why did you choose OPC UA? Was there other technology involved?

Pyry:

Well, in Prosys Forge the core is an OPC UA server, but we don't really care how the data gets to Prosys Forge. We can use the vendor-specific protocols, of which we support a wide range. Or if you'd rather use MQTT or REST to utilize the data, that's totally fine. But still, within the product we have this ISA-95 tree hierarchy of the plant, and you have the standard information models for different machines.

So in this case, they had a status information model, which was the same for everyone. The OEE information model, which was the same for everyone. And now, when we are leveraging to the MES, each machine will also get the MES information model, which will also be the same for every machine. Of course, if we would start storing, let's say, quality data or something like that, then each machine would be different, and each type of machine would require its own information model. The presses just have totally different variables than the CNC, so you cannot force them into the same model. But still, you could have one model for every press and one model for every CNC.

So we just feel that OPC UA is providing an open standard for information modeling. And then the customer actually owns the model themselves. It's not a proprietary model that you hire, because it's inside a system where you can model, but you cannot take the model out or reuse it anywhere. In our case, the models actually could be taken out and put on the PLC, for example. So it doesn't need to be harmonized on the edge level – already the PLC can provide the data in OPC UA information models; Siemens PLCs, Beckhoff PLCs at least can. So this is the reason that we use OPC UA within Forge as the data modeling, but it's not about the connectivity.

In our case, the existing OEE system had already installed a lot of gateways in the factory that were wired to the PLCs which didn't have connectivity. And then we used Modbus to communicate with those gateways, and this is how we were able to get the data for the basic models. Of course, when the MES project came into place, we didn't have enough data from those Modbus gateways. So they bought OPC UA servers everywhere it was possible. If it was not possible, then we used the direct Siemens or Beckhoff connectors or the EtherNet/IP connector. I think Modbus was only for those gateways.

And in some cases they actually replaced the PLCs, or they bought a new PLC next to the old PLC. And then they just made wiring between the control PLC and the data connectivity PLC. This was more or less the basic ways to overcome the problems in the connectivity.

Madeleine:

I see. And in our community, a lot of people use MQTT, of course. They use different technologies. OPC UA is a set standard, I would say. Could we say it's MQTT or OPC UA, MQTT versus OPC UA? So which one actually wins for industrial data? It's a bit provocative, but what I want to ask behind it is: Is there a specific use case for the different technologies? You know what I mean?

Pyry:

Yeah, I know what you mean. You know, my five seconds as a star on LinkedIn was when I wrote an "OPC UA versus MQTT or OPC UA over MQTT" post, something like four, five years ago. I don't remember how many impressions it got, but it was anyway something like …

Madeleine:

More than 100,000?

Pyry:

More than 100,000, way more. That was my five seconds of fame. So in my world, both technologies are great. They are very different in a sense. I think they are meant for different purposes. Of course, OPC UA is an architecture. Everything is included: It's the transport, it's the information modeling, it's the security. And MQTT is more or less just a transport. If you use MQTT, you need to have a separate agreement between the publisher and the subscriber on what the payload is.

Madeleine:

So with payload, you mean usable data?

Pyry:

The payload can be just plain text, or it can be some binary, or it can be JSON, or it can be XML. And you need to exchange the schema of your payload between the publisher and the subscriber, because otherwise one is waiting for JSON and the other one is sending XML, for example. So you cannot interpret the data that you are receiving. For MQTT, there is Sparkplug B, which provides the structure or the payload standardization. But then it has some other problems – I won't go too much into that – why it hasn't really got a lot of adoption. At least I feel that it's going down more than up right now.

Also, OPC UA has connection monitoring, it's request-response, while MQTT is more like: You send the data, and then you need to build the logic yourself if you want to get a response to what you sent. It's not built into the protocol, at least in those versions of the protocol that we typically see currently. So this is why I feel that OPC UA is very good when you are close to the PLCs, to the control level, because it enables you to actually be certain that what you requested happened. You can do the standardized modeling, and it's more like plug and play.

But if you need to send data to the cloud, then MQTT is quite lightweight. It has very good performance, and it works very well for those purposes. And then, like I mentioned, there is Sparkplug, but of course there is also OPC UA over MQTT, which is an OPC UA standard for how you use the OPC UA payload and OPC UA topic trees and all this, which enables more of this plug-and-play connectivity also for MQTT.

I think our standard approach in Prosys Forge is that when we connect to the cloud, we always use either MQTT or AMQP – AMQP in some cases in Azure, because it's cheaper to use Event Hubs, which doesn't support MQTT, but only AMQP. But as protocols, they are very similar. I don't think that they compete. I think there are more like different use cases for different protocols. And there are even more protocols than these two competing in the field right now.

But hey, one thing to say here: If you want to understand this topic very well, on LinkedIn Matthew Parris is writing a blog series about going beyond the proxy war between OPC UA and MQTT. It will take a couple of hours to read through those, but it's a very, very well written series.

Madeleine:

For those who don't know Matthew Parris, I will also put his LinkedIn. He's writing a lot of stuff about this, so follow him, he has a lot of things on this topic. But I guess a lot of listeners are not too technical – and to be honest, I guess you lost me when you talked about AMQP and what you mean with Azure. I don't know this stuff, and I don't know how technical we should get here.

I want to frame a bit what I understood so far. Could I say that MQTT is more like the "send and hope" principle? So you send it, and it's for monitoring, for reading status updates. That's great: It's fast, it's lightweight, and it scales to thousands of devices. But OPC UA is more than just send and hope. Could you say it like this?

Pyry:

In OPC UA, it's more like when I now speak to you: I see immediately if you heard me and you respond to me. While MQTT is more like posting something on LinkedIn. You know that it's on LinkedIn, but you don't know who is reading it. So you don't know if it ever reached the audience or someone that you actually wanted to reach, but then it's easily available for everyone and very lightweight. So OPC UA is point to point – you and me – while with MQTT you put it on the broker. You know that it went to the broker, but you have no idea who is actually listening to the broker.

Madeleine:

Okay. And maybe one last thing to ask here, because the OPC Foundation is also one of our partners, and Stefan Hoppe, he's the OPC Foundation representative …

Pyry:

The president.

Madeleine:

Yeah, the president. And they also started this cloud initiative reference architecture, where there are a lot of different building blocks they work on – not only the transport, but also preserving the information's context. For example, when you have a CNC machine, you have the context of the different variables, you know what I mean?

Pyry:

Variables, yeah.

Madeleine:

Variables which you need, for example, in Azure, to make sure that you have the right end-to-end communication from OT to IT. So how would OPC UA over MQTT solve this? Is this one of the building blocks they are working on? Just to make sure that we have the representative statement from them here, right?

Pyry:

Well, the good thing, or the beauty, of OPC UA over MQTT is of course that you are able, to some extent, to preserve the information model that you had. It's not compulsory to actually utilize it. Well, you would need to combine it with something called the OPC UA Cloud Library – but now we get very technical again. Together these two standards within the OPC UA umbrella allow you to create digital twins in the cloud of what you have in the plant.

In the plant you have very critical operations, and you don't want anyone to mess them up. And now, if you want to copy the data from the plant as such, in the same format and with the same information models, to the cloud, you need some very lightweight way to just publish the data. So when you use OPC UA over MQTT and you have the same information model in the cloud as you have in the plant – or of course just part of it, or just one device or whatever – then you can create the digital twin, so that it looks exactly the same as in the plant, and the data goes fast with MQTT between these instances.

Of course, you can then build all the cloud reporting, analytics, everything on top of that data. But instead of the data being just "this variable has a new value", you have the whole context in the cloud. You have the blueprint of the plant where the data starts to appear.

Madeleine:

I think it's also relevant to see what use case is behind that. When I have, for example, a single remote asset, like a water pump station, sending directly through OPC UA makes sense, for example. But it's scale if you have, I don't know, 5,000 PLCs – or what you're mentioning with a hundred machines, I don't know how many PLCs are in one factory. So you have to make sure that the data delivery is sure, also from security and manageability.

Pyry:

Yeah, and of course that's one good point with MQTT: When you just send data from, let's say, the edge between OT and IT, there is no connection needed downwards. So you can have a hard firewall that is not really opening anything down to the OT – which is never secure, you know; there are all the devices, so something always needs updating. So you need to really protect that.

So with MQTT it's one way upwards, but nothing goes downwards. And MQTT is very handy for that use case. It's easy to build it like that, or to protect the OT network while you use it. And it's lightweight, fast, everything goes smoothly. But it has the problems that I mentioned: You need to agree on things – if you encrypt the data, how you did it, both ends need to know it, and so on.

Madeleine:

Yeah. By the way, if you're interested in discussing that more, for example on the user level: We also have our user group, which meets every month, and they talk a lot about scaling and costs and how to do it. For example, when you have a solution which works for three machines, it's good – but how do you do it when you have 300 or 3,000 of them? How does the scaling work? So if you're listening now, please feel free to join our user group. Or if you have more technical questions or want to learn more about how IT/OT integration works in the right way – I could also post your contact details in the show notes, right? To have a contact to you.

Pyry:

Of course, I'm always happy to discuss this. And I also feel that all the conversations are always great, because I don't say that I'm always right. It's how you learn and how you get new ideas. For example, from the LinkedIn discussions that I have participated in, I have learned a lot. Even our products have been adjusted – the feature roadmap has been adjusted based on those, because I have realized: This is something I haven't thought of before, and this is important.

Madeleine:

By the way, you have an incredible network within the various standards communities that exist. Do you have some recommendations where you say: Hey guys, when you want to learn more about that or stay updated, follow these guys? I mean, of course the OPC Foundation and all these foundations out there, not just for MQTT, Modbus, whatever – but do you have some specific niche communities you would recommend to us?

Pyry:

Well, within the OPC Foundation, if you participate in the events, like the online event OPC Day International once a year, you will learn a lot. I'm also following the Open Industry 4.0 Alliance, and CESMII in the US. There are some Discord groups that have quite active discussions about these topics. Sometimes the discussion is even quite, let's say, tense – especially lately, I would say, or in the past years, about unified namespace compared to OPC UA, and these OPC UA versus MQTT discussions.

But I think that we have moved even in those, from the level where they are directly competing, to understanding that there is a place for everything. And especially that the OPC UA information models are so unique in the industry that no one else has them. They are really the heart and core of OPC UA. And even when you use a different transport, you would like to use those information models.

Madeleine:

Thanks for the recommendation. That's perfect. And I also want to invite everybody to SPS this year in Nuremberg, Germany. Come over, we will have a meetup – I guess it will be on Tuesday. So come over and let's discuss it with all the partners and users on site. And if you're not on site, we can also discuss it online. So please contact us through the network, we can help.

Pyry:

Yeah, and I will be at SPS as well, and I'll try to come to the meetup as well, if anyone wants to meet me there.

Madeleine:

Yes.

Pyry:

Yeah, actually, what I was about to say last time about the case: There we planned to use MQTT originally between the site and the cloud. But there was something more customer-organization based – well, we were not able to open up MQTT very easily. So this is why we ended up going with a different approach: We actually used OPC UA Reverse Connect. So from the site, the OPC UA server connects to the client that is in the cloud. This way we were able to get the standard OPC UA connection and then store data in the cloud databases and data sources for the OEE reporting. But even in this case, the first idea was actually to use MQTT, because it would probably have been a little bit more handy. So I'm not always just OPC UA – use it where it's best.

Madeleine:

Right. Okay. So maybe one of the last two questions for today. Somebody from our community says that when you have the different data points – for example a temperature, or whether or not a correlation to other data points is important – that knowledge from the subject matter expert is in a completely different department than, for example, the data engineer. The person who understands the data point sits maybe in a completely different department than the person who is building the data pipeline. So how does your model, or maybe an open information model, close the gap here in practice? Because you're telling how Forge is doing the IT/OT integration here.

Pyry:

Yeah, so this is exactly the problem that everyone typically faces when you do these projects, like analytics projects or whatever. You have a load of knowledge – the hidden, silent knowledge in the plant about how things work, what the relevant things are, what is not relevant. Now a typical approach is that you just connect to the data sources, you publish everything to the cloud, and there is some data engineer working with the data, having not much idea of the data, but a high-level understanding of what he's working on. And this approach is failing, well, I would say, time after time.

In Forge, the whole idea is that it's a tool that is configured on site by the automation engineers. So they do the modeling, they do the contextualization, they explain the temperature: where it fits in this ISA-95 hierarchy, what the standard range of the values is, what the range is that it shouldn't go to. And on the other hand, they tell whether it's Celsius or Kelvin or Fahrenheit, the value that we see. Or in some cases you actually don't get the value in any human-readable way, but it's just the resistance, for example. Then they probably have the manual available, so they can create the conversion from resistance to Celsius in Forge.

And once the context is built – and of course, if you use OPC UA companion specs, the standard information models that are made by the vendor communities for their machines, then you have a huge document giving the context for the values – suddenly the work of the data engineer is much easier. So this is how we try to solve this. Of course, there should always be a hotline between the data engineer and the automation guys whenever there is something.

And also, when there is this context, it's not just easier for the data engineer, but it's also easier for the AI. Because if you plug AI into a typical automation system, it won't understand a bit what those variables are, like B200_PV. So what's this? What should I understand?

Madeleine:

Right, right. Okay.

Pyry:

But once it's fit into an information model that tells exactly that – this is a pressure measurement of this specific tank or pipe or whatever, and what the tank is doing, what its purpose is in the process – then the AI also understands much more and creates something that is useful.

Madeleine:

Okay, that's cool. So if you're listening now and want to learn more about Forge, please go to the website, check out Forge, and maybe you can book a small demo, or a meetup where you learn more about it. Because Forge is really a unique and great tool – we don't have too many of them that are so proven in practice in our network. So it's really nice, have a look at this. And it not only connects the OT and IT, it's more than that, as we discussed today – also with the new features you're working on right now, for data harmonization and things like that. It's a great tool.

And maybe for the very last question for today: I'm always curious about learnings from a project like this, where other customers could take something with them. I guess you shared a lot of insights today already. But were there any learnings from this project that even surprised you? Something the customer also didn't expect? Do you have some insights here?

Pyry:

I think one of the learnings was that what originally looked very impossible wasn't impossible. I would say that in the first meeting, I don't know how positive we actually were. It was more like: Hey, this will be challenging, and let's see if we cover 30 % or 50 % or whatever of the machines. But I think we did much more than we expected.

A second learning: When you work with this kind of international manufacturing company, it took me too much time to understand how their IT and the provisioning works. I think we spent quite much time waiting for all kinds of virtual machines, privileges and things like that, just because our organization didn't know which ropes to pull.

Madeleine:

So it's a big thing, the IT governance.

Pyry:

Exactly. But then what we also learned is that it actually scaled very well. So now they work on the connectivity, and we are not there, but whenever they get a new machine connected, it's less than an hour until it's live on the dashboards, in the OEE, in the MES communication. It doesn't take us much time to map the data and publish new things, because everything is ready, like the templates. You just deploy templates, you do the mapping, and there it is. So it does scale. And also the reporting systems that we have are made in such a way that they appear there automatically. The first ones took much more time than it does now.

Madeleine:

Okay, okay. Yeah, thanks for sharing those learnings. And one additional question – I don't know if we will put it in the podcast, but it's maybe a nice add-on. We had a discussion about the manufacturing execution system. People have MES systems, of course, to manage and track their production in real time. It's really the basis of what we have done for decades in this architecture, the typical pyramid model. And now, when we talk about AI, it's maybe disrupting all these data sources, and the whole architecture is like a net where every data point is maybe connected. Would you think, maybe five, ten years ahead, that MES will disappear in the future? What do you think?

Pyry:

First of all, like I said in the beginning, investment cycles are long, and things just don't happen fast. So I'm sure that there will be MES systems as we understand them today even in ten years or in 20 years. There are plenty of MES projects ongoing with the current market leaders that I know of, and I know that the idea is to run them for 20 years from when they are done. So it doesn't disappear fast.

But I understand the question, I understand the discussion. I actually had a very nice discussion about this on LinkedIn as well, just recently. Someone was claiming that MES is dead, and then actually, in his post, he went a little bit back to the basics, that it's probably not.

And how I see this is: I doubt that there wouldn't be MES systems in the future. I think there will be something that we still call MES. But the current top-line products are too closed, monolithic and hard to configure today. And AI, the open information models and the new connectivity will disrupt that, definitely. It will also split the tasks. MES is typically doing much more than the basic job management, job control, which is its core task: orchestrating the factory floor – what each machine should do next – and then storing the data of what was done, what the quality was and so on. And there will be new products that will take over, for example, the optimization stuff, the track-and-trace type of things, the maintenance parts and so on. And I think that even the old systems need to, how to say, modernize themselves to still be market leaders in ten years.

Madeleine:

Okay, that's a pretty good answer. And maybe my next question to the AI, when we ask Claude after our session, is: How would you build a zero-touch factory, and what would you make sure of? And I guess the open information model will be one of those things.

Pyry:

Exactly.

Madeleine:

There are other aspects to that, but I will follow up on this in my next episode.

Pyry:

When I'm freely choosing the topic to discuss for students or something like that, I always speak about my dream world, where you just bring something new into the factory and everything is configured automatically, and everyone knows how to recognize it, and everything works perfectly. So it's really like plugging the mouse into your computer.

Madeleine:

Right. Yeah, that's true. Okay, so thank you for our session today. It was a pleasure to have you here on the podcast. We discussed it very practically. Thanks for the customer project under NDA today, to make that happen, and also for the very specific, unique answers here. I will make sure that we also have a summarized statement on our website. And yeah, for this, I would leave the last word to you. From my side: Thank you for being here on the show, and see you next time, maybe.

Pyry:

Yeah, thank you, Madeleine. It was really a pleasure. Since you started, I think we connected on LinkedIn quite early, and it's been, if not on my bucket list, then almost, to be on a podcast with you. And now that's done.

Madeleine:

Perfect. Thank you and have a great rest of the week. Bye-bye.

Pyry:

Yeah, thank you. Bye-bye.