23 Episodes Condensed: What Really Worked and What Didn't

Hello dear friends of IoT and welcome to this episode of the IoT Use Case Podcast, your podcast on putting IoT into practice. Today we're looking back at the last 23 episodes. That has never been done before. Among other things, interesting summaries with quotes from SCHUNK, Siemens, Salzgitter Flachstahl. We have United Manufacturing Hub with us again – I did an episode with Frank Thelen on that back then. We have WAGO with us, Endress+Hauser and many other interesting user quotes. So grab yourself a coffee, keep driving comfortably in your car or whatever else you're doing right now, and enjoy this special episode.

I'm Madeleine Mickeleit, your host, and sitting across from me virtually is the wonderful Dr. Peter Schopf. Hello Peter.

Peter

Hello Madeleine and a warm welcome back to our podcast. I'm glad you're here and coming back. Hopefully you'll take this over again going forward. It was an exciting time, but I'm also happy to hand it back to you.

Yes, thank you very much. I'm happy to be back too. And for those who didn't hear about it: we had twins. It was a very intense, beautiful time at the beginning and now we've settled into a rhythm. And yes, I'm back from parental leave. Let's get straight into the technical side, I'd say. So, 23 episodes – it's incredible how time flies. Let's start by summarizing a few of the highlight use cases and business cases from those episodes. By the way, we've given some thought in advance to which use cases we're picking out here and why. And so we'll start with the first one, which is episode 216. Let's listen to the quote and then look at why it's so interesting.

Murat

We can really move from close-interval manual inspection to an automated hourly interval, so that we can inspect at ever shorter intervals and massively reduce lost time.

Peter, you hosted the episode and took part in the discussion. Why is episode 216 on steam network monitoring with Currenta Conneqtive so interesting from your point of view?

Peter

You have to picture a steam network. That's 180 kilometers of piping laid across the campus they operate, this CHEMPARK. And monitoring something like that – making sure those pipes work, with all the valves and diversions and so on – is quite a challenge. You can really picture it: someone constantly has to drive out there to inspect. And I think if you monitor that sensibly and can then also control it over time, and keep developing your understanding of it – which temperatures are where, where can I raise or lower which pressures – that makes a big difference. The sheer power, the sheer force of these steam pipes simply makes it an interesting use case.

Sure, we'll get to the implementation later, but I think it can be transferred to a lot of other topics. This monitoring of many devices, including ones that aren't particularly high-value, such as pressure sensors or valves: do they close properly, do I have any drops in temperature, in pressure and so on? So you can transfer that very broadly, especially when it comes down to: well, how do I monitor 180 kilometers? That's why I think it was quite interesting.

Yes, absolutely. I should add, for those who don't know Currenta Conneqtive: it's the speedboat, the IoT unit within CHEMPARK. I was in Leverkusen on site just a few weeks ago. It's incredible how huge this CHEMPARK is. It's something like – I think 11 cubic meters is the total area alone – and it's an entire village that's there on site. I know something similar from my own past, when I still worked at Volkswagen in Wolfsburg. So really, a huge site. I don't even know – was this use case also in Leverkusen at the CHEMPARK or was it somewhere else? Do you remember?

Peter

That's my understanding, at least.

Yes, really incredible. And it's also great, as you say, how this heterogeneous pipe network, which has grown historically over the years and decades, is picked up in this episode. So really just a great use case.

Peter

What I found interesting about Currenta Conneqtive: they first developed it for themselves, found out they could do it, built up capacity and expertise, and are now taking the step outward and offering it to others as well. This whole drink-your-own-champagne theme – actually using it yourself first and then perhaps looking at what you can derive from it – often gets neglected too. People rush out and try to find customers before they've properly set it up in their own house.

Yes, I find that interesting. And if you're thinking about it now: I also found the topic of brownfield retrofit quite interesting in that episode. A lot of it comes down to the fact that this pipe network has grown historically. You said it, 180 kilometers of this steam network are there. And I also find that aspect interesting, how they then connected it all. We don't want to go too deep into the technology now, but do listen in, save it in your podcast app. I think it's a really nice episode. Do you have any other quotes or anything, or aspects from this episode that you found interesting?

Peter

Yes, I think the interplay between the different players was quite good there. And they moved from simple monitoring to a digital twin of the steam network. While you were dealing with real twins, we talked about digital twins here. And having that ambition too: we want to model it in a way that lets us really simulate everything and then optimize it with AI algorithms – I found that very interesting as well. So from that simple entry point, you just don't have to drive out and inspect so often, all the way to: hey, at some point we'll build this digital twin of the steam network. I think that also nicely illustrates the step-by-step approach you take there, and that initial stages can always help you develop further.

