Asset Administration Shell in the Model Factory: Reconfiguring Production Lines Flexibly

Today on the IoT Use Case Podcast: the Asset Administration Shell in the model factory. How an abstract standard turns into concrete production flexibility. Our guests are Bosch Rexroth and XITASO. We talk about end-to-end data availability, different semantics – that is, the meaning of data in machines and subsystems – the relevance of OEE and line reconfiguration. Enjoy!

A warm welcome to the IoT Use Case Podcast, the channel with the most current IoT projects from our implementation partners in the market.

Hans Michael, when you look at the model factory in Ulm – which concrete production problem, or, if we don't have problems, then the challenge, do you want to make visible? Is it the data breaks, is it the semantics, is it OEE losses or line reconfigurations? What exactly is it about?

Hans Michael

Everything you just said. And we use it as a playground so our customers can see how certain topics can be tackled. It's often difficult to go into a real production environment, even when you'd like to show customers something. That's why we decided to build a kind of permanent exhibition with the model factory at our site in Ulm. And there we show two customer value streams very concretely. One is a consumer goods value stream, so practically from intralogistics, from goods delivery through manufacturing all the way to packaging and again palletizing and shipping out, and the other is the value stream of battery production, from cell assembly to disassembly.

Exactly as you asked, we show automation topics on the one hand, because with ctrlX Automation we are primarily an automation supplier, but also transport topics such as the connection between machines, mechanical topics, Condition Monitoring – because there are, for example, also linear guides from Bosch Rexroth, modules and so on – and Use Cases that build on that.

And one of the fundamental problems for many machine operators today is integrating machines into existing systems. We know this from some of our customers: they buy a new machine and then spend half a year somehow struggling to integrate it properly into the line, because lines are very rigid in the PLC and once programmed – and no one knows their way around anymore. And especially the topic of machine integration and reconfiguration of machines or lines is one of the topics we address with the Asset Administration Shell, precisely to solve this pain point.

Exactly, with the Asset Administration Shell we also have our highlight topic today, so to speak. It really is an exciting topic that has been part of the industry discussion for quite a while, but hasn't yet had that penetration effect across the various areas. Michael, how do you see the topic of the Asset Administration Shell in the context of the model factory? You supported its introduction there. What does it bring in that context, and what do you want to achieve with it?

Michael

First and foremost, it provides a standardized way to connect machines and plants, and also AGVs, for example. For me, connecting the plants is the priority. And in a brownfield setting. In an automotive assembly plant, nobody asks the question of connectivity anymore. It's completely clear that data is transferred along the structured value stream too. Now in a mechanical manufacturing setting, as shown for example in the model factory in Ulm at Bosch, we're simply still far from that in practice. The plants are already there or are newly procured. The use cases change, the whole factory changes constantly. And the challenge is always to carry the data along, and to do so as seamlessly as possible. You already mentioned OEE in the introduction; when it comes to manufacturing, that is simply decisive.

That's how we unlock the potential we have in our high-wage country, Germany. And anyone who still wants to produce, really seriously, in Germany absolutely has to think about the data and connect it. The Asset Administration Shell is a very suitable technology for that – alongside many others, that's part of it too. The Asset Administration Shell is suitable for moving data within your own plant, but also beyond company boundaries. That's what the standard was created for, that's what it's intended for. And of course you have to populate it. At first that may seem a bit unwieldy – much like the German word Verwaltungsschale – but in the end it delivers the potential. That's what it's designed and made for, and we were glad to be able to implement it with Bosch in Ulm.

Hans Michael

The term really is very bureaucratic German. To be honest, you don't immediately feel like using it. Maybe Asset Administration Shell is somehow more dynamic after all. But in the end it's the same thing. And I'd like to add one more point to what Michael says. For us it's not just about this data continuity, because you could actually establish that in other ways too. With ctrlX Automation we can access control data via OPC UA, REST API, pretty much anything. For us, in this case, it's about flexibly configuring and reconfiguring the line based on the Asset Administration Shell. Because we built a tool for that, the Asset Orchestration Platform, in which I model my line. As soon as I have all machines available as an Asset Administration Shell, or all machine modules, I can start to flexibly design my processes with business logic, instead of hard-coding it into a line PLC.

