From Measurement to Maintenance: IoT in Practice with Ethernet-APL

Hello, dear friends of IoT. Today we are looking at an exciting project at Merck. You may already know the company. However, today it is not about pharmaceutical production but about the area of Utility Supply Services, meaning the supply facilities. Specifically, we are looking at a drinking water storage system that was used here as a test environment.
Several IoT technologies were tested in collaboration with Endress+Hauser, including Netilion Cloud. Smart sensors were also used. Today the focus is on use cases around condition monitoring of measurement data, but also maintenance, servicing, as well as device diagnostics and remote monitoring.
As always, we answer your questions, for example: How do you get from raw measurements to concrete maintenance recommendations? How can the data from the drinking water system be integrated? And what is Ethernet-APL? This new standard plays an important role here as an enabler for more efficient data transfer to the cloud.
Of course, we also want to share best practices with you. For this I have invited Pirmin Lickert. He is Portfolio Manager for Sales, Marketing, Innovation, and Digitalization at Endress+Hauser. And today it is not about classical measuring devices but about the IoT area. More on that in a moment. As always, you can find all the information you need about implementing these or similar projects at www.iotusecase.com.

Hi Pirmin, great to have you with us today. I hope I am pronouncing your name correctly. How are you doing? And where are you right now?

Pirmin

Yes, that is correct. I am doing great today. I am at our office of Endress+Hauser Germany. Our headquarters is in Weil am Rhein. For anyone who does not know that, it is located right in the border triangle between Switzerland, France, and Germany. That is exactly where I am today.

Very nice. Then greetings to the region and of course also to everyone who is listening right now. Maybe we can start a bit with you personally.
As I briefly mentioned in the intro, you are Portfolio Manager for Innovation and Digitalization. At the same time, you are also doing a master’s degree at RWTH Aachen. You have now been with Endress+Hauser for nine years, which I find very exciting as well.
To begin, I would like to know: what led you on the path toward IoT and digitalization? Is there a personal motivation, something that particularly fascinates you about this topic?

Pirmin

Yes, you are right, I have now been with Endress+Hauser for nine years. Incredible how quickly time flies. I started back then with a dual study program in electrical engineering. It lasted three years, I studied and was already employed at Endress+Hauser in parallel.
At that time I was already very fascinated by digital communication. And in the last five or six years, Endress+Hauser has developed intensively, including building up the Netilion Cloud you just mentioned.
I was then lucky that positions opened up in product management in the area of digitalization. That fit perfectly. So after my studies I was able to move directly into this field and help drive the Netilion topic forward here in the German market.

Very exciting. Maybe briefly about Endress+Hauser – you are known as a leading provider of measuring instruments, for example for flow, level, pressure, temperature, and so on. In addition, you offer matching solutions and services. Particularly interesting today is your Netilion ecosystem, your own cloud-based platform.
What motivated you to develop your own cloud solution? What exactly triggered it, and what added value do you see in it for your customers and the market?

Pirmin

Basically, at Endress+Hauser it has always been our aim to deliver a complete package to our customers. As you mentioned earlier, besides the devices, service and solutions are also part of it. It is not just about selling a single flow sensor but about providing a complete solution.
In recent years, the IoT topic has gained a lot of importance. So we asked ourselves how we could extend our solutions and deliver even more to our customers. That is how Netilion came about – a complete in-house development by Endress+Hauser. The platform rounds off our portfolio and enables us to offer an even more comprehensive package.
An important thought here is: measurement technology first and foremost means collecting data. But what happens with the data afterward? We did not just want to measure, we also wanted to help our customers get more out of the data. That was a key driver for building Netilion.

You just mentioned your customers and the IoT topic. Are there specific projects or experiences from the last few years where you noticed that this topic is really taking off? Do you have an example project to make this a bit more tangible? People who know me know I always ask for practical examples.

Pirmin

Yes, exactly – that is also very important. In theory, things usually sound wonderful, but in practice it looks a bit different.
At Endress+Hauser we have seven core industries where we are active. That is for example food industry, life sciences, water and wastewater, but also power plants. And there you really see that it is very diverse. Not every customer is equally open to digitalization and cloud. Some say, hey, no, I don’t want cloud. And others are much more open to it.
We also have some large projects in life sciences. For example at Merck in Darmstadt, where we carried out a digitalization project in water treatment. In this project we basically brought in our entire digitalization portfolio.

Okay, maybe let’s stay with this project. What exactly did you do there? As you just nicely described – collecting data and then generating added value. Which data were collected specifically in this drinking water storage facility, and with what goal?

Pirmin

