Make or Buy in IIoT: Scaling Use Cases on One LoRaWAN Platform

Today on the IoT Use Case Podcast: when a LoRaWAN network becomes not just a sensor project, but a scalable IoT infrastructure. We talk with Currenta Conneqtive and akenza about pumps, steam, ball bearings, impellers and the notorious make-or-buy debate – build it yourself or better to buy it. At its core, the question is: when does sensing turn into reliable operations, and why does that take more than gateways, dashboards and a few thresholds? Enjoy.

Murat, let's start right away with a concrete case. What was the moment when it became clear that you didn't just need a sensor on a pump, but also a reusable and scalable IoT infrastructure?

Murat

At our CHEMPARK it was clear, when we started, that we needed to find a way to integrate our steam networks across the entire CHEMPARK. The wired solution feeding into a control system was no longer an option we could use. So internally, as a system house, we set out to find how we could solve the problem, and we arrived at LoRaWAN and 5G use cases. And that's where the consideration already began: where do we display it, how can we visualize it – as always, then, make or buy.

How do we go about turning the sensor into a finished, end-to-end solution? And that's where akenza came in for us as the platform, with LoRaWAN and 5G as the medium.

The topic of make or buy is really always relevant, and it matters to everyone. For every larger topic, project, any digitalization effort, even up to AI now: do I build it myself or do I buy it in? What were the considerations, the trade-offs that were made there?

Murat

Well, in my past I've had make-or-buy decisions quite often, and in the past I could frequently see how the make decision turned out, until I joined Currenta. There we often needed two or three years of lead time before we even started writing a requirements catalog, from which we then had a development department – either internal or external – and then often really started from scratch with a UI designer, UX designer: how should it look, what should it do, which languages do we need, what input.

And I have to say, that was never the company's strength. And so I'm all the happier now to have the solution with akenza, where I can say: I focus on my core business. That's the sensors, that's the use cases. That's how I make money, and I can leave that work to akenza. And otherwise I'm happy to stay within the standard, where I can use plug and play, all the sensors are already integrated, I don't need developers to help me with the case, but instead the support team or the operations team can often already take part of it on as well.

Can you talk a bit more about your use cases? Which use cases did you start with, what's running now, what's still ahead?

Murat

We're now working with Smart Dampf – that's our first use case. It financed the bulk of the hardware on the shared medium. Now we're moving beyond that and have vibration sensing in the field, where we monitor pumps, incinerators, vapor fans and ordinary pumps used in the chemical operations. Beyond that, we're now really starting with the big range, a large catalog, where we're also making buildings smart, jointly replacing the thermostats and integrating the room temperature sensors.

Then, as the next solution, for example automatic lubrication, or methane sensors with Honeywell and the like. So you can really, once you've built up the platform, scale quickly into many different directions. Or, a very big case for us: we have quite a lot of wells on the site that we need to monitor – for ground faults, for cover openings and fill levels and the like – which then also work very well in the field with LoRaWAN and can be integrated.

On Smart Dampf we actually had a joint recording, a joint podcast, only recently. So anyone who wants to hear a bit more about how that was implemented, with the person responsible for the steam network, can take a look at one of the previous episodes. We had a very interesting discussion there, specifically on that use case. Christian, over to you: when you hear all this now, the various use cases, the structuring, this make-or-buy decision – how do you see it from the platform perspective? How do you look at customers, how do you segment that? Do you say it's actually irrelevant to me which use case you have, I do everything? Or where do you see the value of the platform?

Christian

„I do everything“ is certainly what I'd wish for everyone. We filter that out beforehand. Naturally we're very happy to focus on the core competencies we have. That's the topic of Smart Building on the one hand and the topic of Smart Industry on the other. And for the topic of Smart Industry, I'm responsible at akenza. And Murat already mentioned it: of course we always prefer the buy solution to someone sitting down and starting from scratch to build it.

There are such philosophies, of course, and they may have their justification. Naturally, with us, as Murat already said, it's much faster. We've been developing this IoT stack of our platform for ten years, and we're also considerably cheaper by comparison, of course. That comes together and enables customers to connect all measurement principles, all transmission technologies, protocols, sensors, as Murat already mentioned, that are available on the market – set up completely horizontally, without vendor-specific ties.