And that gives us incredible flexibility. In the model factory, for example, we can reconfigure relatively quickly between AGVs and machines. Because even the floor has an Asset Administration Shell, we can also change the color relatively quickly, or every light fixture has an Asset Administration Shell here. And that gives us a fantastic ability to reconfigure, test and quickly re-implement, which, let's say, ordinary machine operators just don't have with a line PLC.

I'd like to stay with the model factory a bit longer – and with what is set up there as a value stream: where are the breaks in this value stream? So did you deliberately build in breaks to show that this can also be transferred to other regular factories, or is it always seamless?

Hans Michael

Yes, so one possible break we were able to address was, for example, the flexible switching between a stationary machine and a mobile machine, meaning an AGV or AMR system. So the communication between machine and AMR, or the reconfiguration of the AMRs that you see in the model factory, is a possible break. How do I bring my AMRs and my machine configuration together? And together with XITASO, for example, we created an Asset Administration Shell for each module of our battery assembly and disassembly line, precisely to be able to control the modules flexibly. XITASO helped us a lot there, because – I actually have to admit – the first hurdle to using the Asset Administration Shell is the Asset Administration Shell itself, and the creation of an Asset Administration Shell. As with every benefit, I first have to make a real effort in order to actually see the benefits. And with that level, that effort, XITASO helped us a lot – to create the Asset Administration Shell in a standardized way.

It's already in the name with “administration” – that always carries a slightly negative connotation in Germany these days. But, Michael, maybe you can explain again, and vividly, what's actually behind it? What is the Asset Administration Shell? How is it even defined? And how can someone understand it who perhaps hasn't heard anything about it yet?

Michael

Yes, the Asset Administration Shell itself is actually explained fairly quickly. It's simply a standardized way of structuring data. In an on-site talk I once used a lever-arch file to make the point – and in it there are many different divider sheets, and between the divider sheets lie the pieces of information. And at the front the lever-arch files have this hole, and I then ran a red thread through the hole and linked the other end of the red thread to any point on the data sheet. And that's actually what the Asset Administration Shell does.

There are various subsystems, you have to know that as well. The Asset Administration Shell contains subsystems that are defined by the standardization organization. And then there's the Nameplate subsystem, for example – that's one of the simplest ones: a digital nameplate. We implemented that very successfully for one of our customers, the company WITTENSTEIN. The use case there was: they wanted to save on documentation that today is shipped along in paper form, in many different languages. And that worked out quite easily. You say: okay, I take the digital nameplate as a submodel of the Asset Administration Shell, then fill in the fields the way the standard specifies, and with that I've created a standard for my product, which in WITTENSTEIN's case is then built into other systems again, and the documentation travels along, so to speak. The customer then has 25 different WITTENSTEIN drives installed somewhere, and the data can now be accessed freely via a QR code or Data Matrix code or the like, in this standardized format. Neither more nor less is the Asset Administration Shell for other submodels too, such as Skills and Capabilities – we've now used that in the model factory. It's always a bit more extensive, but in principle it's always about making the data available in a form that other companies and other users can also read and would fill in the same way.

Otherwise the classic mistakes happen: article designation – one person sees it as their trade name, and the other writes in what this product can do. And right away there's an incompatibility, and the data can't be used that way; instead it first has to be normalized again, brought to the same standard. And that standard is often different from country to country and from company to company.

I think it's probably not that easy to understand how important semantics are – that is, understanding the data – if you haven't felt the pain yourself of wanting to make use of something like that, or of reconfiguring machines and then having all this effort of explaining this new configuration all over again in your own setup.

Hans Michael, then also in the sense of Bosch Rexroth: where else do you use this? Now, the model factory is a really great case where you can actually observe, examine and visit it. But do you have it in use elsewhere as well, and where is that – what kind of benefit does it bring, so what kind of value?

Hans Michael

Yes, well, of course, the model factory is always something you can simply show to customers. So anyone who's interested: feel free to just come to Ulm and drop by. It's near Augsburg, where XITASO is – not far away, right, Michael? So we're currently rolling it out internally at Bosch. There are Bosch plants that have also come under pressure from the demand to be able to produce flexibly. In the past, Bosch plants produced a million ABS, or several million ABS systems, per year, and the lines were relatively rigid, and you didn't change them much. Instead, when a product was phased out, you'd rather redevelop them or move them elsewhere. And now there's stronger pressure to produce more flexibly, in the Bosch plants too, where it's a matter of millions of units. And there are some plants that are currently developing flexibly configurable lines on the basis of the Asset Administration Shell, or the Asset Orchestration Platform, as we call it as a product. But it's not only the case in our own plants, but also at many other customers.

