IO-Link in Manufacturing: Condition Monitoring and Digital Services

Today on the IoT Use Case Podcast: How to provide relevant data using the IO-Link communication protocol so that it can be directly utilized by IT systems. Our guests are in.hub, which offers a Linux-based IT operating system, and nass magnet, coming from the world of electromagnetic solutions, contributing their Ethernet IO-Link Master. This episode is especially for those who have already implemented IO-Link through their sensors and devices but are struggling with utilizing it. Enjoy the episode!

Hello and welcome to the IoT Use Case Podcast. My name is Dr. Peter Schopf, and I’m your host for today’s episode. Today I have two guests: Oliver Salo, Senior Partner at in.hub, and Zoltán Ziegler, Head of Sales at nass magnet. Oliver, let’s start with you. Could you briefly tell our listeners how you became a partner manager at in.hub, who you are, and what in.hub is?

Oliver

Thank you very, very much for the invitation. My name is Oliver Salo, one of the partner managers at in.hub. I’ve been working in mechanical engineering for many years, I also trained in mechanical engineering, and I’ve been dealing with machine data for many years. That’s how I got in touch with in.hub as well. I found the topic so exciting that I went deeper into it, and I’ve now been able to focus intensively on partner support at in.hub for more than a year.
A headline that, I think, describes it quite well is: expert for condition monitoring. We’re very active wherever conditions in industrial environments need to be monitored and tracked. And the other headline, the marketing slogan, is: just do it — plug and play. I know you see that on many websites, but I think we can say with confidence that we implement it really well and that it truly is simple and fast.

Could you give a few examples related to condition monitoring? What kinds of conditions do you monitor?

Oliver

Condition monitoring covers the classic topics that are driving industry today: condition monitoring, predictive maintenance, and of course using AI to look at process data, detect anomalies, and create the data foundation for that. Because all AI models and AI algorithms only work if valid data is available. That’s what’s occupying us a lot right now.
On top of that come the classic tools like dashboarding and alarming. And then, very strongly, the topic of connectivity — and that’s where IO-Link comes in: connectivity from the field to the gateway, into the solution. We’ve had many classic protocols and interfaces up and running for a long time, but IO-Link was missing for a long time. That’s why the topic is so exciting for us.

And are there certain industries where this is used more? Do you see a trend there?

Oliver

A lot of the time we’re in contact with resellers — so not the classic machine builder, but more component sales. Many companies are currently thinking about how they can attach smart services to the hardware products they sell today. We add value there and bring them into a complete platform that offers many possibilities.
We’re active across a wide range of industries — basically across the entire manufacturing sector. We don’t have a specific niche that we focus on with a solution.

Great, so as broadly applicable as possible. Zoltán, over to you: Can you tell us a bit about how you came into your role, your background, and also about nass magnet?

Zoltán

Hello everyone. I’m responsible for sales at nass magnet Hungary, a sister company of nass magnet GmbH from Hanover. Here in Hungary, we develop smart products for our smart portfolio.
nass magnet has traditionally been a manufacturer of components for pneumatic applications. From that background, we’ve also been active in machine and plant engineering for many years and we know exactly where data is missing in operations — and why. That was the trigger for us to start developing smart products in addition to our existing products, to basically create condition-monitoring capabilities for solenoids and pneumatic valves.
That brings us to the first product: a plug connector with intelligent condition-monitoring features and an IO-Link interface. The second product is essentially the bridge from IO-Link sensors or actuators to IoT systems: a master with an Ethernet connection, or an IO-Link interface. That is the bridge between the components and sensors and the IoT systems.

It’s really exciting that you took this step as nass magnet — a German company that has its smart products developed in Hungary and is also moving in the direction of smart. A lot of companies consider that, and it’s not that easy. You’ve found a great approach there.

[05:32] Challenges, potentials and status quo – This is what the use case looks like in practice

Why did you decide on IO-Link? What was the trigger? There are different protocols — can you explain that? What was the trigger? There are different protocols — can you explain that?

Zoltán

IO-Link is a protocol for the last meters in the machine. Our products are at the very end: a solenoid coil basically sits on a valve and enables the switching of a valve. IO-Link is predestined for that.
It’s a standardized communication system that connects sensors and actuators to the automation level or the IoT level via a simple point-to-point connection and transmits device parameters, condition data, and diagnostics. That’s the main reason — besides other advantages of IO-Link — why we decided on this protocol and integrate it into our products.