Our measuring devices typically deliver classic measured values such as level, flow, or also analysis parameters, for example the pH value. These values were also collected in this project and transferred into our cloud.
An even stronger focus here, however, was on diagnostics. Our devices are capable of providing diagnostic data and codes. For example, if the glass of a pH electrode breaks, the device detects this and gives out a corresponding message. That was a central aspect in this project.

I see. So these are your sensors in use – presumably temperature sensors, pressure sensors, and analyzers that are specifically suitable for drinking water. That is the first part, the sensor technology.
And the goal was then not only to process the measured values but especially also the diagnostic data. Why was that so important for Merck? What was the business aspect behind it – the concrete benefit?

Pirmin

Exactly. Typically, when a device fails, you often only notice it when it is already too late. Then someone has to go out into the plant, locate the device – which is not always easy depending on the setup – connect on site with a laptop, and first find out what the actual problem is.
Of course, that is connected with considerable effort. With Netilion this effort can be significantly reduced. All measuring devices are visualized in one dashboard, including the respective diagnostic data. If a device reports a fault or has a maintenance requirement, a message pops up directly in the dashboard – including the error code.
A particular advantage of Netilion is that it not only shows the error code but also immediately a suitable corrective action. Depending on the device, this can vary a lot. In simple cases the message is “Battery empty – please replace.” With more complex devices, of course, the diagnosis and recommended action can be much more detailed.

So with this type of condition monitoring you are already moving toward smart maintenance. Up to now many of these steps were carried out manually – someone had to go there, check the error, initiate measures. Now you can get maintenance recommendations directly from the system. This not only reduces effort but also creates new maintenance cycles. These were tested in the project with the Netilion Cloud, correct?

Pirmin

Yes, exactly. The goal is to save time and optimize processes. As you said at the beginning, this first took place in a test environment – not in the pharmaceutical core processes but in water treatment. This area is less critical but very well suited to test such digital solutions. In the long term, this naturally provides a basis to later also enter the core processes with such solutions.

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

What would you say were the technical challenges in this case? Are there points that keep coming up with other customers as well?

Pirmin

There are two points that come to mind spontaneously. The first is connectivity. In many plants devices are already installed. We are not going in here with new devices that all already support PROFINET-APL and can therefore be integrated relatively easily. Instead, you often encounter legacy devices that, for example, only output a 4–20 mA or HART signal. This creates a very inhomogeneous infrastructure. So you have to figure out how to connect these different measuring devices to the cloud. That often requires adapter solutions, gateways, or edge devices. And that is often one of the biggest challenges: to really bring the data reliably into the cloud.

I see. So these data are, for example, values like tank levels that until now were only recorded as simple analog signals?

Pirmin

Exactly. The 4–20 mA signal is a classic analog signal. The actual measured value is scaled onto it, meaning you only get this one value from the device. There is no additional information, no diagnostics, nothing. That is quite simple.

And beyond that, what are typical challenges? Connectivity is one, but when the data then need to be transmitted, what do you see in practice? You mentioned earlier that sometimes it is already difficult to even locate the device. Are failures a frequent problem, especially when only the classic primary values are available?

Pirmin

Yes, absolutely. If you only get one measured value from the device, you basically know nothing about its condition. You just notice: there is no value coming anymore – so probably something is broken. You cannot say more than that. If you use digital signals instead, you get much more information, such as granular error messages.

I would also be interested to know how customers actually do this without you today. How do they get the data manually? Are there typical approaches where you would say: that is cumbersome, not scalable, and costs unnecessary time and money?

Pirmin

Some customers also evaluate the diagnostic data directly in the process control – provided the devices support a digital HART signal or similar. Then it is programmed in the control system and analyzed there. So the possibility does exist. But the effort is usually much higher than if you simply map the whole thing via the cloud.

I see. And the goal is not only to visualize some measured value, but to make concrete statements – for example: the sensor reports a deviation, calibration is required in three weeks, please schedule in time. Is that the direction you are taking?

Pirmin

Exactly, that is definitely the goal. I would say we are not yet at 100 percent, but we are moving in that direction. Predictive maintenance is of course a big keyword that always comes up. But the first important step is to reliably read out the diagnostic data and understand what they mean. Is there a drift? How does the condition change over time? Only once this basis is established can you build on it.

Yes, that is really a kind of flagship discipline – and technically also another level. All the more exciting that you are already testing this here in a pilot project.
You mentioned PROFINET-APL earlier. I would like to bring along everyone who may have never heard the term before. I myself have only come across it once or twice at a trade fair or read something about it on the side, but not in detail.
Maybe you can briefly explain: What exactly is Profinet APL and why could it be a game-changer in terms of connectivity? As I understood it, this is a new standard that brings Ethernet directly down to the field device. Each device then basically gets its own IP address. So it is not only that a sensor delivers some value, but the device becomes an active part of an intelligent network. Can you put it that way?