In the automotive Tier 1 segment there's another user for the Asset Orchestration Platform. But we're also talking with machine builders – interestingly – about the topic, who often don't just sell individual machines to their customers, but rather half lines or sometimes entire lines, and who are also looking for a flexible, reconfigurable solution in order to integrate their machines well at their customers' sites. So it's slowly catching on, that's my sense. There's demand for it. The users see the benefits, which, as I said, we show them very vividly in the model factory too.

How do you distinguish this from other data formats, for one? There are various formats, after all. What else is there that might be an alternative, or also systems like an MES or similar? Michael, how would you distinguish it, again, from what's already there – what kinds of alternatives there are to the Asset Administration Shell?

Michael

As basically already mentioned: the Asset Administration Shell is one technology among many. We have OPC UA, we have MQTT – by the way, we used all of that in parallel in the model factory project too. Which protocol and which technology is suitable for which use case? That's the most interesting question we face as a software development service provider. And there we're technology-agnostic, so we're completely open. You have to consider: what's already there, what code should be used, what systems are already in operation in a manufacturing setting like this? They often have 50 or more systems already in use when we're talking about a brownfield factory like that. There's no point in us coming along with some great new technology and saying: yes, with this everything gets better. Instead, the important thing is to integrate it together, bring it together and look at: what do I want to solve, and which technologies are suitable for that? Usually there's more than one.

The Asset Administration Shell is well suited to guaranteeing, to accomplishing, the exchange across company boundaries. Registering a new machine – so many automotive manufacturers buy their production lines from all sorts of suppliers and write into the specification: for registration in my factory I'd like to have the Asset Administration Shell, simply so that the commissioning process is accelerated in terms of data management. For issuing individual motion commands, the Asset Administration Shell is certainly too clunky – you can do that well with MQTT. Transmitting sensor signals, say from a small level sensor that monitors the coolant right at the bottom of the plant – you can certainly do that excellently with OPC UA.

And in the interplay of the different protocols and technologies lies the potential we have to unlock together in order to stay competitive. And that's why it's so interesting for us as a service provider to get a picture of the situation on site and then select the right technology, so that afterwards the customers can also keep working with their solution. Our goal is to enable, to accelerate processes, to get them going, but then also to empower the customers to live and work with their own systems. And there's clearly an advantage when you use standardized protocols and technologies. That reduces this truck factor. We all know that one specialist who developed the plant 20 years ago, in terms of software and control technology, and then at some point wants to retire, and no one can pick up where he left off. When that person is on vacation, you have to call them back if there are faults. You can simply avoid and prevent that by documenting things relatively transparently at various levels, making the technology choices together and using the protocols the way they're intended. And in many cases it simply exceeds the core competence, or just the capacity, of the customers. And then it's good if they turn to people like us at XITASO, who deal with this every day and, thanks to the broad spectrum of customers and use cases, then also know what's best to use.

Why hasn't it caught on more yet? What difficulties and complications do you see? Thinking in different directions, perhaps: one thing may be the technological implementation, the other is organizational topics that play a role here. So which areas do you see there?

Michael

Yes, a diverse spectrum. I have a long background – I worked in production myself for 25 years, and as a production manager. One obstacle, for a start, is the network. So anyone who deals with production knows: the machines usually run on a separate network. It's often physically decoupled from the outside world, from the internet. Then someone has forgotten a laptop somewhere in the control cabinet, and now we do have the connection after all. But people are afraid of making their core competence available to the wide world, to the whole crowd. That's why the machines are shielded off. We hear about some cyberattack or other every day; it keeps getting more radical. That's also why people are afraid of simply hanging the machines onto the internet now. That's a big hurdle, but one we have to overcome together. We have to look for solutions for how you can have the advantages of connected manufacturing and still keep the risks under control. For that there are pen tests and strategies for how you can set up cybersecurity, architecturally.

Would you say – a very quick interjection – that the Asset Administration Shell only makes sense with the cloud, that is, with internet connections, or can you also set up and use something like that locally?

Michael