If you have these valve switching functions via your connectors: which industries are we talking about? Is it pharma or process industry? Broadly positioned? Are there focus areas? Broadly positioned? Are there focus areas?

Zoltán

Very broadly positioned. Anywhere air is being switched. That can be automotive or the production of any kind of product. It can be pharma, it can be agriculture, it can be the glass industry — all kinds of things. Anywhere pneumatic valves are in use.

And then you built the connector and realized: now we have connectors, now we also need a master, right? That was probably the step to the next product.

Zoltán

Yes. We operate in niches, and first we built a product that fits one-to-one with our own products — for single-valve applications. Of course there are many master manufacturers in the market that forward the data to the machine control via fieldbus protocols. But our goal is different: we intended to make the data we measure on the solenoid coils IoT-ready.
That’s why we had the idea to create a master that converts or translates the measured data via Ethernet into IoT-understandable protocols and can then forward it to IoT systems — for evaluation, for condition monitoring, for predictive maintenance systems, and so on. And that’s also exactly how we got in touch with in.hub regarding their decentralized solution.

Oliver

Exactly — at one of those classic meetups where you present yourselves and see each other. And that’s when the spark jumped: the approaches and the way we address the market are very similar. That’s how the exchange became closer, and it matched really well.

[08:24] Solutions, offerings and services – A look at the technologies used

Now for you, Oliver: with your platform you can support multiple protocols, and IO-Link is now an extension. A master is a device that connects and brings together different sensors. Now it’s about how to pass IoT data on to IT — to dashboards, analyses, and the like. What was your approach in terms of end-to-end continuity? Did you work this through on a specific customer example, or did you set it up more generically?

Oliver

With our operating system SIINEOS, we basically create an operating system in which the customer can configure the application. They don’t have to program any code. We’ve had various protocols up and running for many years, including controller connections and analog and digital signals.
Our claim is: if we integrate something into SIINEOS, then we should also be able to handle most of the device configuration. With many masters on the market in the IO-Link portfolio, that’s not so easy. The master from nass magnet impressed us because it passes on the data in a very unfiltered way, and we can then evaluate it.
The requirement from the market for us to provide a suitable IO-Link interface to integrate sensors and actuators better for condition monitoring had been there for a while. That’s where the paths crossed. We can now configure the master, and also the devices behind the master, in SIINEOS. That creates a major added value: no software switching in the project — instead you configure everything directly in SIINEOS.
From an architecture perspective, it looks like this: in the edge device, we do the preprocessing in our devices and also maintain a database that the data flows into — no matter where it comes from: discrete inputs and outputs, a protocol, or in this case IO-Link. The data is normalized and written into a database. On top of that, we deploy various microservices with SIINEOS: a Grafana dashboard, an alarming tool, cloud connectors, an SQL connector for the company’s own SQL database. We’re very open.
We can generate value directly on the edge device via apps such as Grafana or Alarm, or we can pass the data on — aggregated or as raw data — depending on what the customer’s application requires. What matters to us is that the customer can parameterize a lot themselves, so that we don’t have to build a new app or a new connector for every customer project; instead the customer can parameterize it and keep project speed high.

Does that already work in a way that you have applications that are used more often? This tension between standardization and customization isn’t easy. How is it for you?

Oliver

That would be great — if we had the app you just described: one app for everything and all problems are solved. Unfortunately, that’s not the case, of course. Every process is different. In consulting, we go relatively deep and take a close look.
But the tools I use for that are always the same. We break it down into different tools that we put into the toolbox of our operating system, and that’s how we implement the applications. Normalizing values is always the same function and the same approach. Writing to the database is standardized in the background. The user only selects the values they want to store.
Especially with IO-Link, you get a lot of values. I don’t necessarily need to write all of them to the database, or not as frequently as process values. You can configure that. The tools are there, and the customer can configure it.
We also meet customers through YouTube and other information channels. That works very well: the maintenance technician or engineer watches how to normalize a value, replicates it, and then builds projects very quickly. The tools are available — they just need to be parameterized.

And Zoltán, you’ve then used it accordingly: SIINEOS, your connectors, your end customers. Have you already deployed the complete stack, or is that more of a future topic?

Zoltán