Pirmin

Yes, you can basically put it that way. You already described it quite well. PROFINET has been around as a communication protocol for quite some time now—that’s nothing new. APL stands for “Advanced Physical Layer” and describes the physical layer below it.
The special thing about APL is: you can communicate over a simple two-wire cable that can even be used in explosive areas (EX areas). The field devices are connected directly via this cable, and communication is then handled via the PROFINET protocol.
Each field device receives its own IP address and even an integrated web server. That means I can simply enter the IP address at my computer and directly access the device – for example, to configure it or to read out values.
The whole process also runs much faster than with 4–20 mA or HART signals, where depending on the network load it can take up to half an hour.

I see. So up to now the classic way was to transmit values via 4–20 mA. With APL I now have an end-to-end protocol that not only enables measurement values but also diagnostics – and that directly via an IP address. That is the background.

Pirmin

Exactly, another advantage of is the high transmission speed. For a single measurement value that might not yet be decisive, but as soon as you move toward diagnostic concepts, it becomes very relevant.

I see. And Ethernet-APL is not a vendor-specific system but a jointly supported project – globally organized, with participation from various industry partners, standardization institutions, and technology providers like you.
Are your customers also involved in this? Or is it rather a topic mainly driven by automation suppliers and standardization bodies? How much has this topic already reached your customers?

Pirmin

The large customers – for example BASF or Bayer – are definitely involved. They are working intensively on topics such as PROFINET and APL and are also specifically demanding these technologies from the field devices they want to use.
That then naturally brings us as measuring device manufacturers into play, as well as other automation suppliers – for example Siemens, Pepperl+Fuchs, or others. This cooperation is essential in order to bring such technologies to the market at all. The demand is definitely there.

So that means you also work closely with these customers and deliver data that is then used in interaction with other devices in the ecosystem?

Pirmin

Exactly. As you rightly say, it is not enough to just have the field device. You also need a so-called field switch – for example from Pepperl+Fuchs or Phoenix Contact. And you need a controller, for example from Siemens, that evaluates the whole thing. So it is an interplay of different components and partners to really get the technology running in the plant.

Yes, or also with WAGO – you are working with them as well, I believe.

[16:34] Solutions, offerings and services – A look at the technologies used

If someone in industry is now planning a similar project – maybe not exactly the same plant, but a comparable setup – how do you approach that? Can you describe how you proceeded in this specific project with Merck? From the selection process of the sensors, to the edge devices, and then to the connection with Netilion?

Pirmin

Sure. As a rule, this always runs through our field sales team, which is active throughout Germany. That is usually also the first point of contact for our customers. In this case, our sales team together with the contacts at Merck identified a digitalization potential. Merck was interested in simply trying out such a project.
As soon as it becomes more concrete, the sales team then quite quickly brings us from product marketing on board. We then look at the project together with the customer – often in workshops. We first clarify what the specific need is, what goals are being pursued, and how the whole thing can be technically implemented.
Then we go into detailed planning. For this we usually also bring in our technical specialists from the product centers – meaning from the respective production sites. They have deep technical know-how and support in finding out which components are needed, what the architecture should look like, and whether everything can be implemented that way. That is the typical procedure.

And with Merck it was then the case that you delivered the smart sensor technology, right? You set up the architecture based on Ethernet-APL and then provided access to Netilion Cloud—your central cloud platform for visualization and analysis. Did Netilion also serve as the central system for evaluation in this case? What exactly did you provide there?

Pirmin

Exactly. In the project with Merck, Ethernet-APL was not yet a topic. Instead, mainly 4–20 mA and HART sensors were used. We connected them via adapter solutions and gateways. An edge device then collected the data and transferred it into the Netilion Cloud. There the measurement values and diagnostic data were visualized.

Very nice. What I am often asked: Are there concrete best practices or typical pitfalls from such projects that one should pay attention to? Maybe from this project or from others – things where you can save yourself a second iteration if you consider them right away?

Pirmin

A real recurring topic is the interface between OT and IT. Our edge device sits exactly in between – it connects the process plant with the internet or the cloud. And this is exactly where it often gets difficult.
Especially when it comes to opening ports or getting security approvals for data transmissions, this can become time-consuming. We have already had many rounds where IT departments had to be involved. That consumes a lot of time. That is why it is important to consider this interface early and to bring all relevant stakeholders on board from the very beginning.

And how does the integration of the data into existing systems work – for example into customer systems or your own cloud? Especially in large corporations we often see in our community that many IT systems already exist. The data should either be integrated there or maybe even written back. How do you approach this from the Netilion side – how does such a data integration into existing IT structures work?