Now Murat Mutlu from Currenta Conneqtive says in the episode that they massively reduced it. Let me just look it up myself. Right, they massively reduced lost time. Maybe we can talk a bit more about that figure. Right now it's qualitative and there's no real number behind it yet. Is there a business case to be drawn out of this episode where you could talk about euros per hour per year or something similar – what this delay actually costs, and how much this hourly inspection actually saves?

Peter

That's an interesting point, because I tried in all the episodes to tease that out a bit and to ask and dig deeper. In the pre-calls in particular it was important to me to find out whether we could talk about it. But unfortunately it's often the case that they can't really commit to figures. So it's difficult to calculate business cases, often also because end customers don't hand over the exact numbers.

And well, if you say something in a podcast it becomes so official that unfortunately this was very often a topic where I didn't get the kind of concrete statements I would have liked for our listeners. So, yes.

A lot of it is also under NDA. I was at their in-house trade fair on site and I presented an example there of a heating chamber from the company DENIOS. Greetings, by the way, to the digitalization team, they're also part of our network and community. And that was a really nice case from the chemical and process industry. We don't have those so often – and, as you're already laughing, a lot of it is under NDA too.

So it's about a heating chamber. You have to picture it like an oven where various containers are heated. And it's about things like proving that temperature windows were maintained. And they monitored this heating chamber, essentially to know: how is the medium inside the container itself actually doing? Because the chamber itself could already be monitored. And then they calculated what a lost batch actually costs, for example.

And it works like this: if a batch from one of these – I think they're called IBCs, a 1000-liter cube for example – has to be scrapped, that costs them 20,000 euros. That's rare, but realistically it happens about once a year. And that alone is already the purchase price you'd get out of this digital solution. And cleaning this plant, for example, costs around 2,000 euros plus one shift of downtime, which is really annoying, because this incorrectly heated medium goes on to be used and cleaning the plant costs a lot of money, plus that downtime. And I thought that was a really cool example. We also discussed a lot on site about what other use cases there are in this chemical environment. I don't know whether an even cooler one comes to your mind, but I wanted to put a few numbers out there at this point.

Peter

Yes, and downtime alone is a good point, that it does happen. Because often people calculate: well, what does a solution like this cost me, and maybe also the hours you save in some form. But in reality, especially in a process environment, if a batch gets scrapped or downtime occurs where you actually want to produce continuously, then you're quickly at euro amounts that carry a digitalization initiative easily. That's also why the process industry is often a bit further ahead – considerably further, in fact – when it comes to data monitoring and so on, because costs arise very quickly there. But in discrete industry too, where parts are manufactured, downtime is sometimes a huge deal when a machine is running at full capacity. And that often isn't properly factored in.

Good point. And if this topic interests you: you're warmly invited to join our community. Write to me or to Peter on LinkedIn. We're happy to take you on board. And exactly these use cases and many others are discussed there – how to implement them properly. But let's move on. We continue with episode 209. It's about early flood detection, and Narrowband IoT was used here. And it's a municipal case. Let's listen in to what it was about.

Felix

… at a mayors' meeting in southern Germany, for example, where two or three households are always affected as soon as the trash rack gets clogged and the water then runs into their basements, where two or three affected citizens are sitting there and quite rightly complaining that no measures are actually being taken to get an early alert when this trash rack clogs up. In relatively small municipalities we of course have a certain differential measurement where the sensor is also used. That means, using our own control system, we measure the fill level upstream and downstream of the trash rack and simply know that when certain differences occur, a blockage is building up. And the fire brigade can then take countermeasures early on.

Okay, Peter, I listened to that and my first reaction was: what actually is a trash rack? I had to google it myself just now. I don't know, do you want to explain it a bit?

Peter

Yes, it was the same for me at first – I had to look it up briefly too – but in the end it's basically a grid. A grid that keeps large objects from flowing into various pipes and lines or the like. And when the grid is blocked, it can be so finely clogged that the water backs up, because no more water can flow through. And I found that quite interesting because it also shows the breadth. We've talked a lot about factories, and in this case about municipalities and how they can use IoT. So the breadth of use cases on the one hand, and the breadth of the technology as well. At Currenta Conneqtive it was LoRa, for example, as the monitoring network to collect the data; here it's Narrowband IoT, which transmits directly into the mobile network. You don't need a specific gateway for it.