Where would you say the biggest pain is when you try to build something like this yourself? Is it now the diversity of devices – because there are an incredible number of sensors and other devices that you connect – is it then more about scaling, so data frequencies, data transmission, simply the sheer volume of data, or is it also about the topic of output, semantics? So what is it where you'd say the pain or the complexity is greatest?

Christian

That depends on the use case, on the customer, on what they want to implement. You can't generalize it like that, there's no single common thread. Basically, it's like this – to address the topic of LoRaWAN specifically – of course every device first has to be integrated into a specific platform. In other words, the decoding has to take place. And this decoding is already implemented at our end in the so-called Device Type Library for well over 400 devices – the usual sensors on the market, LoRaWAN devices that are often used, including Currenta's devices.

That means the customer can obtain the devices and they can be integrated onto our platform with a single click. In other words, the devices are already stored, are decoded, and this effort falls away. And in my experience, for many customers this is one of the biggest pains, decoding the devices. Because it's basically like at home: you buy a device, it's lying on the table, and now I'd first have to configure an app, and many shy away from that. They don't really want to do it. They want it with one click. The whole thing should simply work. And that's the case with us.

That's cool, of course, but it's also difficult to keep up with, this Device Library that you have. Maybe quite concretely, let's say with the pumps: which sensors are installed where, what do they capture – and let's go through it step by step, from the pump, from the sensor, all the way to the analysis.

Murat

Gladly. Let me take our river waterworks as an example. There we have large integral pumps that draw Rhine water and then use it for cooling purposes and the like. And these are assets that are critical in themselves – of course they aren't built redundantly, but their value is so high that they're worth protecting. We like to equip them proactively so that, between the maintenance intervals too, we know how the pump is doing.

In the past it was the experts who walked the field, who could hear how the pump was running. This expertise is becoming ever scarcer in the field, and we can then compensate for it with the IoT approach, where we say: we now install, for example, a TWTG sensor that can measure vibrations. You can then attach it to the critical components, for example on the motor, on ball bearings or on the mount.

There, together with the engineer or the vibration expert, we identified the critical components once and attached the sensors. Then we come in with LoRaWAN, because the assets are very often spread across our plant, over 11 square kilometers. As a long-range component, LoRaWAN is very good, where we can say: we can transmit small amounts of data over long distances – vibration sensing, too, can work with small amounts of data – in a very battery-efficient way. And we even get FFT analyses out of the sensor, that's naturally a bit more demanding, but they can then be sent, so to speak, into the field, into the platform.

Briefly explain FFT analyses, especially in the context of vibrations.

Murat

Yes, an FFT analysis is a spectrum analysis. So when we show it, we go across a pump that has a frequency band – everything has a frequency band. But we go from 1 hertz up to 6,000, 20,000 hertz and then look at the peaks, how high the amplitude is. So how strong the vibration is in which range. And from that we can read how the pump is doing. So high-frequency vibrations, sound levels present a different problem than low-frequency vibrations.

There, I think, it already came out quite well that every device is different. And that's also a big complication you have with this topic, with how you do Predictive Maintenance, for example, because every pump, in combination with sensors, has its own quirks and requirements. But we can come back to that. Let's continue along the path. So, then the data is in the LoRaWAN, transmitted via the LoRaWAN. How did you set that up, what do you have to keep in mind there?

Murat

Here on the LoRaWAN we have an outdoor antenna that is then installed in the plant. That's where the data is sent, so to speak. From there it can be forwarded via two paths: on the one hand of course via the fiber that we've laid, or, as a backup, via 4G, so that it then goes out via the backhaul. From there, into Actility – that's our LoRaWAN network server. So I'd call it a bit of a hub for the data. That's where the data comes in and can then also go out again.

And when it goes out, it goes into the IoT platform, akenza, and from there it continues onward.

We can practically hand over directly to Christian here. The data now arrives with you in the IoT platform. What do you do with it?

Christian

So the data is generated by the sensor – in Murat's case the TWTG sensor. Then the raw data, as it's called, arrives on our platform. This works by us storing a so-called Data Flow on our platform. That means we first need to know: what kind of sensor do we have, over which network? Murat just mentioned Actility. The networks – there are several of them, several providers – are stored directly with us as so-called Connectivity as a Service.