Yes, you can set that up locally. You just have to create an architecture that allows me to keep enriching the data. Every product can – yes, you mentioned ABS to me earlier – every product can get an Asset Administration Shell. I just have to keep the system open enough that I can also write this data somewhere and store it on some server and have access to it again afterwards. But those are the prerequisites.

I also wanted to raise a second hurdle, which is certainly organizational, to be anchored in management. Everyone has heard of an SAP rollout at some point – that's usually decided relatively high up, by corporate headquarters or company leadership, that it should happen this way. These systems are all in place today; you have to work with them, you're allowed to work with them. So you simply have to ensure this openness of the systems, together, and tap into the existing data base. That often requires management decisions, which you can then certainly fine-tune during implementation, but you also have to bring management along. And we often still have hierarchical structures in manufacturing – that's okay, but it also thrives on information. So here too, some convincing now has to be done. The managers want to know what's happening on their shop floor, and the shop floor people want to do meaningful things and perhaps adjust one decision or another so that it fits well for them too.

And then the various manufacturers – every manufacturer. Bosch Rexroth now makes an automation platform, ctrlX, which we think is great. We've also been a development partner for many years, and Bosch Rexroth does this very well and openly and securely. But there are many manufacturers that still simply rely on this vendor lock-in. For decades that was a very successful business model, one where you perhaps put certain limits on openness and say: of course I'm now tying my customers to me, I want them to be satisfied, but I also want them, of course, to keep buying the products from me. Such systems may then not be super suitable to build on directly right now – you may have to take a few intermediate steps there. And those are, to name three, three hurdles you have to factor in.

Hans Michael, perhaps you have something to add there, from the user's perspective, on the Asset Administration Shell as well?

Hans Michael

Yes, from my perspective all the reasons Michael just mentioned are valid, I see it the same way, I'd sign off on that. For me, creating the Asset Administration Shell as such is already a huge hurdle too, one that I see with our customers – or with customers who visit the model factory and say: we think what you're showing here is cool, so how can I implement something like that at my place too? That's the first question. How do I actually create this Asset Administration Shell? For that I can of course go to XITASO now and, for example, commission it as a service, the way we did it.

For example, we also offer our customers a function block for the PLC that generates a kind of standard Asset Administration Shell. That's really cool if you want to retrofit brownfield machines, for instance: I then connect the signals to the gateway, this function block then runs on the gateway, and I create a standard Asset Administration Shell to begin with, and can already get started with it and really reap the benefits from it.

If that's not enough, then on top of that you can, for example, commission XITASO to build in more extensions, the way we did it for the battery line, for instance – because we didn't just want the data exchange, but, as Michael also said, the topic of skills: what capabilities does this machine module have, which are then represented in the skill. But I think creating the Asset Administration Shell is a huge hurdle you can name here, but one that isn't complicated at all at the end of the day. But people also imagine it to be a bit complex, similar to an MES or ERP rollout, which we're all somehow fighting against in the industry, which no one feels like doing. And you can start small, gradually – that's always my credo here. Then you do one line with it, or one or two machines, use the benefits, maybe the bottleneck machine, yes. So introducing the Asset Administration Shell is not to be equated with introducing an MES or an ERP system. Yes, and it shouldn't be, either.

You said “standard Asset Administration Shell,” and, to understand it a bit: what exactly is the standard, so to speak, and what are the extras then, the configuration? Does it also go in the direction – there are also different semantics that EPLAN or something like that uses – how does that fit in? Is that something that extends the standard, so to speak? And then, when you use it specifically for one machine, for example the bottleneck machine: what's the benefit then?

Hans Michael

If I were doing a data analysis in the factory, I would always start at the presumed bottleneck machine and equip it with an Asset Administration Shell, because that's where I see the shortest return on investment and perhaps a quick win that I can then also show to management. So I wouldn't equip all assets with it across the board, but rather start with the presumed bottleneck machines, so that you build trust there.

What would that look like? How could you, for example, improve OEE using this bottleneck machine, if you took maybe an example from the model factory or from the other plants?

Hans Michael

Yes, so it's difficult in the model factory, because we only ever produce there when people are around. That means we don't produce around the clock, but only ever when we do our shows. So it's always a bit difficult to improve OEE there – we make it transparent. And that's the first step: to say, where are my losses at the machine, actually, and to make them transparent. And that's what I mean by presumed bottlenecks: simply read out data in a standardized way via the Asset Administration Shell, in order to actually back up the assumption, this gut feeling, with reality and say: okay, it really is this machine. And there it's simple – the simplest thing is parts in, parts out, and how much across the shift and so on, and then you recognize it. And that's actually what I mean by: I wouldn't connect all ten machines right away, but maybe the two I'd suspect.