And while Currenta Conneqtive was interesting with its 180 kilometers of piping – here you have square kilometers to cover. So municipalities have one issue in one place and another issue on the complete other side of town. And covering that breadth with IoT, with sensors that need long lifetimes so that you don't constantly have to replace batteries, for instance – that simply shows the range of possibilities.

Yes, I found that really interesting too. And I should say, maybe a bit of context as well: Felix Brühl here is the Business Development Manager at Endress+Hauser. And those who have been listening to the podcast for a while may know how Endress+Hauser is positioned in the IoT space – for those listening for the first time today: Endress+Hauser is by now genuinely operating as a solution provider here.

Otherwise people always talk about components, about hardware. And as you mentioned, suddenly it's about Narrowband IoT, which brings the data into the cloud somewhere, where Endress+Hauser can then implement a holistic solution and a use case together with partners. So that's probably new to many people, I imagine. And on the topic of Narrowband IoT – I think they used it because you're relatively far out there and probably needed a long battery life. And you also get the good coverage that Narrowband IoT brings here, right? Do you remember why they used it at this point?

Peter

Exactly, it's this direct transmission to the radio masts of the telecom providers. That means you don't depend on collecting everything again somewhere in a gateway where the data gets consolidated and then transmitted. Funnily enough, we had exactly these topics – going straight into the mobile network – on the shopfloor as well. There are solutions for that too, where you avoid this collecting and routing everything through central IT, for example, to get it into the cloud.

Some data you can bring directly via a mobile mast into the cloud, into your own dashboard, whatever you want to have. That path – and I found that interesting in the recent episodes, in the last 20-plus episodes – these different paths by which data from the sensor, from the machine or in this case from a shaft where water is measured, how this data reaches your own dashboard, your own app via different routes, where you either display something or calculate something, train algorithms with it and have it evaluated. These paths are really interesting.

They are interesting. Visually I also have a classic architecture diagram in my head, where you now clearly have the classic automation world, the way data used to be connected, and then by now also from – I don't know whether it's a KSB pump, an Endress+Hauser sensor, whatever, an ifm sensor – which you can now connect via the manufacturer cloud, which goes external, or via mobile networks or via LoRaWAN, Narrowband IoT, and then perhaps run directly into your own data lake or into a data hub where it's all collected. There are all sorts of options. Without going into too much detail: these are also topics we discuss in our community. But it's really interesting to see the different paths there are and what the tech stack actually looks like for these individual use cases. Let's move on, I'd say, shall we? We had picked out another episode, a completely different aspect. It goes in the direction of digital service. So a manufacturer, a machine builder, the company SPALECK, which offers digital service. That's episode 206. Let's listen to what Jörg says here.

Jörg

The first problem we noticed in the past is: when an LED is simply green for five years and then turns yellow, and then it's yellow for months and red for another few weeks, and then the damage is done and nobody saw it. And in the logs we always saw, okay, everything worked as such, but nobody reacted. That's why at some point we lifted this onto the cloud platform, so that we, as the experts for these machines, notice it and can then make the things happen that are needed so that a repair that maybe only takes 10 minutes really does stay that – and not complete downtime for one or two days. That's already four or five days that we actually save if we apply a trained data model. That doesn't sound like much, but whether it's a Friday or a Tuesday when you know you really have to act now does make a difference.

Yes, Peter, what did you think of the episode? What was interesting for you there?

Peter

The topic of downtime comes up again here, which we discussed at the start. Depending on the machine and the operation, it's a huge deal and enormous losses arise. What I really liked about the quote is the theme: well, for five years everything runs without problems. As he says, everything is green. After five years you've simply forgotten that problems could ever arise. You just don't think about it anymore. But then, when a light somewhere is yellow and at some point red, nobody knows anymore why this machine is doing that. So the knowledge about the machine simply isn't there on site. It runs, runs reliably, and so you never built up that knowledge. What you actually need there is collaboration with the machine suppliers.

And that's also what makes it so interesting: well, do I transmit my data, my production data or whatever data – production data, machine data – to the supplier of the machine and let them help us avoid exactly these issues? So that they keep an eye on it, because if they get the chance, they can ensure across a great many machines that things work. And I think many are still a bit hesitant there: I don't want to transmit my data, and so on. I think we in Germany need to become much more open, in many areas too. We need to share data, within a secure framework of course, in order to realize use cases like these.

What I also find interesting here – this just occurred to me – is: this is a case that doesn't occur very often, that downtime happens because of a specific error log or whatever the cause was. How do you see that? I mean, to have proper training data, whether for an AI model or even just for simpler things, you first need a training data set at all. In the community, I remember, we often discussed: if this case never occurs, how do I simulate it, or where does this training data actually come from? How do you see it? How do I actually do that? And where does this training data come from, especially with reliable machines where hardly anything ever fails? You know what I mean?

