Groundwater lowering in the excavation pit made smart – that’s what the use case of the 39th IIoT Use Case Podcast episode is all about. Turck and Hüdig digitize water pumps and make worst-case scenarios such as overflowing excavation pits a thing of the past. The interview guests in this episode: Olaf Ophoff (Turck), Sai Seidel-Sridhavan (Turck) and Christoph Kehe (Hüdig).
Podcast episode summary
“In the IT world, anything is possible: once the data is digitally available, the possibilities are endless.”
The use case is about the groundwater lowering process and how it is optimized in multiple ways through a holistic digital solution. When do you need groundwater lowering? In short, whenever you undertake a construction project where you may encounter groundwater. The classic application target group includes larger construction companies, civil engineering companies or water drainage service providers. Different systems can be used to keep the excavation pit dry. Hüdig’s system is a pump unit that pumps out the water via vacuum solution. The practical users of these pumps wanted the manufacturer to provide monitoring, a way to digitally monitor the groundwater drawdown – even remotely. Thus, the use of the smart cloud solution was born in collaboration with Turck.
Turck’s core business is the automation world. The medium-sized company sees itself as an enabler of digital solutions by offering its customers cross-industry electronics, control technology, software and platforms, allowing them to assemble their applications according to a modular design. In the case of the use case in this podcast episode, a technology was used that makes it possible to mount components directly on the machine that previously had to be located in the control cabinet – a decentralization at the plant with many added values that will be discussed in detail in the course of this episode. The device is equipped with a touch display that directly visualizes the data obtained, and the control technology is also already integrated. Additional modules, such as serial interfaces or wireless connections for the cloud, can be added virtually “piggyback”.
Digital data acquisition enables early detection of faults and immediately prevents major water damage by automatically notifying affected users. This is important, because the pumps for lowering groundwater must perform 24/7, but are usually connected to the construction power distributor, which does not always shine with a stable power grid. In this way, high costs can be prevented. Maintenance also becomes predictive by monitoring service intervals and pump conditions based on data such as operating hours or vacuum values. However, the goal of automation should not be to get as much data as possible into the cloud, but only the data that is really meaningful, says Turck.
Other topics in this podcast episode: pay per use as the method of choice for cloud solutions, smart data instead of big data, optimization of information chains and added value in intralogistics.
Hello Olaf, hello Sai and hello Christoph, welcome to the IIoT Use Case Podcast. Glad to have you guys with us and that you took the time. I would just start right off with a quick round of introductions. Olaf, could you say a few points about yourself and briefly tell us what exactly you do at Turck in terms of the core business model?
You’re very welcome, I’m happy too. I am Olaf Ophoff and head of the Automation Systems business unit. At Turck, we deal with everything related to automation and automation solutions. Turck is a medium-sized company with 640 million euros in sales and around 4,500 employees worldwide. Above all, this includes the entire product chain that is needed in automation to create solutions – in other words, from sensors to fieldbus technology, control technology, cables and the cloud. And that’s the topic that we brought today.
Sai, I’ll hand over directly to you, then you can join right in with your brief introduction.
I am Sai Seidel-Sridhavan and I am mainly responsible for Product Marketing in Corporate Marketing at Turck.
Thank you very much. You brought your customer with you today. Christoph, would you also like to briefly introduce yourself and say a few points about your core business at Hüdig?
My name is Christoph Kehe. I am a master electrician and automation technician at the Hüdig company and work here from beautiful Celle near Hanover. Hüdig is a company founded in 1902 and originally started with turned and milled parts in mechanical engineering accessories. Then, however, the first irrigation and pumping units were developed relatively early. In this area, we are now among the market leaders here in Germany and Europe. Today we brought you a nice project example from the field of groundwater lowering. The issue always arises when the water needs to be pumped away from where it is currently disturbing.
I would also ask there again in detail what exactly the groundwater lowering means and how IoT can perhaps help. First, a quick question for you, Sai. You are now active with very different customers. What new challenges do you see in terms of digitalization that are moving you?
One important point that we have noticed more and more in recent years – especially from our customers and this is very cross-sector – is the so-called modular machine construction. This means that we are increasingly finding ourselves in a situation where machines have to be adapted, where adaptation times naturally have to be extremely short, and where modularization plays a very important role in the planning and design of a machine – both in the hardware, which is to be modular to a certain extent, and in the software. In hardware, this is primarily the topic of IP67, which is a piece of our DNA where we place a very large focus on ensuring that products do not disappear in any control cabinets, but are on the machines. However, also in software: For example, I have a colleague who keeps talking about how software as a whole has become modularized over the last few decades, where the industry is simply following suit. Decentralization to the field, decentralized automation – these are the major challenges to be able to achieve the one goal, a faster time to market, as efficiently as possible. This means being available on the market faster, but also being permanently fast and also being there for a long time and being able to adapt flexibly.
Now you’ve just mentioned “IP67” – can you briefly describe what that means in practice?
First of all, it is a type of protection. This is a standard that is required in mechanical engineering in order to be able to install components directly in a machine rather than hiding them in some protective housing. This means that on the one hand, they are robust against mechanical stresses, but on the other hand, they are also resistant to cleaning processes, etc. Olaf will certainly be able to describe it better in detail.
Exactly, maybe the question to you, Olaf: What is the relevance of this protection class in the field of modular mechanical engineering?
The interesting thing is that this IP67 technology means that the components, which were often otherwise in the control cabinet or for which an extra control cabinet was needed, with cabling and such things, are attached directly to the machine on site – much more decentralized and not in a cabinet. The advantage is that this makes it even easier to map modular mechanical engineering. I also save meters of control cabinets and metal boxes and things like that. All the cabling also becomes more efficient because the distances are shorter as a result. That is, it’s like decentralization to the machine, to the plant. It’s more smart units that are intelligent in their own right, but then interconnected instead of wiring all the inputs and outputs into a central control cabinet. That’s the principle behind it, which also makes it cost-effective.
I would now jump in a little bit on your joint project. Christoph, you had said that groundwater lowering is the issue here. Can you tell us more about that? In which environment and with which customers are you working?
To begin with, the question: what actually is groundwater lowering? This may not be such a clear concept to everyone. Groundwater lowering actually always comes into play or is necessary when, for example, I want to create an excavation pit for a basement or an underground garage, and I excavate this excavation pit and then relatively quickly encounter the classic groundwater. We may still know this topic from the sandbox in the past. This water must of course be removed there for the construction phase, because excavators usually swim rather poorly and the employees usually also not so well. Therefore, there are pumps from us, which are used for groundwater lowering. There are different systems that can be applied there, with which this area of the excavation pit is kept dry. This means that the water that flows in or flows against it is pumped out in such a way that it does not even reach the area of the so-called construction site or the excavation pit. Anyone who is interested in this a little more: We just had a cool project where repairs had to be made to a gas pipeline in a field after the fact and groundwater was an issue there. There is a short video on our YouTube channel where you can see how this looks in practice.
Let me ask you again: Who are your classic customers?
Our customers start with traditional contractors. We don’t usually talk to the builders themselves, but then we talk to the larger construction companies that take care of this pump technology. We talk to civil engineering companies, i.e. the companies that are actually responsible for creating the excavation pit, but also to so-called service providers who deal with dewatering – the whole handling of the groundwater issue on the construction site. That’s usually contracted out to third-party vendors, to service providers, who actually put the pumps there, install them professionally, and make sure that the pumps are running. That’s our core business and those are the people we usually deal with there.
When I imagine these different customers of yours, what are the classic challenges or tasks that have to be completed there?
The classic challenge is always a bit of a dichotomy. On the one hand, one can imagine that such a groundwater lowering has to run permanently, 24/7. It must not fail in between, because then I immediately have water, and no one wants a pond in that place. That is, some monitoring of security of supply is important at the point and is also the problem. Because especially on construction sites you often have the problem that the power supply is there, but sometimes not that reliable. Water runs into a cable drum somewhere, then the RCCB in the construction power distributor trips. Or our lines, for example, which are connected to the pumps, they work with vacuum. If, for example, there is an ineptitude somewhere because someone has tripped over a plug or something similar, then the system naturally breaks down or collapses. Of course, it is important for our customers to know that they will receive appropriate alerts – that is one thing, this worst-case coverage. On the other hand, we still have the service part, because of course such systems also need to be serviced from time to time. In case of malfunctions, the service technician should of course know where the machine is and what its current operating status is. It must be possible to answer questions such as: Do I now have to repair a water pump, an air pump, or is perhaps something completely different defective in the control cabinet? Of course, I can also transfer that via such possibilities. And last but not least, there is of course the classic part of the administrative act. Because where water is pumped out in Germany and pumped to another location, it always has to be logged. And of course, this can also be done wonderfully via cloud solutions, where I can carry out the corresponding evaluations automatically via reports that are linked to water meters.
Here’s another follow-up question: Are your pumps connected to the construction power distributor that you just mentioned?
Exactly. I’ll say that a large proportion of construction sites in Germany are really equipped with a construction power distributor, i.e. a fixed power connection. There are certainly exceptions sometimes, which are operated only by power generators. And there is also in the area of groundwater drainage partly even the intermediate solution, where one says: Primarily I operate myself via the fixed construction power, but I have a generator standing there. Because if the power goes out, my water still has to be pumped out – so the classic emergency generator is next to it as a backup solution. The whole thing always happens basically in the interest of the construction site operator. After all, it’s not just our pumps that need electricity, but I’d say almost every trade on a construction site needs electricity these days, such as flex and drilling machines or various other construction equipment that has a power connection. And everyone wants to charge their smartphone and the coffee machine always has to be running, too.
Now that I think about the administration, it sounds a bit bureaucratic. Who are you talking to at this point, who is interested in having it digitized?
Our customers always have to log this. That means they also have to submit applications if they want to lower groundwater at a site. In the sense of: XY cubic meters per hour are taken and this is discharged into the next canal or river. There are corresponding authorities, which must then also agree there in case of doubt and also want to know how much water was really pumped. In some cases, certain fees are charged per cubic meter, which are calculated on a time and material basis, so to speak – similar to the classic wastewater that you know at home.
If a pump like this fails now, who will do the service? Does it take over or is that a separate service unit?
Depends. For the most part, it’s something that our customers do themselves. This means that they have service technicians who are trained by us accordingly on the machines and can then carry out the maintenance themselves. However, we also have machines in our own rental park, which we then of course look after ourselves with our own personnel. Or even that the customer says: “My fitter is in Bavaria right now, he can’t drive to Flensburg. Can someone from Hüdig take over?” Sure, then one of our technicians travels to the site and takes over.
Now in the project we also talk about live data coming from a wide variety of hardware. Which metrics are interesting for you or your customers there?
It starts with the very classic condition monitoring: Is the pump switched on or how many operating hours has it run. Operating hours are of course again an indicator for billing the end customer or also for the interval of service and maintenance work. This is such a classic. Of course, fault messages are also interesting – that is, has a motor circuit breaker been tripped, do I have a fault on some sensor, or is the pump running outside a certain operating parameter that I don’t want. Very important in the field of groundwater lowering is the so-called vacuum value. This means that we have vacuum pumps on the machine, which is a split system. On the one hand, we are pumping air, so to speak, and on the other hand, we are pumping water. Because if I want to get the water out of the ground, it doesn’t come up to the surface by itself, but I have to suck on it first, like a straw. This is exactly what the vacuum pump does, and then this vacuum value that is present there is a very important criterion. Because only when the vacuum is high enough, the water also comes up. That’s why this is such a leading parameter that customers can always do a lot with and can also see well: Where is my machine working? How deep do I sink? How many meters deep do I actually get the water from? For example, it makes no sense to get the water from a depth of nine meters when my excavation pit is only three meters deep.
If I now think in the direction of this digitization solution: Up to now, a control cabinet was classically supplied, which was not yet connected to the Internet. Now you bring a lot of knowledge with you with the vacuum values, the operating hours, the fault messages, etc., which your customers can use to leverage added values across the board there. How do I bring your knowledge into the digital world at this point?
That was basically one of the biggest challenges for us at the point, because before we started digitizing, this pump was really very simple. As an electrician you would say: “Rattle technique installed”. That is, the pumps were simply started. Then there was a fill level probe and then that was actually already done at that point. Now we had to capture all these values digitally first. That means we first have to have digital parameters that I can then send to the cloud via an ether. That’s when the collaboration with the colleagues from Turck came into play. We have installed a touch display that offers the customer completely different display options of all operating parameters, which thus also brings added value for the customer on site. In addition, this display also has a built-in microcontroller, which then captures all my input and output signals. This is then also equipped with an attached modem, which then transfers the data to the Turck cloud portal via mobile radio. On the construction sites, we have to work via mobile radio, because there is usually no W-LAN that we can use, let alone a LAN cable sticking out of the ground somewhere. That’s why we do this via the classic mobile radio thing and then the data is transferred to the Turck cloud portal as I said, where it is then processed and presented in an appealing way for the customer.
Last question very briefly in your direction: This touch display, is it available on site, does the customer have it somewhere in his headquarters or how do you have to imagine it?
The touch display is permanently mounted on the machine. On this, the customer can operate the machine completely autonomously and set all parameters. Of course, we then mirrored all the information again in the cloud via the cloud solution, so the customer has it available anywhere in the world on their smartphone, tablet, laptop, wherever.
Olaf, a question in your direction: We have now talked about various hardware. Christoph had also just said that the whole thing works somewhere in the overall system. How do you come into play there now and how does this solution look holistically from your side?
Yes, what we offer at this point is, on the one hand, sensor technology to digitize things first. There are not only system states, but also the tapping of the useful data of the sensors, as Christoph just described, the vacuum, etc.. And the whole thing must first be introduced into this on-site device. If you will, this is a so-called all-in-one device. This makes it particularly interesting and easy to handle. There are digital inputs, there are analog inputs, serial interfaces. And in this way, I have this data digitally for the time being, with which I can then do something. And, as Christoph says, on the one hand, visualization on site on the screen, and on the other hand, using this one device, the whole thing is then actually transported to the cloud via mobile communications, just as our cell phones do, with a SIM card inserted. And when we talk about cloud, you can think of it like a website. That means this data is then accessible like a website with any device and from anywhere in the world with any data terminal – that’s the chain, so to speak.
Christoph had just spoken about a small control. This means that a small controller is also attached to this display somewhere, on which I can then carry out this pre-processing of the data. Or how does that work exactly?
It’s already in there. From the front, it is a touch display – again with a high degree of protection (IP66) – and the device not only contains the electronics that make the whole thing visible for the display, but also the control technology, which is integrated all-in-one. The device additionally has the possibilities at the back – we always call this “piggybacking” – to actually then put additional modules, in the case digital EAs, analog EAs, serial interfaces and also exactly this radio link to participate in mobile communications.
Christoph had talked about data bringing various added values for customers – be it the power supply, be it perhaps the administrative apparatus wanting certain data. Now that’s a logic that I first have to process somehow cloud-wise or on-site. Are you taking that logic and putting it into the data, so to speak? Or where is the overlap where you say this is what your customer does and this is what you do?
The customer usually, or in the vast majority of cases, actually designs his application. What are we? We are a so-called enabler for this. That means we have the electronics and the control technology, the control platform, the software platform, in order to be able to implement this as simply as possible, so that the user can then build his application with it. This means that we deliver the modular system with all the trimmings, so to speak. And the customer can then assemble it software-wise, similar to Lego.
Now we had defined different roles of the customers – am I with an administrative apparatus or am I perhaps a construction site operator. These are different roles that I have to map first. Do I have access for the site operator and then maybe I can also provide data for an authority or how does this role and rights management work for you?
Basically there are different roles, so that the one who has certain access rights is also authorized. And that way you can also make sure he has the qualifications to do that. This is mostly how I do it, by first extracting from the cloud and then putting it together again externally in a different way. The interesting thing about this solution, and this is really the crux of the matter, is that it suddenly combines two worlds. One is precisely this automation world in which we have all been at home for a very long time. Now that ties in with this classic IT world. In the IT world, anything is possible: once the data is there digitally, the possibilities are endless. And the cloud is precisely the means to the end of it all, to visualize, inform and extract reports at any time.
One more question about the hardware: We have now talked about sensors, control data and also connectivity, in the direction of mobile communications. Does that mean that the mobile slot is already integrated in this small controller plus the display, or how do you work there? Do you look at what SIM cards to install or is it a device that comes with all that already?
This is a device that also has this modular requirement, or let’s say this modular system, where I can then piggyback on something like this at the back, as I already said, which enables me to communicate in the cloud. The SIM card I need is the same one that goes into a smartphone. There is no difference. It’s the same mobile network, it’s the same card. And the other side, the connection to the server, that’s classic hosting, just like a website is hosted. What this device does: On the one hand, it uses the classic automation principles downwards – gets everything from the pump, from the sensors everywhere. And on the other hand, it plays that up with the IT principles and embeds itself there exactly in the things that we so often know from the smartphone.
Now we have talked about the technology and the hardware, also a bit about the logic. Many people are now also interested in the concrete business case behind it. I create added value for customers that goes beyond the actual hardware. So what’s the classic business model that goes along with that? Christoph, again in your direction: How does the new business model work from your side?
We at Hüdig are a classic machine builder or aggregate builder. We provide our customers with the hardware and accessories they need. This means that we equip our pump with the system from Turck adapted to our needs. The customer still provides us with the SIM card, then in that case we deliver the device or machine to the customer complete and fully functional. The customer then has with us in principle only the portal costs, the monthly fees that are incurred there. We see it more as offering this system to the customer as added value to our actual pump. Because the system that we have now set up there from Turck would be useless on its own for our customers. If I don’t have any data, or in our case I don’t have a pump connected, I don’t need to push anything to the cloud, so we basically unify that here at our plant and then deliver a fully functional pump for the customer. The customer then simply receives a short briefing from us – or from me in this case – and the access data for the cloud. And after that, the vast majority of customers find their way around relatively quickly – set up their alarms and reports there, and then it actually works like a charm at that point.
Now I must perhaps also ask a brief critical question: The whole thing is worthwhile for a customer if I prevent downtimes through these fault messages and I have a return on investment. I have various advantages by paying monthly, but on the other hand I also pay for availability somewhere. Is there any experience from your side, how often there are problems, how often such an RCCB trips and how often failures happen that really go into the money and are prevented with the help of your system?
The classic power outage is a common occurrence on the construction site. Construction site nets tend to be a very fragile system. There are plugs lying everywhere somewhere in the water, in the mud. This is all always associated with moisture – which brings us back to the IP67 story. Or someone arrives and now needs electricity for his concrete mixer and pulls out the plug of the pump because he thinks he can now use the socket for something else. These are the classics. This happens quite often. But this chain of communication is also an issue, which has been reported to me quite often by customers. As I said at the beginning, our customers are often third-party providers. This means that they are not permanently on site. They deliver their equipment there, set it up, then drive away again and come back at regular intervals to check that everything is in order. If a failure occurs – whatever the cause – it is of course extremely important to react quickly. That means that someone has to be on site quickly, and it doesn’t even have to be someone who is actually from our third-party supplier; the foreman on the construction site, who is on site all the time anyway, is enough to just take a look. Is the RCCB flipped back up? Do I have to put the plug back in? And here, of course, you can use such systems to make this information chain simple. Our customers often take the foreman – the end customer’s point of contact, so to speak – into this cloud alarm distribution. This means that he also automatically receives an e-mail and can say: “Pump XY is down, I need a service there”. This flow of information is definitely there and it is ensured that someone also takes care of it as quickly as possible to avoid major consequential damage. And in this case, there is not even much consequential damage to the pump itself, so not much can actually happen. But if the excavation pit fills up and there is an expensive renowned excavator or similar down there, then the damage can of course quickly run into the tens of thousands.
Are you actually seeing more of this in this construction site environment, that data is being shared with others in order to leverage added value? Is this coming more and more or is it perhaps already established?
The way I see it, this development is just starting at that point. In some places, of course, it’s already there and more established. I’m thinking, for example, of excavators that are laser-controlled to pull off the right height for some floor slabs or things like that. That goes more or less in the same direction. But let me put it this way: the younger the contacts at our customers and end customers become, the more interesting it becomes. Because the generation that grows up with a smartphone in its hand and does everything via smartphone and tablet is coming. I count myself among them. I also have a smart home. I would like to see everything on the tablet and on the smartphone. The generation is coming and with it, it’s getting more and more interesting. It is also the case that this whole project was also initiated by the end customers. I did think about how to solve it technically with the guys from Turck, but the idea that you need something like this came from the end customers. They approached us and said: “It would be great if I knew what our pump was doing 300 km away.
I also think that this is going more and more in that direction. The more digital the mindset is, the easier it will be in the end. Now I would make the transition back to Olaf. I have two questions – one for more transfer examples of this use case and one towards using it as pay per use. First of all, what are the expansion stages of this use case, how can I transfer it? You are working with different customers, aren’t you?
Absolutely. Pumps are a good example, but this is also the case in many other areas. One area, for example, is mobile machinery. Let’s think of lifting platforms, combine harvesters or even vending machines. Everywhere there, you simply want to have access to these machines so that they also have the necessary availability on site. And here’s what’s actually interesting: these machines are increasingly no longer obeying this principle. I build a machine, sell it, and when it’s out of warranty, the owner is responsible for it. Rather, it’s about these pay per use models. And that’s exactly where a connection like this and billing via the cloud are the means of choice. If I lend something out or, to put it more legally, rent it out, and I receive money for it, then I have a very, very high interest in ensuring that what I rent out also does what it is supposed to do on site. And this access is worth its weight in gold at first, so that you can say: “Press here, press there, and it’ll be fixed”. Or we send one out, he knows immediately what he has to do and actually has the right spare part already in his luggage. I would like to increase the availability of my rented work platform, so to speak. That is the very, very big added value. And the second is that I can be active pay per use in this way. This means that if someone wants to paint their house, they don’t buy scaffolding, but rather borrow scaffolding or a lifting platform. The same applies to concrete pumps, etc. All this is rented. In the agricultural sector, this has been the case for many, many years. Combines are very, very expensive machines. And a farmer, as a rule, no longer buys the combine himself, but borrows a combine. And he bills according to the area that was actually tilled or harvested with the equipment. And that’s the only thing he pays for. Cloud solutions have long been fully established there and are the means of choice for precisely such pay-per-use machines. That is the one point. The second is: The whole thing is also available in stationary form. Namely, where it counts. If we think about this whole area of travel and transport or infrastructure at the airport, such as baggage transport systems at airports from one plane to another with connecting flights. It all has to work like clockwork. This is purely a matter of availability. Pure availability can also be achieved through predictive maintenance. That is, I want to know before something breaks and not already let it come to the fault case. And that’s where these cloud systems play a very, very big role. This is also the case in the food and beverage sector, where there are chemical processes that cannot be reversed – everywhere where things have to run like clockwork. Everywhere such cloud possibilities and cloud applications are the be-all and end-all, and these are also increasingly actually the industries where we see and feel this and where it is well received. The other thing is: I can do a whole lot with a cloud. And what we’re focusing on here is smart data. We always say we need Smart Data, not Big Data. The Big Data story is often associated with this. In the sense of: Now I have a cloud, now I’ll get the automation data up there as well. No, we pull up exactly the data that is good for something and that is useful. Automation is not the kind of industry that says: I’ll just collect all the data and then see what I can do with it afterwards. That’s exactly what we don’t do, because it interferes with automation and makes no sense at all. What happens, however, is that I can get manufacturing data from different manufacturing plants. For example, I produce one and the same food product in different locations around the world, let’s say a frozen pizza. Then I can look at the performance data of these different plants – one is in Brazil, the other is in Germany and the third is somewhere in China – and compare them with each other and know where I can optimize or where perhaps the plant still needs help, because it becomes comparable that way. And those are the purely stationary applications that are also tremendously important when it comes to these things, and they’re often in intralogistics. And I think that’s the segue now into the topic that we also brought, Madeleine.
Perfect, maybe just a very quick interjection to Christoph before I get right to Sai. This issue of pay per use availability, are we seeing that in practice yet? I mean, this is a business model that I have to rethink holistically, perhaps away from the core business.
As mechanical engineers, we can of course think along these lines. But we always look at it from a different angle. As a rule, we rent the machine on appropriate terms – either by hours of operation, by days, by countries sometimes even by pumped volume, how much load the machine had to handle. For them, this is certainly an interesting starting point. For us as a manufacturer of the machines, however, this is not the focus. We offer that, of course, through these cloud things and leave free customers to share that. But as a manufacturer, we don’t have our hand on the data either, I’d say. The customer is then free to decide for himself what to do with it.
Last question for you, Olaf. Do you also provide support with regard to this business model development? Do customers approach you and say, “This is the business model, I need hardware for this,” or do you also take this holistic approach?
Of course, we also take this holistic approach, which is in fact increasingly the customer’s actual motivation and he is looking for a solution. The whole thing is also always connected, especially in combination with the automation world. That’s what makes it so important and so different from all the clouds that already exist in the world.
Okay, thank you very much. Now the handover to you, Sai. We had just briefly touched on intralogistics, Sai. You seem to be active there, too. What exactly do you do there?
Before I get to that, on the topic of local solutions, a quick preface. I’ve heard some things now already in the last weeks and months about the whole sensor data, just also in your podcast, which I appreciate very much. And what Olaf just meant is also a very important point. Getting the sensor data from a sensor into the cloud – that’s one thing. That is also something that is technically possible nowadays, and we can do it. But making smart data out of it that is usable by customers, by users, that doesn’t go up there without any pre-processing. That’s the crux of the matter, which we also take very strongly for ourselves. This can happen at a sensor where we process the data beforehand and push it up. This can happen in an edge controller. But it can also happen in the process itself. To get the transition right now. We have some challenges ahead of us, especially in logistics, with our in-house partner Turck Solutions, a solution partner for turnkey solutions, truly turnkey solutions especially in logistics, that we want to completely monitor goods, material, incoming goods and outgoing goods holistically. The goal is to be able to perfectly monitor the quality of the end products, that what we deliver to a customer or our customer delivers to an end customer at the end of the day. We have a company here, it’s all about tire production. Here we can automate this flow of goods in such a way that we can monitor the complete process from the delivery of the goods to the production of the tire to the delivery in the truck with the customer. And all that data goes into a cloud, too. If we are now back in this nucleus cloud: Sensor data, machine data, modular machine building, that’s all right and that’s all important for us to develop in the industry. If you look at the Industry 4.0 ideas of our federal government ten years ago, it’s about how do I turn the pyramid into a network? How do I make a cyber-physical system? This is a very important building block in mechanical engineering. In logistics in particular, it’s also about the processes involved that are being digitized. And we have managed with the customer to be able to monitor this inbound so well that he can also measure the tire quality against it at the end of the day. This means that if the tire quality is not right somewhere, he can go back through the entire process and see where the problem lies. And that’s not just the rubber, that’s all the materials around it to make a tire a tire. Implementing the requirements that customers and tire manufacturers give us into a large system is precisely our strength. A holistic system in logistics, evaluate a holistic process and set it up again to generate added value. Here, it is no longer a machine downtime, but rather a process downtime. Especially with premium tire manufacturers, of course, you don’t have such an incredible amount of tolerance, because if I buy a good coffee privately, I don’t want it to have no good coffee in it either. From there, that’s one way to monitor that through a holistic system. Of course, that always has a connection into a network, into a cloud, but where the cloud plays a completely different role. In this case, it is more of a data hub, a data center, to monitor and control the whole process holistically.
I think the logic of this one use case, which we have now taken apart a bit, is also quite transferable. Ultimately, it’s also about generating added value across trades through data that I might also network horizontally, isn’t it?
Of course, this can also be another point, but in this solution it was mainly important to be able to monitor this production. And sure, this transferability to other plants is also important, no question about it. In this case, it was especially relevant to package the transferability on media that everyone can handle. So there we are again at the point: what is the visual interface to the person who is going to look at this? That’s also part of this whole project. We don’t just have a few products that are in this plant and we look at that, but it’s about holistic processes. And these are, after all, the requirements coming from the industry. We’re no longer talking about “I need this and this product now” – that’s the one path. It’s more about, “I have this and this problem.” And the customer’s problem or challenge, as just mentioned, was: the quality has to be right. It is a premium manufacturer. As with the coffee example, the quality simply has to be right. Accordingly, this is the requirement with which we entered the race, and the solution via our colleagues from Turck was ultimately the key to success here.
Great, then thank you for the exciting input and session. One or the other who has found himself there, I think, can gladly contact you – online or offline – and take up the whole thing again in a conversation.