Which network is available or has been built at the respective customer's site can be selected directly on our platform. In other words, I click on the network – LoRaWAN – then choose the corresponding network provider, LNS, LoRaWAN network server, and then I select the device and then I select the output, in this case for example the akenza platform. And then I have this Data Flow, consisting of these three steps, configured for this device. I can of course also use it for additional devices of the same type.

And then the data – in this case it's the raw data of this TWTG sensor – arrives with us on the platform. For example the XYZ axis, as Murat already said, vibrations, frequency bands, acceleration values, temperatures etc. And with this data the customer can then, using the corresponding features we offer – for example a dashboard feature that the customer can use but doesn't have to – build a corresponding dashboard and visualize this data, for example as a graph. And that's what Currenta did in this case, the Conneqtive side.

Murat

Exactly, and what we can then do with the data once it comes in: you can also run thresholds or the like, or trend analyses, and from that generate a notification to an email, where we offer a full service for the pump, for example. We do the sensing, but together with a partner of ours also the analysis, so that when a vibration pattern is breached, a field service can then be dispatched as well, to take a manual measurement on site once.

I think that's really one of the most obvious and direct use cases: drawing thresholds and learning from that which limits are acceptable and which aren't. But that's the first step, and then it continues, all the way to Predictive Maintenance, AI models, so training classic machine learning models. Have you already moved in that direction too, and where do you stand?

Murat

I'd say first of all that the bread-and-butter approach, where you say we work with thresholds, can already really cover a large portion, where we say: 95 percent of the problems we solve that way. Of course we now also have vibration patterns – for example on the cooling side, where we have our vibration experts. Anton then also builds machine learning models for complex vibration patterns, where you have systems operating on the same foundation that can interfere with one another, so that you then have optimal settings for how they need to be controlled.

So how hard the one compressor runs, then the other, how hard the fans run in that context, so that you have a holistic optimization. But that's naturally a bit more complex, and then we're already back in an engineering project and somewhat out of the plug-and-play business.

Yes, I think these dedicated models are simply still complex with every deployment, and that requires the appropriate expertise. Great that you have Anton there, that's always an asset.

Murat

Exactly, at worst we can tell Claude Code please program us a machine learning program for the plant – and then after two minutes something comes out.

Exactly, generative AI isn't quite there yet. Christian, back to the Device Type Library again, to make it a bit more tangible for me and for the listeners. Now, around devices you can do a lot more, all the way to: yes, when will the device fail? So you can theoretically provide a lot of meta information. Where do you stop, so to speak, with the Device Type Library? It's already very good when you understand the semantics of the individual devices. Can you describe that a bit? Is it mainly about registering in the network, or is it already about understanding the data that's captured there?

Christian

Correct. There are of course sensors that can, for example, only measure pressure and nothing else, or only temperature. Then there are also sensors like TWTG that do vibration, ultrasound. There are further sensors that are hybrid, that also do temperature. There are many different factors, so also values, that are sent by a sensor over the LoRaWAN protocol. And they're all decoded accordingly on the platform. And as I said, the „then the sensor fails“ in the sense of: how long does the battery last? That's how I interpret it for now. That can be displayed accordingly with us. So what's the battery status, what's the network quality at the moment?

You know that typical mobile-phone symbol with those bars at the top that you have on your phone. That can be displayed with us too. What's the spreading factor of the device? That is, what's the reception quality etc. etc. Those are all options that we already offer, quasi integrated, on this Device Type Library.

When the device is selected and integrated into our platform, the customer then only enters the basic data I need, so basically a device ID and a key. Then the device is uniquely identified and sends the data to our platform. Everything else they can then configure to their own liking. So the so-called columns, as I just said – battery level, reception quality, spreading factor and so on – the customer can configure however they want. But it's fundamentally stored on our end.

Great. You also said that you're very technology-agnostic there, so sensors from all kinds of manufacturers and so on. Two things I'd like to understand. First: how do you build out this library further? So what's the trigger there? Do you go into the market and look for further sensors that aren't in it yet? Or do you always react to customer requests? Or do perhaps even the suppliers themselves come to you and say: hey, look, we have a new sensor, please build it in? So that's one block.