Peter

Absolutely. We discussed that in the episode in quite some depth too, because it's a really interesting part. We'll come to the topic of AI later – classic AI, generative AI. With classic AI models in particular, you need this data to train them. You need a lot of data. A few failure data points every five years isn't enough. The nice thing, actually, as Jörg then explained, is that they had a machine that really was quite faulty.

In that case it was almost a gift that they had such a failure-prone machine early on. And with that data they could then test and analyze this machine in great detail. You almost have to hope you get a machine that doesn't work so well in order to obtain data like that. But getting hold of negative data is always a challenge for classic AI, machine learning algorithms – training it so that it can then also anticipate failures.

Okay, we'll come to that shortly, and I think that interests a lot of people. So we can pick the question up again in a moment and answer it. And by the way, we'll also come back to why it actually fails. We have an interesting quote there, as you heard at the beginning. So we'll get to that shortly. Now I have to add something quickly: I didn't say who Jörg actually is. So Jörg is the Head of Development at SPALECK. And also with us were Lukas Schattenberg from IXON and Dr.-Ing. Alexander Engels from the company aiXbrain. I hope I pronounced that correctly. The three of them worked together in that episode.

Peter

Yes, exactly, the interesting thing there was: aiXbrain was essentially the AI algorithm, responsible for the machine learning part. Then we had the provider for the IoT platform and data transmission, and the machine builder. So I found this interplay really interesting, how the three of them mesh. Each brought their own expertise to the table and together they created a solution that gives the machine builder's end customers exactly this service, so that you always know when a machine is going to fail.

How do you see this topic? How are manufacturer clouds developing, actually? Were you able to take anything away from the episodes, any new aspects in the direction of digital service?

Peter

There are simply a few unresolved areas of tension, and this is definitely one of them. The plant manager ideally wants all machines pulled together into one cloud and to monitor it there, and doesn't want a separate app for every machine. But that's exactly what the machine builders naturally offer. This discrepancy – because I mean, at the moment it's difficult to really get all machines into one cloud platform. So you're more dependent on: who already has something, how can I work with it?

And from my point of view that isn't fully resolved yet. And now it's important, a really central issue: in every tender for a new machine you should always write in that you want access to the data. But if you don't demand it in the tender – some still don't do that, which I find utterly fascinating – if you don't demand it in the tender, then afterwards you're stuck there wanting to pull the data from the machine builder's proprietary data cloud into a broader cloud. And then it doesn't work. That's obviously a big problem.

Yes, a really important point. And as you say, I think that hasn't fully resolved itself yet either. I think many of the larger corporations, and larger mid-sized companies too, are now integrating the manufacturer clouds into their own systems via an interface. But that's already very, very advanced. I think in mid-sized companies in particular many simply use the SPALECK cloud directly, probably first as, well, maybe a pilot phase. But as a manufacturing operation I don't only have the SPALECK machine, I have many others too. And yes, a more open architecture is developing there, so that you perhaps don't only go with the manufacturer cloud. But we can probably do a separate episode on that. Right, let's move on to the next case. That's episode 202 with the company ORGATEX. Here the aspect is digital documentation. Let's listen to the quote from Philipp Smolke.

Philipp

We have customers who, after we broke the numbers down together in a small analysis, simply assign two full-time FTE colleagues who do nothing but search all day long – which, with today's labor costs, very quickly adds up to a six-figure sum.

Then Philipp quotes a customer, I believe, who said the following to him.

Philipp

Dear Philipp, it's great that you offer rack labeling and container labeling and the KLT-Snapper. That's all wonderful and well and good, but I don't want 60 pages of paper in my KLT – I actually want a smart digital solution for it.

Yes, what was the interesting aspect in this episode?

Peter

Yes, I think digital documentation in particular is a use case of its own. ORGATEX originally comes from visualization – stickers, that's what stuck with me, the various markings they bring to the table. And moving from this rather physical world – I stick markings onto things – to IoT and the documentation of when, where and what happens and gets used: we'll come back to that in particular later. I think when we get into implementation, this whole topic of semantics, data, from Asset Administration Shell to Unified Namespace, these are the topics that play a role in this documentation environment. I thought it was described quite well there, how you get from physical requirements to digital requirements. That's why the episode was interesting.