And which standards would I apply? For that I'd refer to Michael, who can perhaps say, from his perspective, from experience, from the projects, what the simplest Asset Administration Shell is that helps me, for example, with this data transparency. In a second step you can then tackle this topic of orchestrating the line, but the first step is certainly the one of data quality or data transparency.

With that perfect set-up, over to you: so what kinds are there?

Michael

Yes, here I'd like to broaden the scope a bit more. So, let's not shrink down into an Asset Administration Shell episode here – I wouldn't be the best expert for that at all. For that I'd recommend my colleague Alwin Hoffmann, for example. He works intensively on the Asset Administration Shell, standardization and submodels. I'd rather shift the focus back to OT/IT.

So: today we simply have so many great possibilities in IT and in software development that can now increasingly find their way onto the shop floor. Among other things through standardized protocols, but also simply through the way of working. And that's important for our manufacturing operations, to move forward, to keep developing now. And it's essential that at the beginning of a project you sit down together and look at: which use case do we have, what value do we want to achieve for our customers? Many IT systems I've experienced are really great, but the value isn't immediately apparent at first glance. And if the value isn't the guideline, then you always run the risk of simply producing losses too, as in OEE. So setup is a loss, scrap is a loss, waiting for material is a loss, waiting for people to operate the line is also a loss. And it's actually exactly the same in OT/IT: if we don't keep the customer in mind, then we run the risk of doing things that don't directly pay into value.

And in software development, over the last few years, people have moved a huge way in that direction – all the user stories are always geared toward value for the customer. And that's what we start from. So that means it doesn't begin with us showing up with five people and immediately producing code; instead, we first work out a concept together with the customers: what is it about, and what value do we want to create, and how do we get to that value fastest, iteratively and incrementally? And this thinking and this approach is a bit new for a shop floor. So, I don't want to say that value wasn't kept in view there, but trimming a manufacturing operation for maximum output doesn't always represent value for the customer.

I once had an example where we manufactured cylinder liners for cars, and the challenge there was that you received the call-off quantities for the next day the day before, and the production time that remained was just a few hours. There you have to strike the balance between optimizing output and being able to react quickly. Then, in the end, an Asset Administration Shell in combination with a BPMN tool can help set up the different sequence by drag-and-drop and, in principle, then retool the machine by drag-and-drop. But at the start comes value for the customer first. There I wanted to make the case again for us looking at this holistically – also detached from the technologies and protocols at first, but rather from the customer's perspective first, and then in the end deciding: which technologies do we use, how do we build the first iteration, and how do we then continue.

There you're pushing at very open doors with me. I'd like to share an insight I had from my own past and hear what you make of it. I was also a sales director for MindSphere back then, an industrial IoT data platform from Siemens. And that's when I first noticed how important an aligned vision is, so to speak – a target vision. So, before that I was also once a business development and strategy lead for a segment, and I always somewhat smiled at this topic of vision, mission. Why? Because it simply had no impact, no influence on day-to-day business. Everyone had one, no one really took it seriously or used it.

But then I realized in these digitalization projects – and this also applies on the shop floor, and I'm noticing it again right now with AI – it's exactly the same issue: if you don't have a shared understanding, from management and from the people, of where things should go, then you don't take the first complicated steps either, and then you never get there. That's a bit this topic of target visions, that is, visions translated into something very concrete: in two to three years it should look like such and such. In my everyday work now, with what we do, this has become very important because AI can generate these target visions so wonderfully. How do you look at that, Hans Michael, maybe – target visions like that? I mean, with the model factory you've created something in that direction, where you can orient yourself a bit on what such target visions look like.

Hans Michael

Target visions are one thing for me. You then show the highly flexible manufacturing, and you want to enable that highly flexible manufacturing. What I've rather learned – and what we're now recording here in a podcast too – is the topic: which use cases specifically exist for certain technologies, and how do I get there? So, do I use the Asset Administration Shell, that is, the use case Asset Administration Shell, for data exchange, because I save this and that, because I want to achieve this and that? Or do I use the Asset Administration Shell to orchestrate my plant as line control 4.0 or whatever. So naming it concretely – and you do that par excellence with the IoT Use Case Podcast: what is the use case? That of course fits with the target vision we set for ourselves. But what specifically is the value of this technology, this solution? What's in it for me, and how quickly do I get there?