Both, actually. We’re currently in the process of using the SIINEOS system ourselves, and of approaching customers together where we can offer a complete condition-monitoring infrastructure. We deliver the structured data, and in.hub turns it into the condition monitoring system with visualization.

Is it more about enabling the application and the connection to IO-Link and additional data in the first place, or can you say: cheaper, faster, better? What are the levers that matter most to end users?

Oliver

What we repeatedly see when visiting plants is this: sensors are installed, switching outputs and analog outputs are wired, the IO-Link data is there — but it’s lying dormant in the plant. The great thing about IO-Link is the broad product range across many manufacturers — standardization works well. We see an enormous amount of data in plants that isn’t used at all. Many manufacturers provide IO-Link on many sensors, but often only the switching outputs are used.
That’s exactly the topic where I can ideally connect condition monitoring: I have sensors and actuators installed in the field that send me diagnostic data, and I just need to capture and process it. Our approach is not to put additional load on control engineering, but to capture the data directly, write it into the database, make IT systems available — for anomaly detection and so on — and leave the processes untouched.
At the same time, we can of course build the bridge into the control world. If we want to send messages to the machine operator via the control panel, or if the controller should receive information, we can do that. SIINEOS provides many tools to build control communication.
The driver is the market: sensor and device manufacturers are bringing many devices at attractive prices to the market that send IO-Link data — and the data needs to be utilized.

That sounds sensible. But projects often run into difficulties. Can you tell us: what are the complications? Where do you see the biggest challenges when someone starts such projects and wants to use the data? Can you tell us: what are the complications? Where do you see the biggest challenges when someone starts such projects and wants to use the data?

Oliver

One of the biggest challenges is, in the very first project discussion, getting the right people to the table. In a company there are different groups, and everyone has their pain point. Such systems are only accepted if significant benefit can be recognized from many directions. We often experience that one area wants to realize value, but then gets slowed down along the way.
I think the industry has reached a point where the issues you stumble over are no longer technical in nature. For a lot of things, there is an answer. It’s more about clearly defining the goal and following through: should alarms be generated, should reports be generated? What do we want to optimize? Spare part availability in the warehouse? Better understanding where disruptions arise in the machine? Goals have to be clearly defined. That’s more of an organizational hurdle. Technically, there are many solutions for many applications.

Do you support customers there as well? Many mid-sized companies may not yet have an overview of what’s possible. Many mid-sized companies may not yet have an overview of what’s possible.

Oliver

Yes. We have various options. If a machine builder is thinking about a digital business, we go in with consulting and work together on questions like: what are they doing today, what could be exciting in the future — classically for resellers.
And in the area of integration: if a plant operator needs an integration partner, we have different regional integration partners in our partner network. It’s important that the integration partner is nearby and doesn’t have to travel extremely far. We can build those bridges.

If you look at the discussion in the community, semantics is an exciting topic. Connectivity is one thing, but achieving a uniform format and understanding is not trivial. Do you have experience there?

Zoltán

We have experts in sales and in the program management team who know these applications very well and have been selling such products for many years. IO-Link offers huge advantages in cabling and makes connecting sensors via the master easier.

Then you have the data.
I’m not that familiar with it myself, so the question is: is IO-Link semantically clearly defined already — meaning it’s unambiguous which sensor is behind it, what it does, what it measures? Especially semantics, so you can merge it with other data to generate meaningful results, for example predictions.

Oliver

In the IO-Link environment, people very often talk about the IODD. The IODD is basically the driver file — the description of the sensor data, process data, but also parameter data.
We take two approaches: we have an IODD interpreter. You can load the IODD, it gets translated, and it’s stored in SIINEOS as a device driver. In parallel, we can provide this via an online portal, via a marketplace, where as a device manufacturer I can provide the device files — and have two or three additional functions compared to what the IODD provides out of the box.
Bringing semantics into the IT world is then another story. We have to provide the data in a certain structure. There we have various options to preprocess and format the data via OPC UA or MQTT so that what you mentioned arrives in the right structure in the IT landscape.

Is the transmission always trouble-free, or do you sometimes have issues, data loss, or something like that? Once you connect it, does it just run?

Oliver

From the IO-Link sensor to the edge device, it’s a wired connection where the distances are manageable and easy to handle. So I see fewer problems there.
When we talk about data quality and completeness, it’s more toward IT — from the edge device to the cloud or to a server. There we have connectors and drivers that can buffer. With well-known cloud systems, we have drivers that can buffer. But there are also one-to-one connections that may lose data if the connection drops. In the application, you have to check what is right and how to keep the data valid. There are tools for that.