Maybe we should also define digital documentation a bit, because we have so many different use cases on our platform here at iotusecase.com that cover different aspects. So anything from: how do I actually do remote reading in digital documentation, how do I automate billing, through to: how do I get structured access to files and documents? Keyword digital product passport – we'll come to that shortly as well.

Through to audits and reporting that a customer might need, and so on. So there are all kinds of things, right up to knowledge preservation. I was asked that again recently: how can I actually preserve the knowledge of my employees who are getting older and may leave the company? So there are all kinds of interesting aspects. All of it has already been solved, technically as well by now. But yes, those are perhaps the use cases behind digital documentation. And I think we'll look at ECLASS and the Asset Administration Shell shortly. Was this really a nice practical use case here? Do you have any other aspects you'd highlight from this episode where you say, hey, that's something else, that wasn't clear to me before or was somehow new or interesting?

Peter

As you say, this breadth of use cases. We also talked about certificates there, CO₂ footprint, compliance with all sorts of requirements that arise. So simply this breadth of documentation – I think that's an interesting topic in general. And it's not all in that one episode, but it runs through many of the recent episodes where we kept coming back to it as a theme. The implementation then makes it interesting again, of course.

Yes, absolutely. I'll just put the link in the show notes if you're interested. Have a look, and above all at the IoT aspect there. So how do I then work with live data in the area of digital documentation. Right, there's a whole lot there, a chapter of its own. Do have a look. So, now I think we're getting a bit more technical. Please don't switch off now, it's not that technical. But we want to talk a bit about data architecture and IT/OT integration and what's new there, explained at a practical level.

For that, let's first listen to episode 205. There we're on the shopfloor. It's about how to write data into the ERP via OPC UA, with the Giesser Messerfabrik. Let's hear what Björn, as the user, says.

Björn

I love it and I always call them scalable systems. Always start with something, also breaking the ice with employees, with the managing director – all the decision-makers are, thank goodness, right here with us, we're relatively flat in structure. I don't need that much convincing. But that's often the problem: when you have a system that is very large, it's harder to convince someone to spend 50 or 100,000 euros, and then there isn't the one factor I can offset it against and say, look, I'm saving this and that much. Instead I first have to build acceptance for such a system. And that's where it lends itself perfectly, that I can create an application with the very first board that solves a large share of problems and thereby also paves the way for me, and then I have a system that isn't – now I've bought the small solution, now I have to throw it away again and it has to be the next bigger one – instead it's like a modular system that fits together. I also don't have to have the hub right from the start, but once I've installed the third, fourth, fifth board, then I get to the hub.

Yes, I found two aspects interesting here. He talks about acceptance, employees – so the whole topic of change management – and at the same time about scaling. Peter, what did you find interesting in terms of scaling here?

Peter

Yes, precisely these scalable systems as the approach, saying that in many areas you simply have to start step by step. That's what I'm doing right now in my current use case. We do everything with generative AI for organizational development. And this step-by-step approach is extremely important to me: that you quickly get to first results, but that you're then not left standing alone – you can build on it and develop the next thing and the next and the next. The big grand slam is always a risk, especially when things get complex. Complexity is often underestimated and then projects fail with a lot of money spent, because people took on too much at once. So a staged approach in IoT, just as with generative AI for organizations, makes a lot of sense. They show that very nicely in the episode.

It's about these Peakboards, which are industrial visualization computers. You can attach one to a machine relatively quickly and configure it yourself. What was really interesting was that I've rarely experienced such an enthusiastic customer. Someone from the factory, a factory manager, who was so enthusiastic that as a non-IT person he can configure and set up these things himself.

Because he simply brought that enthusiasm, showing that this is a sensible way to get to results quickly and keep expanding it, while also being taken along so that it doesn't remain piecemeal. It is of course still a problem if these are just isolated topics that don't mesh together. But then at some point in this case, for example, this hub comes in, which pulls everything together again and makes it orchestrable and manageable. Then you don't have to tinker with every individual topic again, you can manage it all via the hub. These are topics that from my point of view make a lot of sense in terms of an application.

Yes, exactly, and I should say that Björn Mutschler here is Head of Production at Johannes Giesser Messerfabrik and therefore someone who has the whole factory in view, from a commercial perspective as well. And also with us was Thilo from Peakboard, as you said – Peakboard, our partner, who offer this solution.

And maybe a quick bit of context in case you're wondering what Peter means by "we": Peter, you have a dual role. On the one hand you're here at IoT Use Case as a host on the podcast, supporting the team, and you also have another role on the topic of AI. So if you're interested in learning more about the topics Peter brings up here and there in the podcast, do reach out to him. I think, Peter, your contact details are in the show notes as well. You've been doing this for years. And I should say we've known each other forever, from our Siemens days. And yes, now your focus is on AI. So do get in touch with him if you like.