In my view that's the most important thing, and it's what we show in the model factory in Ulm. And there are somehow a thousand use cases, and depending on the customer we then pull out the relevant one. And especially now, in the end-customer area, we show the connectivity. But that, in my view, is what's decisive, and you do it very well in the podcast: to then address the various use cases in each case and make the technology approachable, but also show what it brings with it. And that, in my view, alongside the target vision, is what's decisive.

And here I really want to make the case for AI, because very few people do this, or very few have understood it: that you can use generative AI to create such target visions and then also to map out the path. So from my perspective it's totally relevant to consider: what is the step I have to take today in order to arrive at the target vision in a managed way? And that, as I said, is a really great thing with AI.

Hans Michael

Many people think visually, and any visual support – if you can't draw well, then it's of course great visual support for sketching out the vision. There I agree with you. And to really sit down and work out such a vision, but then not for the next ten years, but rather perhaps to choose two to three years as the horizon for what I want to achieve there.

Michael

Or for a project, too. In the end AI creates a great many possibilities, but it's the people we have to bring along. And all day long we deal with a great many superbly trained people who can make their own decisions and also want to. And when you define a target vision together, it also helps to steer these many small decisions you have to make day in, day out in the right direction. No requirements specification can do that, no management claim can do that; instead you have to agree on it together, and do so again and again. That's what we've learned and are putting into practice. In the end, it's the people.

Exactly. And sometimes in combination with technology. And the time horizon is of course also something you have to decide, that's clear – you can think about it short-term or longer-term and then flexibly adapt again and again. In the context of the time horizon, Michael: how does the whole thing develop further, as we wrap up our podcast today? What do you think are the next steps? Is it the case that the Asset Administration Shell will prevail everywhere, or are there other topics? Is it always this mix? Where does it go from here?

Michael

I think it's the mix. The Asset Administration Shell has great potential – as an early adopter we believe in the potential of the Asset Administration Shell in combination with the submodels. We'll certainly see quite a few implemented and successful use cases there yet. There are other technologies too that now have to be transformed onto the shop floor, for application on the shop floor. And that's a combination of a mindset, of a way of thinking, and the application of the tools.

I believe we'll continue to see a trend toward distributed knowledge. Quite naturally, the PLC programmers cited earlier will simply be replaced by teams that work on a project with different technologies and also as different people. Documentation will continue to play a role – you have to be able to trace what one person or another was thinking. You have to scale the plants, you have to scale the sites that now collaborate in manufacturing worldwide. That also poses challenges for us. The value streams are distributed, and they'll continue to stay that way.

Even if we've seen a few setbacks here with a blocked Suez Canal and a Strait of Hormuz – the supply chains will remain global. It's an illusion, I think, to say that we in Europe are now self-sufficient. So, I don't believe that. There are these megatrends of our time, and I believe they'll simply manifest themselves, and we have to respond to them technologically and with our organizations.

Hans Michael, from your perspective, the outlook: where do things go from here for you? What are the priorities you're setting, from your point of view?

Hans Michael

Very good question. At the moment the technology is developing very quickly. We've already talked about AI – the use of AI in OT as well is interesting. So, what can I do along the complete lifecycle of my machine, for example? How can I use AI there? Can AI create the Asset Administration Shell itself for me, for example? Can I build the Asset Administration Shell with an AI agent? How do I use AI in engineering? How do I use AI models during the operation of my machine too, for example to analyze time series?

Those are the main drivers for us right now, because we notice that this technology is advancing extremely fast – not only to generate target visions for a vision and a mission, but perhaps even, in the future, to engineer, configure and operate entire machines. And what effect does that have on our production? Those are topics we'd like to bring closer to our customers in the model factory, for example, and also make tangible.

Great, thank you very much. It remains extremely exciting. So, dear listeners: feel free to subscribe to our podcast. We'll stay on top of the hottest use cases in IoT. And with that I'd like to thank you very warmly for your attention. And Hans Michael and Michael, thank you for being here. It was a really exciting discussion.

Michael

Thank you.