And then, this can maybe come afterwards, this very technology agnosticism applied to other areas as well. Where do you perhaps also see differences – it always depends on the use case, you'll surely say – but maybe you can already say a bit about differences at various levels. For example LoRaWAN: you mentioned a few alternatives. What are the alternatives there, and how do you view them? Because you'll probably use several of these technologies too.

Christian

Both apply: manufacturers come to us and want to enter into a partnership with us. We've also presented these partnerships on our homepage, showing which manufacturers we cooperate with. That means the manufacturers' devices are then added to the library step by step. Then there are of course customer projects that make very, very heavy use of a specific device. Naturally that device is then integrated by us as a service for this customer project. That means, once integrated, it's in there, and can be used by everyone else too.

And of course we also look at the market for what's hot and what's not, as the saying goes. You see that a device keeps coming up very frequently in other use cases that we may not even support. Then we occasionally like to add that to our library too. It depends on these three factors. And the other question you asked, about the alternative to LoRaWAN: there's also the protocol mioty, for example. There are also hybrid gateways that can do both, so process LoRaWAN and mioty, which means I can build a hybrid network. I'd rather not go into the pros and cons of the technologies now, that would go beyond the scope. Then there's the topic of NB-IoT, so Narrowband IoT, and the LTE-M technology. That means, depending on the use case, where I am:

In the field I use an appropriate technology. If I'm on a large site, in a CHEMPARK like Currenta's, I can set up as many gateways as possible, have a very dense network and like to use LoRaWAN sensors. But if I have to cover very, very wide areas, I'm somewhere in a forested area, I have no power lines there, I can hardly set up gateways, then I use a battery-powered sensor that has an LTE card built in directly, so a SIM card, and then I use the LTE technology to send the data directly via LTE to the server, akenza.

And now, Murat: if you want to implement this – did I understand correctly that you do the complete package? Now you've deployed it yourself at your CHEMPARK, and now, since you've built up this knowledge, you also make it available to others as a kind of package solution. Can you describe a bit what the core of the solution is – and maybe also the boundary: what do you do and what don't you do?

Murat

Our strength really lies in the system-house mindset, where we say: we bring the expertise and partnerships from the manufacturers, for sensing all the way to analysis and visualization for the customer, or even the operation and the replacement of the motors. We also have a partner, Tectrion, who then uses the vibration analysis to make findings on site or to carry out a replacement of the pump. We can offer the whole service.

We now have the water meters that we're trying to gradually convert to LoRaWAN at our plants, to reduce the trips across the CHEMPARK for meter readings. Then of course you have the pain of configuring the decoder correctly, so to speak. We'd bring that along too – also with the manufacturers as partners, where you say: we have the sensor, we want to read it out this way. Then you do have to do quite a bit of back and forth by email, if the sensor isn't already implemented at akenza. Once it's in there, it works plug and play with a single click.

Which is a huge help, because that can otherwise take a week or two of project time, simply making these arrangements. Then we roll out the product, the sensors go in, and we can then bring them into the customer's desired system, for example. Our desired system is a billing platform. That's why it makes less sense to visualize it on an IoT platform; instead it just has to be billed. Then we bring it from akenza directly into the platform, in the desired format, so that the ingestor works – via MQTT or OPC UA or via CSV, which is saved in the right folder and then consumed by the program.

That nicely ties the chain all the way to the end, to everything you do. And there's quite a lot hanging off these different layers in terms of topics. Right, especially in the context of platform configuration: akenza has a bit of a no-code, low-code approach to configuration. Can you say, if you have a typical customer project in mind, what does Christian do with akenza, so to speak, what do you do, Murat, with Currenta Conneqtive?

And that still stays with the customer, in a sense. So the very simple things they'll probably do, and want to do, so that they have a certain flexibility. Part of it you do yourselves, Murat, in your own implementations too, but also as a service for customers. And then akenza probably comes in on the more complex topics.

Murat