Right, cool. Otherwise: the second aspect was this topic of acceptance and change management. I found that interesting too – which episode was that just now? That was the episode, I think it was with SPALECK, where you're also the expert for the machines. And in any case I find this aspect interesting for change management: that you start out and say, I have a use case here, I'll just get going, and then you see the data and suddenly it becomes clear: hey, I can see that too, and that's another effect, and couldn't we do this and that with it as well? So often that's when the ideas start to sprout. And I do think it's good that you build it up as a scalable system yourself, saying I'll start small and expand it over time. Or how do you see it?

Peter

Yes, that's exactly it. That you bring the people on site along. You always have to be careful about who you bring along and where. It's the people in the factory, but also management. Everyone needs those first moments of success, that understanding. It has to be built up first. That's also one of the answers we discussed in the last episode, for example, which I think I'll keep coming back to a few more times. We spoke there with Next Level Mittelstand and SCHUNK.

What's really interesting is this: how do you take the people with you? And there, first small successes are very relevant on the one hand, but so is the vision – where should this be heading, in other words target visions. And the last episode was incredibly good, especially in the context of change management, because it doesn't only start with the people on the shopfloor, it's just as important with the managing directors, commercial, technical, whichever. And I think there's a great, great deal more that can be done.

Yes, cool. Before we get to SCHUNK, just quickly two more episodes we'd like to tease. That's episode 215. It's about Unified Namespace with the United Manufacturing Hub. Those who've been listening to the podcast for a while: I did an episode with Frank Thelen on that topic. This is an update episode and it also goes a step further, specifically in the direction of AI. So do listen to that episode, it's episode 215. And then another episode, number 207. Really an important and interesting episode right now on the topic of the digital product passport. It's about ECLASS and also the Asset Administration Shell, with the company WAGO. Do listen in, an interesting episode. And then episode 201. That was about a private 5G campus network. Let's listen to what Julian from Salzgitter Flachstahl says about it.

Julian

So we have an AGV, an automated guided vehicle, that has to cover a distance – not a big one – of 85 meters each time. And it does that with two coils. Coils are our rolled-up flat steel products. The vehicle is called by a crane operator. So he has a warehouse management system, presses a button, and then this vehicle has to start moving.

Then he can place these coils on it and then it drives, and that's the special thing with us: not only inside the hall, it also drives outdoors. And what's particular is that this vehicle, alongside all the safety equipment – meaning it drives without fences. That's already the first high level you have to meet, 100 tons without fences. Collisions aren't much fun there. There are emergency stop switches at the operator's station.

So that means safety communication: I see a fault, I have to press it, it has to stop, it has to come to a safe stop. We have applications where we used really good WLAN technology from other manufacturers, which also ran stably for years, until someone turned up with a truck with a concrete pump and operated his concrete pump, and that then interfered with something, because the frequencies hadn't been taken into account beforehand.

Yes, I'll stay with that last sentence, because I find it particularly interesting from a technological perspective, since many people say: we have Wi-Fi here, our applications run, so why 5G, why do I need a private 5G network? And I find that interesting because he says certain frequencies weren't taken into account, and that's a nice aspect of the 5G topic, why you would deploy it. I found that interesting towards the end. What did you find interesting about this episode?

Peter

Again, this range of possibilities. We talked about LoRaWAN, Narrowband IoT, MQTT and the like. 5G is then of course – a private 5G network is another matter entirely in terms of how it works. And placing that: when do I actually need it? Here you see it with these 100-ton trucks that are also camera-monitored, high-frequency; camera images in particular, image transmission, is a topic where 5G lends itself.

You have completely different requirements there than when a small IoT sensor transmits a small mini data packet once an hour. And this range is interesting, because with Siemens and Salzgitter you have two heavyweights involved. I don't think 5G is relevant for everyone, and definitely not a private 5G network, but where it is relevant it's a very interesting episode.

Yes, absolutely. And I think there will be both. There will always be the WLAN use cases and then also 5G, where you have the use cases he describes here, the use case in the production hall for the AGVs, where signal strength but also these frequencies have to be taken into account. So there are lots of use cases coming up now that are interesting. And I found it interesting to hear it from practice for once, how Salzgitter Flachstahl does it. Do tell us what use cases you have. You've heard a lot now, and we'd be interested too. Do write to us. And do send us questions if you have any. This year I'll also be doing a few special episodes where I answer community questions. My and Peter's contact details are in the show notes. And now we come to the announced episode that we already heard in the intro, episode 220. And we'll just listen to the quote.