Pirmin

That is a great point you raise – especially with large customers this is almost always a central requirement. They usually have a leading IT system into which all data should flow, and understandably they do not want to operate a separate cloud solution for every field device manufacturer.
That is why we designed Netilion to be very open from the beginning. There is an API interface through which all data – meaning measured values, diagnostic data, documentation, and more – can be transferred into other systems, provided these also support an interface.
That means: you can use the Netilion dashboard, but you do not have to. Whoever wants can simply integrate all data into their own platform.

I see. That is of course particularly interesting for customers who rely on hyperscalers or already operate their own systems but still have many of your devices in the field. With your open platform approach you give them the flexibility: use Netilion if you want – but you do not have to.

Pirmin

Exactly. For example, we also work with SAP. That often concerns device data such as documentation or certificates – so more like master data. Here too we enable direct integration into the respective SAP system via the API interface.

Very good. To conclude I would like to do a short summary. The core today was really the business case around maintenance – in other words, how to move from raw measurements to concrete maintenance recommendations.
You said earlier that you are not fully at the goal yet, but how could this work in the future in the Netilion Cloud? How can measurement and diagnostic data be processed so that you can say: there is a maintenance requirement – and the use case is really solved?

Pirmin

A good keyword here is our Heartbeat Technology. It goes far beyond classical device diagnostics. With Heartbeat Technology, for example, you can track drifts in the device over time—in other words, how certain parameters develop.
This allows conclusions to be drawn about the health status of the device. We are currently working intensively on integrating these Heartbeat functionalities even more strongly into Netilion. The goal is to detect such deviations at an early stage – before the device fails.
That would then be another step toward predictive maintenance, where the maintenance requirement is not only detected but can also be proactively scheduled.

I see. And beyond that you also have other applications in the Netilion ecosystem. I simply called it “software,” but basically they are individual applications within the platform – such as Heartbeat, Netilion Value, and others. Can you tell us which apps or functionalities there are and what they provide?

Pirmin

Exactly. Currently the Netilion ecosystem is roughly structured along different use cases. For example, there is Netilion Health – that is about device diagnostics and condition assessment, exactly what we mentioned earlier with Heartbeat.
Netilion Value focuses on the pure measured values, meaning the classical monitoring. Then there is Netilion Library, our “digital library.” This is about documentation – a huge topic in the context of asset management. There customers find operating manuals, certificates, approvals, and all important documents for their devices.

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

The project at Merck will certainly continue to develop – and others at your company as well. What can we expect from the Netilion ecosystem in the next one or two years? Can you already share a bit of what is coming?

Pirmin

The process industry overall tends to move a bit more slowly, so the cycles are a bit longer. Nevertheless, we are continuously developing our Netilion system – following the principle of agile software development. That means new features are added regularly.
At the moment we are working on a new user interface. In addition, as mentioned, we want to integrate Heartbeat Technology even more closely into Netilion to bring diagnostic functions and predictive maintenance to a new level.
And of course AI is also on our agenda – both internally and in relation to Netilion. For example, we are considering how AI can be used to evaluate data more intelligently and further optimize processes.

Sounds exciting. And for everyone who is listening now and has a similar project ahead – maybe not exactly this use case, but something comparable – would it be okay for you if I put your contact details in the show notes? Then interested listeners can connect with you directly or reach out to you on LinkedIn. What do you prefer?

Pirmin

Absolutely, very happy to. Best via LinkedIn – that always works well, and we can get in touch easily there.

Perfect, then I will include your LinkedIn link directly in the show notes – as well as everything else we talked about today. What I found especially interesting was the topic of connectivity with Ethernet-APL, your Netilion Cloud, the data integration, and of course the concrete project at Merck.
If you’re curious, feel free to check out our platform at iotusecase.com. There you will find many more practical projects – maybe also on a topic that you are currently dealing with.
And of course, as always, a warm invitation to our network and community. If you are planning or already implementing similar projects, this is exactly the right place to exchange experiences.
Pirmin, thank you very much for joining us today. It was super exciting not only to get insights into practice but also to really understand how such a project with you works – including best practices. And with that I will leave the last word to you for today.

Pirmin

Thank you very much again for the invitation – I really enjoyed it. If any of the listeners already have a concrete idea or are planning something, please feel free to contact me directly on LinkedIn.
And just a little note: we will also be at the SPS trade fair in Nuremberg again this year with a large booth. Feel free to stop by, then we can talk in person directly.

Very nice, we will definitely be there as well! And if you are listening to this after the fair – no problem, just get in touch and exchange ideas. Then thank you again and have a great rest of the week. Take care, bye!

Pirmin

Thank you, I wish you the same. Bye!