Let me take the example of vibration analysis. Say we now simply have customer A. Customer A would like ten sensors fitted in the pilot. For ten sensors I naturally don't use my own IoT platform. Those we'd then provide via akenza as a multi-tenant system from our side. And what we'd do would be: first look at the machines, which sensing can be used? Are they fast- or slow-rotating? Is it an agitator now, or is it a fast-rotating motor? Then you might have to look at which sensor to choose.

We then install these on site with the assembly team, integrate them into a local LoRaWAN network, which we deploy and also maintain, service and operate. The data then goes, so to speak, from the local system into Actility. From there it's sent into akenza, and there we can then often let the machines run for 30 days, feeding the data in on a dense schedule, where we say: we want one value every 30 minutes. Then, after 30 days, we can look at the data together with the customer on the platform and set the thresholds once.

There are of course ISO thresholds you can use directly, but usually, for specific installations on site, it's good to fine-tune them afterwards. And that's the expertise we'd bring, where we say: we bring the sensing, the assembly, the network and the platform. And the platform is, so to speak, hosted and operated by akenza.

Very good. From my perspective that already makes a lot of sense, also the way we're describing it now, from the concrete topics. What's important to me, I think, is to emphasize once more: this misconception that it's always about the one use case, which then immediately needs a return on investment of half a year. Rather, it's about building infrastructure like LoRaWAN, where, once you have it and once it works, you can implement lots of use cases. That's why it's often a bit misleading, a bit of a misconception too, what gets generated when you really talk about individual use cases. But I'd still ask the question: do you have individual use cases you could talk about? Because an infrastructure KPI probably isn't that transparent.

Murat

We can say we have one or two use cases where we have a direct ROI. Because we also often offer the services as a subscription. Where we say: we have, for example, old buildings on the site at the same time, which is very often the case in Germany. There we can directly bring in a solution to reduce heating costs, in that we have digital single-room control, can measure temperatures, heat the rooms on demand and thus directly save costs, save CO₂, and often that's less than the costs of the energy we save as well, so that the customer has no ROI period directly.

And once the network is already built up with that use case, we of course have the shared medium and can then expand to all the further use cases, where we say: we have the vibration sensing that we bring in, we have the lubrication optimization, where a technician then no longer has to walk around with a grease pump and go to the systems every month or on a distributed schedule – the sensing I just described, the vibration sensing or also pressure and temperature measurements, to bring safety once or to optimize the process.

So practically Infrastructure as a Service and Software as a Service in combination. That you offer it as a service, and through the savings you can already cover the infrastructure, and then on top of that you can build further use cases. I find that's a nice picture that many first have to grasp: that you can keep building further on the infrastructure, and that it gradually improves like that. That's the platform idea, in a sense. Christian, do you have one or two more figures and insights you want to share on this?

Christian

Basically, to come back once more to the other opening question: „do you actually do everything?“ Well, the format here is called the IoT Use Case Podcast. Basically, as you say, it's correct: all use cases can be covered. That can of course happen via our platform too. Murat earlier used the word data hub, in connection with Actility. That's how we see ourselves too. As I said, we can connect everything that's available on the market. Whether that makes sense has to be examined, of course, quite clearly. Accordingly, we then filter too.

We can scale infinitely, that's not the problem. We also have the corresponding output connectors, which already went a bit in that direction earlier, I mentioned it with my Data Flow example. We can use the akenza database, but we don't have to. That means the data can be displayed and also visualized with us. But also, as Murat already says, there are also such machine learnings. That means the data is then forwarded via CSV – that was the classic – SQL databases, Power BI tools, webhook. We have cloud-to-cloud communication via a corresponding API. So there are incredibly many options. Of course alerting: Teams, Slack, messages, SMS. That can all be selected in parallel. Accordingly, we're also set up agnostically, horizontally, on the output connectors, where the data should then go. That's the first point.

And the second point also goes in the direction of time: time is money. And if I now think about an open-desk policy at a company – I have an office building with 500 offices, and every employee can choose in the morning when they arrive: where do I work? You know this model, every workstation is set up pretty much the same. And this search for a workstation in the morning often eats up a lot of time.

And when I then, via a so-called sign screen – you know it, you come into an office building, see a big floor plan and I can see at a single glance which room is green, so free, and which room is occupied: employees save an incredible amount of time in the search. People like to underestimate that. We do that too, meaning we then represent the floor plans as a 2D, 3D model. Every desk, every chair is occupied accordingly with the sensor. You can also use existing motion detectors, sensors.