Henrik

I think Peter put it in a nutshell. I'd like to discuss what you said, Peter, at the next Mittelstand meeting, at one of the next roundtables or sessions we have. How could we perhaps even develop such a target vision together and extend a helping hand to SMEs, to mid-sized companies?

What exactly did Schunk do here? Could you summarize that briefly?

Peter

Yes, what really excited me about the episode is that we actually moved a bit away from the use case, which was about data transparency, availability of data so that you can go on to use it, and data sovereignty too – STACKIT from the Schwarz Digits group was there. So in sum the technology was very, very interesting, we could have discussed it forever. But then we turned off and talked about: well, why does it fail? Why doesn't it work in mid-sized companies, so that they make swift progress, including on digitalization? Some really good examples were mentioned, very concretely, about the conversations going on and so forth. There's the Next Level Mittelstand initiative that Henrik Schunk launched, which is partly about exchange. Similar to the IoT community now, where we've had really substantive discussions recently, where this topic came up as well: why does it fail?

What we agreed on was in particular this: the vision is missing, these target visions, this "how do we actually want to move forward?". We've now talked about a lot of topics, about how you could do it technologically. And then at the end someone is perhaps standing there saying: well, and now what am I supposed to do? And up to now – if we take the topic of AI, we've talked a lot in industry about classic AI, machine learning, training your own algorithms for machine failures, for example.

But now there's the new AI, this new AI world of generative AI, and along come these large language models, and they really are large, really big, they already have an incredible amount of knowledge inside them. And what they can do is exactly this: structure such topics, in the sense of: well, how should I proceed? Most people then think: well, how can I deploy AI later, for documentation for example. But very few are thinking right now about: how can I get help from AI, get support in describing the path?

You can tell I'm passionate about it, I have to rein myself in a bit so I don't go too far. But it was about using generative AI to create target visions. Where should this be heading? And target visions that everyone understands, from someone working in the factory up to the CEO, perhaps in different ways, at very different levels of detail, visualized – that's where AI is currently very, very strong, this generative AI. And you no longer need a consulting project, which is what it might have been until now, over weeks, discussions and alignment meetings and expensive consultants in the building. We do that, for example – my company – in a single workshop day, a bit of preparation, a bit of follow-up, and then you've worked out great target visions and made a plan for how to proceed with digitalization now. And I think that was a really, really strong episode, addressing and discussing this fundamental problem. So in my view every mid-sized company really should listen to it.

Exactly, we'll pin it somewhere right at the top for you, and do save it again. And what are the hurdles, then – why does it fail? Do any other things come to mind that we've just discussed? For me it's definitely too many players, and communication is definitely a huge issue. Does anything else come to mind right now?

Peter

Well, maybe also: what doesn't it fail at? It no longer fails at the technology. I think that's very important to understand. Just going to your website and looking at all the use cases. Right, it's up now. There's basically a solution for almost every topic. One use case, one solution, one provider who has already done it. You don't have to reinvent everything yourself. So now it's more a question of: does it rather fail at the people?

Also important. iotusecase.com, by the way.

Peter

That this understanding is there, and process understanding too, because processes often aren't documented, aren't clear. And that's where generative AI can suddenly help everywhere, because it helps to communicate, to communicate understandably, it helps to structure complexity. It doesn't resolve these issues completely, but it helps enormously. And it's still hardly used for that, far too little. And that's a shame.

And on the question about classic AI and how to deal with it, there's no blanket answer, so to speak, but generative AI can also help build a plan – how do I even go about it, how do I get to data? You can actually also use it to support data labeling and so on, to create data structures. So suddenly, with this generative AI, you have a tool in hand that in a great many aspects – especially along the way, as I said, not just at the goal but along the way – can help you make progress.

I completely agree, exactly. It may still be too technically complicated for your own service and sales staff, or the communication work behind it, as you said. And perhaps also too high an investment before you see any benefit at all. We had that with the Peakboard episode too: it starts small, where he has a use case that delivers real value, and then you can develop it nicely. And as you say, the AI aspects are of course a huge chapter too, with lots of use cases that deliver value.

But there's also this topic – we didn't cover it in detail today – this topic of trust, governance in data exchange, keyword ECLASS. We did an episode on that, do listen in as well. I'll have to look up which one it was. I'll put it all in the show notes. So that's another important point about why it fails. And yes, you can simply learn from that, I'd say. And now to the topic: what do I do if my machine doesn't deliver the data? Do you have a tip or a recommendation on how to go about it?