And if you sum it all up: do you have concrete examples from customers of what they’ve saved? Lower downtime and things like that?

Oliver

We’re currently working out a tangible use case in parallel. But we also have another area where we look very closely at OEE and energy savings. That complements IO-Link ideally. We repeatedly get reports from customers that they can set up a solid ROI calculation in a very short time. These are projects that scale out strongly.
Another reason is project speed: it becomes less of a project-like character, and we move into execution very quickly through parameterization in the system. We have fast response times and can show results very quickly.

[23:54] Transferability, scaling and next steps – Here’s how you can use this use case

What are your next steps? First bringing it to market, or are there further developments on the product roadmap? First bringing it to market, or are there further developments on the product roadmap?

Zoltán

We have various products in preparation, but for now our goal is to successfully bring the existing products to market and cover the applications that we have also taken on here together with in.hub.
We want to further expand our master, take over or add communication protocols. A multi-protocol master is coming soon. In addition, there are further products in the pipeline: for example an IO-Link hub that will have similar functions to the Smart Connector, as well as further plug connectors for controlling proportional valves with IO-Link technology.

Great. And Oliver, what’s next for you? What are the next steps in how IoT platforms will develop?

Oliver

We have big building blocks ahead of us that will be launched step by step. The newest addition is the SQL connector, which allows operators to write directly to SQL databases. That means: I have an SQL database in the company, a machine that I retrofitted for condition monitoring, and I can build the bridge — easily parameterizable.
I mentioned the marketplace earlier, the online platform where we can provide driver files. That complements IO-Link extremely well, because I can get data into SIINEOS even faster when driver files are prepared and available somewhere. That gives device manufacturers the option to provide device driver files with extended functions. And that’s also a topic: how can I enrich my device with additional software, make it more interesting, differentiate myself in the market? Those are topics we can address.
And we are excited about our new HUB-SE100. It has nothing to do with IO-Link, but it lets us move closer to the sensor: the first decentralized module from in.hub. Until now, our cabinet modules were for DIN-rail mounting in the control cabinet. With the SE100, we can plug directly into the sensor line at the plant, digitize the signal close to the sensor, and make IT applications available — or process it further in the control cabinet. That makes retrofitting even easier. Many exciting products — we’ll keep everyone up to date on the usual channels.

Excellent. Maybe you’ll come back again and report on further developments and your collaboration. I think it’s strong when you have a match like this and then simply set up a collaboration and move forward. It complements each other nicely, and I’m curious to see how it continues.

Zoltán

It’s a perfect complement, from our perspective as well. We intend to expand this cooperation further and see what new developments arise for us on the hardware level.
In parallel to the in.hub topics, we also aim to move into new industries with our IoT master, such as building automation and intralogistics, and to design the products for these applications.

And you’re certainly interested in partners who do this with you together. If someone listens to the podcast and says: we need an IO-Link master device — what’s the best way to get in touch with you? If someone listens to the podcast and says: we need an IO-Link master device — what’s the best way to get in touch with you?

Zoltán

I can gladly leave my contact options here, but you can also find me on our website. We’re very open to cooperation and partnerships.

Oliver, if someone wants to reach out to you and needs IoT, what’s the best way to reach you?

Oliver

I’d start one step earlier. Most partnerships come out of conversations, or out of exploring: who is active where, who could use what, how can you complement each other? So feel free to get in touch in a very relaxed way.
You meet us at many events and trade fairs. Of course also via LinkedIn. The contact details will be provided in the show notes. We’re out and about everywhere. Of course also via LinkedIn. The contact details will be provided in the show notes. We’re out and about everywhere.

Zoltán

This year, we’re also at three joint events, three trade fairs together: All About Automation in Friedrichshafen, All About Automation in Wels, and SPS in Nuremberg in November.

SPS is also always firmly in my calendar. It’s a bit like my home trade fair, just around the corner from Erlangen. I also really like handling things through conversations. For me it’s more about generative AI for organizational development. Nevertheless: that was super interesting. Thank you very much for being here. Thanks to the listeners for following along with a topic that is quite specialized and in-depth. Until next time.

Oliver

Thank you very much.

Zoltán

Thank you.