Christian

And that's the kind of use case that gets underestimated: this time, this room search and seeing what's actually happening. And in addition to that – even when I speak of motion detection again –: what about the washrooms? Do they need to be cleaned, were they even used today? Do I have to send my team in there? Do they need another solid hour to clean something that wasn't used at all? Such topics also play a big role there, simply the optimization of buildings. And we're now also doing all of that with the Conneqtive side at the CHEMPARK.

Yes, exciting use cases when you build out further, ultimately on the basis of a topic like this. We also talked about ball bearings once: when you replace a ball bearing, you spend 1,000 euros. But if you don't do it in time, then you have the problem with the impellers, and then you have to spend 10,000 euros per impeller and things like that. I think that's special, when you can map more of it on the basis of one infrastructure, then that's always a great thing.

It almost sounded too good to be true from you just now, Christian: everything's there across all connectors and everything's mapped and everything's output. But now to turn the view forward: where is further development and work happening? You'll probably, typical IT, never be finished and always have a bit of a roadmap. So what are the topics you're now still improving in the platform, for example? What's generally being improved in IoT?

Christian

That's a very good and very difficult question to answer. I'm not a developer on our team, which means I don't know what's on the roadmap. Basically, of course, the projects that come in are examined specifically: how can I improve the project, what other requirements does the customer have? We've found that no customer is the same. There's no common thread where the customer says, I have a sensor, I have LoRaWAN, I want the data visualized, and with that budget, that's enough for me.

Every customer has their special requirement somewhere. They want a change here, they want a change there. And those are the kind of rolling topics we constantly have on the table, optimizing applications with the customers. And as I said, there's no royal road. It's simply that every application has some differentiation from the other application somewhere. And we work on that daily. But providing this flexibility, that's precisely our strength.

That means we don't start from zero anywhere. We're well positioned, and we have the options in our portfolio. And every change that comes in, every wish, can be implemented in a very short time and very fast. And that's also mostly via the low- or no-code approach of our platform, by the customer themselves. And that's the advantage. That means follow-up costs, if you will, are very, very few. Unless it's that super fancy feature the customer wants.

Then we also have to look at whether we can develop it, how long it takes, make a quote and so on. But basically it all works with the on-board tools of our platform, and that's our big advantage.

Okay, so then, Murat, can you name a few examples there, two or three examples where you'd say: had we known this earlier, we'd have done it differently – and now do it differently in the following projects.

Murat

What we were able to learn is to often go with an existing standard after all, so that we can be faster. Often requirements that appear as a must-do at the start turn out in the end to be only a nice-to-have after all. So that more often turns out to be the case when you say: you then used very, very expensive hardware in the field and built it up, and in the end the project also turned out a bit too large in the requirements catalog. On the software side we haven't had any major problems so far, we've been quite happy with akenza.

As Christian said, it can then happen that something has to be developed further at some point. You can talk about that, you have a quota, so that you can develop something together to get a custom solution. When you say, for example – our CHEMPARK is also no run-of-the-mill case for the company, rather we have a large site – we can take the maps, we can then visualize on the map which block is currently being supplied and how, and how we could optimize that in the final expansion.

In that case, on the IoT platform, we had fewer major learnings, because that really came out of the box, and more then on the sensing side and in the field, where we had to say: there we paid a bit of tuition, because we perhaps did think too complex, or too much like an engineer, about how to optimize that last little bit, and could perhaps be a bit more pragmatic there.

A pragmatic approach, I find that generally very good. And working together with you certainly makes sense there too. And perhaps also choosing the exchange with others: for that we have the IoT user circle in the IoT Use Case community. Being part of that, I think, is also very exciting, to talk precisely about such cases and about the problems and to compare notes there. I've been there a few times now. Those are always interesting discussions, precisely from these very concrete problems that arise during the implementation of topics.

Many thanks from my side, it was a very interesting conversation – about the fact that you now also offer this jointly going forward, independently of one another of course, but then also together. I found it very exciting, because you also deploy it yourselves, the CHEMPARK among other things. So many thanks, many thanks also to the listeners, and until next time.