Peter

That depends heavily on the individual case, and at the same time, again, using generative AI, for example, to make a plan for how to get at the data and how to structure and label it – so the whole topic of: what does semantics mean here, what do the individual data points mean? For that preparation work, generative AI can now provide support as well. So it doesn't solve every problem. If you have no data, you can't train a model, that's simply a fact.

But you can at least make life easier for yourself than it used to be.

Now that I think about it: I'm doing an episode soon – do subscribe to the podcast – and it's really interesting. We've already discussed the content, with Cumulocity, and it's partly about the fact that they're now joining forces in ecosystems with manufacturers of, I don't know, various packaging machine builders, pump manufacturers and so on. And I could imagine that in the future, when you have an ecosystem like that, labeled training data will already be available. So for a specific case that I perhaps didn't have in my production, but somebody else did. Wouldn't that also be an approach – that in the ecosystem of my cloud provider, Cumulocity for example, who work with a Microsoft, there's already an approach? Isn't that a thing too? That's how I imagine it, I don't know, I can't look into a crystal ball, but that way you could also read the manufacturer data and these error logs from a similar device, where you say, well, that case has happened somewhere before. You know what I mean?

Peter

Well, ecosystems are a very big answer to many topics. And especially this Next Level Mittelstand that we mentioned, IoT Use Case as a platform – so these ecosystems where people report to each other about, and that's the entry point, simply about problems, and how we can tackle problems together. Through to the next step, data exchange. There are also many initiatives there that we've discussed partly critically in the episodes, like Manufacturing-X and the like.

But there's already a lot out there. You do have to bring a certain openness to it, though. And I think, as I said, it always comes back to understanding: where do I actually want to go? And if I see for myself that I won't get there alone, then the approach we always factor in almost automatically follows: how do I go into an ecosystem or work with partners? Who do I need as a partner to reach my target vision? That often gets neglected. Companies look through their own lens and don't look further afield into the ecosystem, perhaps also because it's sometimes too complex for day-to-day business. Yes, AI can help there too.

Their own world. Yes, absolutely. So perhaps physical limit values or expert knowledge from certain trained models will at some point be available in an ecosystem through the data. I'm looking to the future with great curiosity to see what else comes. And I know someone in our user group once said: when the motor spindle – they have a motor spindle that runs continuously with those operating hours – that they simply run tests, endurance tests in the lab, to generate these artificial failures.

I don't know whether that's a thing too, but I think a lot of companies do that, running them right to the limit to see when they fail and what kinds of errors there might be in the upstream and downstream processes. But then, as you say, you have to look at the individual case: what kind of use case is it, what kind of device is it and so on. So if you're interested, do reach out to Peter. It's interesting what he does on the side with his company.

And Peter, to sum up: I'm grateful for your time. It's great that you did this. You did a really good job. I find the episodes really interesting. And yes, I'm going to bring in a bit of new, fresh momentum again. I have a few things I want to innovate again, bring in new input, a few new topics. And yes, I'm really glad to be back. We'll probably speak again and maybe we'll even do another episode together, if you … and then let go.

Peter

I'd be very happy about that too. And thank you as well for the trust in letting me take over your podcast for this time. I enjoyed it a lot, it gave me many insights, and it was important to me to continue it the way you did it too, very friendly and personable. With a certain structure as well. It's a specialist podcast, so it's sometimes a bit of a challenge – you can't focus so much on the people. We actually cut things down even more in the last episodes, going straight into the technical topics, not so much on the people.

I almost always felt a bit sorry about that. It's the same for me: when I listen to a specialist podcast like that, I want to get to concrete insights as quickly as possible. We changed that around a bit there, but that's why you do it exactly like that again – you do it brilliantly anyway, with fresh momentum too. And maybe the odd episode that isn't so use-case-focused, but more like the last one, taken up a bit more generally with decision-makers.

That might be quite interesting as episodes. Maybe, dear listeners, you know managing directors or the like who have understood it, who may already have developed a target vision, so that you could discuss something like that too. A level above the use case, because many use cases eventually add up to a target vision again. That might make it quite interesting. Right, so: in any case I'll remain a loyal listener of the IoT Use Case Podcast and look forward to the next episodes.

Thank you. And as you say: if you have episodes or topics, speakers, whatever it may be, do get in touch with me. And if you have feedback, always welcome, write to me on LinkedIn or by email via our website. And I always look forward to shaping this format optimally for you. I enjoy it a lot, and so do many of the speakers. And so I'm looking forward to the future. So then, take care and we'll speak again very soon. Until then. Bye.