How Ignition is boosting SCADA in the Biotech Industry

Speakers

Chris Bollom

Senior R&D Project Engineer

Cytiva

Andrzej Kolon

Principal Automation Engineer

Cytiva

With a demand for flexibility and a strong focus on quality, SCADA systems play a crucial role in ensuring smooth operation of processes within the highly regulated Biotech industry. As a leader in the field, Cytiva is accustomed to developing solutions designed for the lab environment.  Attend this session to get a peek into the technical aspects where Ignition has been leveraged to help meet customer demands, including dynamic OPC connections and integrated eLearning.

Transcript:

00:01
Cindy Smith: Hello, welcome, good afternoon. I'm Cindy Smith, I'm the Candidate Sourcing Manager here at Inductive Automation. Welcome to today's session, How Ignition is Boosting SCADA in the Biotech Industry. To start things off, I'd like to introduce our speakers. Chris Bollom, Senior R&D Project Engineer with Cytiva. Chris is a Project Engineer with Cytiva's Automation, Digital and Learning Group, and has experience running various technology projects within the biotech sector for the last six years. As Project Manager for the mPath Link SCADA system, Chris oversees the use of Ignition Perspective to deliver flexible solutions for end users. Chris is responsible for identifying post-launch customer requirements, planning feature additions, and overseeing releases to the market to leverage the benefits of Ignition. Andrzej Kolon, Principal Automation Engineer with Cytiva, is a highly skilled Automation Engineer with 16 years of experience specializing in PLCs, HMIs, and SCADAs.

01:01
Cindy Smith: With a tenure of seven years at Cytiva, previously Paul, he held this role, excuse me, he held the position of Principal Automation Engineer in the Automation, Digital, and Learning Group. In this role, Andrzej led automation efforts for various biotech projects, and he began his journey with Ignition SCADA in 2019 as the Automation Lead for the mPath Link development. Presently, Andrzej is actively engaged in new technology research, and providing mentorship to fellow automation engineers within Cytiva. Please help me welcome Chris and Andrzej.

01:38
Chris Bollom: All right, this is cool. Cool. Good stuff. So, thanks guys. So, what we'll go through today is a little bit of our perspective working for a company called Cytiva in the biotech industry of how Ignition is supporting us in terms of delivering our customer needs. We'll talk a little bit about some of the key demands from the customers, and then Andrzej will go through a bit of a deep dive into how we've leveraged Ignition on some specific topics. Already had an introduction from us, so. We'll have a little overview quickly on who Cytiva as a company are. So, effectively, we're a global provider of technologies and services aimed at accelerating drug development. So, there's a range of products, which I'll touch on in a second, but essentially we're producing consumables and hardware to support our customers made drugs. We have sites all across the world, and myself and Andrzej are based in the UK down in Portsmouth on the South Coast. We do have quite a big presence in the US as well, particularly on the East Coast here. So, in terms of the products that Cytiva offer, it's the full end-to-end solution, which covers small batches up to 2000 liter volumes, right from upstream manufacturing and in terms of bioreactors through to the downstream purification and filtration devices to produce an end product.

03:06
Chris Bollom: Predominantly, Cytiva focuses on single-use technology, so that's really to deliver the flexibility that our customers ask for. And you can see on the board there where we'll be focusing on mPath Link, which is a SCADA platform aimed at the process development phase of manufacturing, which is really in the early stages before we get to large-scale manufacturing where customers really demand flexibility. So, we'll start, we'll delve into that in a little bit more detail in a second, but first we can focus on some of the needs that our customers are asking for in that process development sector. So, customers, first of all, are really looking for scalability at this stage because process development is fairly early on, customers don't know the full extent of the equipment that they'll require, so they wanna start small and build equipment in as they go. Added to that, flexible access is something that customers want in a clean room environment, they don't wanna be gowning up every time they need to check what their process is doing, they'll wanna be able to remotely access their equipment and monitor their processes. Added to that, customers really ask for out-of-the-box use.

04:18
Chris Bollom: They're often smaller customers in this process development sector, they won't have large automation teams, they'll often be scientists that wanna just get the software and start using it to start their processes as quickly as they possibly can. And they're also demanding flexibility and access to data, mainly because in that process development space it's quite early on, customers don't know exactly how they're gonna transfer into manufacturing at that stage and they want to be able to change things and experiment with how they can produce the best yields possible. So that led us as Cytiva to launching the mPath Link, SCADA platform, which is built on Ignition. It was launched back in 2021, utilizing Perspective, but there was a version working on vision a few years before that. The main purpose of it really is to provide a standard UI across Cytiva equipment. As I mentioned, this is really aimed at the process development stage of manufacturing, so quite early on in the development process, but the intention is to try and expand that software across Cytiva's range of equipment.

05:30
Chris Bollom: And since 2021, we've got quite a robust process in terms of capturing needs from the field, and we've had a number of updates and iterations just to really hit those demands of the customers. And that wouldn't really have been possible without using Ignition, so linking that back to those key use cases from our customers. The first point around scalability that our customers are asking for, obviously the license model for Ignition is critical to helping with that. When customers want to scale up and buy more equipment, the traditional tag-based licensing models would be a problem to them. We obviously don't have that with Ignition. And Andrzej will delve into the technical side of this in a second. But one of the key things that we've done with this is the ability to add OPC connections in runtime, which makes it really easy for customers to purchase more equipment and add that into their processes.

06:26
Chris Bollom: Utilizing the perspective modules obviously been critical for us as well, particularly with some of these customers being startups, they're quite receptive to modern technology, want the ability to utilize tablets and mobiles. So we launched mPath Link with a mobile app so customers can access that, and that obviously takes away that need for customers to gown up and enter a clean room every time they want to do something. One of the other topics that Andrzej will delve into a little bit more is e-Learning as well, that supports that out of the box approach. With, as I said, people being generally scientists using this software, they wanna get going with it straight away. So we've utilized Ignition to add in some videos and e-Learning modules within the software. And then finally, as I mentioned, people will want to play around in this space, try and improve yield. And Ignition's really helped with that with a range of different charting tools. So we've added in features over time, things like a batch compare module, which allows customers to try and essentially get a golden batch and identify how they can make process improvements to improve their yield. So I think I'll hand over to Andrzej let's go through a little bit more detail on the technical side of this.

07:43
Andrzej Kolon: Thank you, Chris. Hello everybody. So we now concentrate on how the general architecture looks like in mPath Link. We have to go for a bit of the hardware, so then we've got like a perspective on how actually the software is built as well. So if you look at this slide at the bottom of it, we have a unit level, which is a dedicated hardware. So it can be anything. It can be a flask, it can be a dedicated bioreactor like you see here. It's a rocking bioreactor. It's this one here, and this is just a flask with few additional sensors and things like that. So basically this is the hardware that does something which is really particular peculiar for the particular process. On the higher level, we've got the controller level, and basically this is what we call controller or tower.

08:32
Andrzej Kolon: Basically what it is is a set of sensors and activators like gases or pumps, and they are controlled. There's a PLC inside, it's a back of PLC. It's OPC UA server. That's quite crucial here. And what it actually consists of is all the I/O and sensors that are in general, general purpose ones, and they pretty much can handle commonalities between all the processes. There's one-to-one relationship between a tower and the bioreactor. And this explore via OPC UA to our mPath Link, SCADA server. And that is currently on a standard deployments, that's Windows stand Ignition Gateway, 8.1.17, and Microsoft SQL 2019. All of that runs on a PC, dedicated PC that we sell as well and as a standard offering. And it provides as a visualization, we provide perspective workstation for mobile and for desktop applications. And it's basically supports everything that perspective workstation supports.

09:57
Andrzej Kolon: When it comes to Ignition Gateway itself, it consists of three projects. The global project consists of everything that is common for all the other projects. And then we've got mPath Link project and that's main desktop application. And then we've got a mobile version of the application. We decided to split those together because we had quite a distinguishable different user cases for each inside. It's much easier to manage those two applications as well, two different applications as a well. Well, like, as a separate application really. Now I'm gonna present a little bit of the video of how the actual software looks like we're using perspective, obviously with all, well, hopefully a lot of bells and whistles that comes with it. It's a modern UI. We design our UI with our UX team.

10:57
Andrzej Kolon: We've got internal UX teams. All the workflows are basically designed by them and we just follow what they want us to do. Perspective is really great with it. The UX is always focusing on new approaches, new workflows, all these standard web application kind of front end. And, yeah, with Perspective Module, it's really easy to meet those requirements. So I'm gonna play this video and we're gonna talk a little bit about it. So that's how the application looks like. You have access to individual units and the main dashboard. We don't have a limit to have amount of units we support in one application. It's a dashboard that is specific for the unit with few KPIs, process screen. We're gonna talk about process screen a bit more.

11:50
Andrzej Kolon: Alarms, trends, that's events recipe system, everything you have access to. You have also access with your cog icon to additional settings for each bioreactor and for the main system level as well. You can set up a lot of stuff here, specific to particular units. You can set up alarms. You can enable, disable alarms so everything is flexible. We provide maximum flexibility so the customers can set up their equipment exactly how they want. They can disable alarms, enable any alarm they want in the system. E-Learning as well. I'm gonna talk more specifically about e-Learning. You also have process screens I've mentioned with access to individual face space for each I/O that is configured for the system. So that's how it looks like everything is parametrized. And that's really, really quick with through how the application looks like. It's really minimalistic. And another video I want to focus on, it's actually running again.

13:17
Andrzej Kolon: Is what Chris already mentioned. So we're gonna deep dive a little bit into how we create units in runtime and how we add OPC UA connections in runtime. So that video will present how our customers that don't really have a big automation knowledge, if at all actually handle application fully from the front end. Bear in mind, these are mostly scientists that we are dealing with. So they know... They are really clever people, but they know pretty much everything they can about the process, not necessarily a lot of software/automation knowledge. So, yeah. This is how you see the software when it has nothing configure on it. You just log into the system. You log in and you go to settings and use add your controller. You select from available types. We have two types of the controllers. One is with pumps. The other one with this, without pumps, you just name your tower and you put IP address in. So that's the only bit that they really need to know. That can change. That can be different subnet, it can be whatever the IT department told them to put in or anything else. And then they need to put host name. If they don't know what it means, they just click on a help here and the software will tell them where to look to see what the actually the magic number is. Once they figure that one out.

15:06
Andrzej Kolon: They just click add and OPC UA connection is created. I clicked the, No, on the creating the units because it was the second thing explicitly I wanted to show. So once they add the connection, they can start setting up the unit and here they can select from all the available types of the units. They put the unit name and you see a lot of other main cases that... Main setup parameters they can have. They put all of those how they want, and they are at the page where they can set up the I/O. So pretty much what's happening here, they can add remove I/O. We just have a good guess of the default I/O settings. And based on that, they can modify everything. Here it's additionally we support user configurable I/O. It can be anything. It can be input, output, analog, digital, whatever they need they can do once they create it and agree on everything, they safe, we're happy, boom, job done. They have a unit and pretty much from here they can start running the processes straight away. They have a default batch they can run. So pretty much it takes two minutes to set up the whole software to run. And there's unlimited support to your connections, and there's unlimited support to the amount of units you can create.

16:22
Andrzej Kolon: So, now we'll focus on how it actually works from the back of things and we focus at the beginning at how we create this OPC UA connection. So what happens is at the top you can see how the application presents the controllers. Here's a example of three controllers, three controllers that are set up with different IP address and stuff like that. So pretty much what it does, it just represents exactly what is happening on the gateway side. So all the connections you can see at the bottom, they're standard gateway connections, and we just show them on the application. You can ask why we are doing that at all. So the reason why we're doing it is it's much easier for the customer to go through the process of setting it up, like I just shown a movie. But also we don't want to give customer necessarily access to Gateway. So he can ask, like he can modify a lot of things and also damage a lot of things. And we don't necessarily want to allow that to happen.

17:24
Andrzej Kolon: So how it works is there's a magic link at the top and this link gives you access to internal ignition gateway database, and pretty much everything that can be configured using your ignition gateway web server, you can see here. And you can interrogate and you can basically check what's happening and how it's happening. So this is the URL for that. You've got the list and you can query the database and you get the results at the bottom. So we, as I said, we're gonna focus on OPC servers. So this is the example of OPC servers. We just select OPC servers. We get all the fields here, and as a result, we get free servers like you've seen on the previous spring screens. So we've got free servers. All the names are exactly like that.

18:19
Andrzej Kolon: You've got type description and read only. And what is really important is the OPC server IDs. So that's gonna be really important because once you get your OPC servers and you work out how this is actually presented, and what are the fields you get to the OPC UA connections. We are working only with OPC UA. Our towers are back of towers, as I said, and their OPC UA server. So we know that we support only those back of towers. So we know that we are looking for OPC UA connection settings. So you can see at the bottom, and you can see here a little bit more at the top. These are all the fields that you can set up when you're going through your Wizarding Gateway. You can actually see all of those settings here as just fields. And what is really important here, you can see the server settings ID. And this ID links with servers. So each connection setting record has an equivalent and is assigned to actually the server itself. So that's pretty much how the link between server and its settings is made in the database. So we work with SDK, and I just noted here a few things that are really critical for the thing to actually work. And we work with SDK. It's 8.1.17. It doesn't, this does not have change too often.

19:47
Andrzej Kolon: So it worked. We went through 8.1.7, then 9, then 17 and it just never never changes. We're working with a context of Ignition Gateway. We also work with OPC EE server settings record and we work with OPC UA server type and also what is important we are interrogating, and there's the bit here, we are interrogating extension points. Extension points, the way I understand them, is pretty much capabilities of your gateway. So you're pretty much checking what the gateway is capable of and returns that it's actually capable to work with OPC UA. So how does it actually work when you want to program something? We use something called persistent interface and we create new persistent interface. So first of all we create a new server, so what we're doing is we create new OPC server setting record. We pass from the code name, server type and we just save this persistent interface. So that's the first bit you need to do. And then once you get that server saved you can start playing with actual settings of your connection. So what we're using here is we're creating a new OPC UA connection setting record that's pretty much one row here.

21:35
Andrzej Kolon: And we use, again, persistent interface and we associate that with one of the server's IDs that we already saved and pretty much we have access in that way to any of the settings from your Gateway. So that's pretty much how you can save anything, you can pass this all as the parameters, you can do whatever you want. Here it's not the problem, it's far more than I'm listing here. At the end of the day what is really important is to get persistent interface and save it. And as the last thing you need to notify the Gateway that actually something has been added. So you can say it has been added, there's option to have it modified and removed as well so quite a lot of interesting things you can do with it. It's all available in the documentation. So that's how we create OPC UA connection in runtime and there's a lot of interesting stuff there and some magic URLs and some magic fields. Here I'm gonna show you now how we create a units in runtime.

22:43
Andrzej Kolon: It's quite an interesting approach as well in my opinion and also this functionality doesn't involve any SDK or any additional code at all. So let's say not off-the-shelf supported by Ignition. That's kind of more mainstream usage of Ignition. So first of all I wanted to show this is... And this is common for all the empathic applications. What we're trying to do is to move as much configuration of the software to database. So if we can store some data inside the database, default values, user configurations, other sort of configurations, we store them in the database and our UI is responsive based on query results from the database. So we try to hard code as little as possible inside the perspective. So we've got our OPC UA connections, our controller towers and we basically store that information and we just query if we need it and we store those query results in session parameters and we just throw them at the screens where we need to. So we can see those towers are the bottom three towers I believe.

24:03
Andrzej Kolon: So we do the same with our units and that's what we're gonna concentrate right now on. We've got three units and we also have exactly the same idea. Whatever we have units, basic information is stored in the table and if we need to present it in the perspective page, we just query stuff, return the values and we sort them out on the view. Our units also consist of folders. So every unit is a folder. Every folder has additional folders inside that are pretty much specific to the I/O that we are using and every I/O is a UDT. Well, it consists of groups of UDTs basically. We have our UDT definitions. This is static and we use parameters to those UDTs.

25:04
Andrzej Kolon: So pretty much we, I will show you how we instantiate those UDTs with parameters that are here. That's how we create the tags for our OPC UA connection. So basically, what you've seen in the video is as soon as customer saves the bioreactor, we go through a series of events that are happening and we trigger code and you notice there's certain default parameters customer can add, remove from different I/O and we just constantly create a dictionary where we store all those changes and all those configuration settings and at the end we create a data set out of them and we pretty much, the first thing we do, we insert to a table that you've seen already a new bioreactor is created with unique ID and then we start to go through that dictionary of the I/Os and we create I/Os. So here we focus on 1270 ID and you can see 1270 bioreactor has all those I/Os with all some basic configuration already predefined based on some parameters inside the database and the ones that were put on them configured on the UI side.

26:23
Andrzej Kolon: So, here what is important, we're just gonna quickly go through that. It's ID78, which is our nano temperature. We're gonna follow through that example here. So we've got another table in which we store additional information of what's happening with our I/O, what are some other default IDs, and what is really important is what are the UDT types. So here, what is really important is what actually UDT we're gonna use and what is the sub-UDT if any, that we're gonna use. In this case, it's 2 and 19 that's quite important. So the next thing we're doing is we actually try to understand what the 2 and 19 means. And 2 is our input object, and it's a path to our UDT. So if you've seen our previous screen, there's a UDT which is actually called input object, and there's also a PT100, which is 19.

27:22
Andrzej Kolon: So basically, we understand that we have now... We will be working with input object, and there's actually a PT100. And we start to create folders for our bioreactor, and pretty much we create what we see here is an object, and the object details, and we're just instantiating with system.tag.addtag. We create sub-paths, sub-objects if necessary, and we pass parameters and attributes for I/O path, which is our input object and PT100. So that becomes our input object, and this is our PT100 object. So the next thing we do, and we focus here on an Int, which is analog input row. We're working with another piece of default I/O setting, which just helps us instantiate those UDTs with a certain magic parameters that we are expecting from our PLC. So PLC has an object structure.

28:37
Andrzej Kolon: It's an array of, actually here, control object inputs, and there's 31 of them, and they are always there. They are static, and we either use them or not. That depends on the scanner, actually, and the way it's actually implemented and configured by the customer, but pretty much we're talking about 31. And this is our prefix based on that we know, and we're passing parameters of temperature, index, and control object. Our server is one of the servers we already created, and pretty much we resolve to that, which gives us communication quality. Actually, good to see it. It's nice. Anyway, that's how it works. The last bit of presentation I want to show is how we implemented a pretty simple, but really satisfying, in my opinion, bit which is e-learning. It's quite flexible, again. Again, it's the same concept. As much information as possible, we store in the database, where we can change the content without actually modifying the code itself. It's quite important.

29:51
Andrzej Kolon: It's quite important for us, because, for instance, in this case, we didn't know what the content of e-Learning will be at the moment we were implementing the solutions, so we basically didn't know what the database will look like, so we had to be really flexible here. So, there are two options here. One is we store user manuals, and that's just the PDFs, and the customer can add their own PDFs if they want to have any SOPs they want to add. But pretty much this is the standard setup with our user manuals and the option to browse and add new ones if they want to. And there's an option of e-learning, and this is quite interesting. It's contextualized based on unit type, and it actually also gives you an option of having a QR code or an external link that you can click on.

30:49
Andrzej Kolon: So, how pretty much it works, like we'll see in a second, but what we have is our e-learning portal. Cytiva has an e-learning portal, and customer can log in and access all the necessary manuals and all the necessary videos that explain how to do certain things by just watching them on a second monitor, if they have one, or just the scan, and well, if they have a monitor and they have actually internet access, but also they can just have a mobile or a tablet, they can scan QR code and pretty much go for video and follow the video on the real device and actually start making things happen. So, again, the database, the database is a set of names, paths, type, which is either document or PDF, sorry, video or PDF and bioreactor type, and that's pretty much it.

31:48
Andrzej Kolon: And we query the database based on the context on the webpage that we are accessing, and eventually we're getting to that one component, which is just one single tile, and we repeat it as many times as we need to in perspective, and we link, we bind labels here to a content of the query that we have, and also we generate on the fly and runtime a QR code just using a standard ignition barcode. We just bind it, and it just works. It's quite easy, quite flexible, and you can pretty much expand the system to however many what pages, links, URLs you want, and then pretty much, you don't have to modify any code. You just chuck stuff into the database and it just works. It's quite cool, I think, and quite simple. Chris, over to you again.

32:47
Chris Bollom: Cool, yeah. And this is just a final one of sort of, I guess, next steps that we're looking towards with this. So, obviously, we've been hearing about it most of the day, but fully intend to utilize the better version of 8.3 and see what we can potentially do moving forwards with mPath Link. And we're definitely finding that customers are becoming more receptive to cloud technologies, so connecting up to various modeling software packages and things like that. So potentially moving towards investigating Ignition Cloud and Edge is something that we might well do there as well. And then two pieces more internal to Cytiva that we're potentially looking at doing with this of expanding mPath Link across our product range. And really to do that, moving more into the manufacturing scale, customers are looking more for robust batch management solutions. So potentially integrating some sort of batch engine to mPath Link is also something that we're looking to do there. So I think with that, that's it from us then. So, yeah. Welcome any questions.

33:50
Cindy Smith: Any questions?

34:00
Audience Member 1: For the e-learning, when you guys implemented that, does it give them credentials when they watch the videos, like credit? Like checking the credits of like the operators who logged in and they watched it and they took a test and they kind of get credit for that? I've had customers ask me about implementing something like that within Ignition.

34:20
Andrzej Kolon: So pretty much how it works is just the access to external web page that Cytiva owns with all the content. And that's additional web portal they have. They would have to log in with their credentials that they purchased.

34:35
Speaker 4: Oh, so it's like external manage. Okay.

34:37
Andrzej Kolon: It's external, correct. Yeah, we don't store the data locally on the server because it changes too frequently and it's updated independently of how we update our software.

35:00
Audience Member 2: Hello. I saw on one of the screenshots that you had some sort of flag or counter that determined the order of the tiles, the units that you're creating, the controllers. Was that what was happening? Was there like a specific thing that was ordering, like when a user creates a new controller, does that like control how that grid looks or how was that laid out?

35:25
Andrzej Kolon: Yes. So basically it's based on creation time. So that's how it's being shuffled around on the page. Yeah. There's no customization on this particular case.

35:34
Audience Member 2: It was still a pretty cool solution. I liked it.

35:36
Andrzej Kolon: Thank you.

35:45
Audience Member 3: Hey, thanks guys. So it might be a bit of a pivot, but I guess the question is, 'cause you mentioned early on a lot of the customers that you sell into tend to be smaller companies. It's not always big firms. So what's the technical maturity of a lot of the customers that you're selling into? And then how do you find, like do they have a lot of IoT solutions, maybe like MES Lite or something like that? And then how's the integration of this solution into that existing technology stack? It's a bit of a broad question, but do you tend to find it's a complex process or it's a relatively simple or what's it look like?

36:24
Chris Bollom: I guess I can do the first bit and you can talk about the integrations 'cause you worked on that a little bit more. But there's a variety because we work with some small customers. Their technical maturity won't be very high at all 'cause they're essentially looking to get acquired in this industry. So we'll be quite new into this. We'll pretty much use the solution that gives them the best opportunity of starting off. But we also have large customers in this space. And probably the thing there, I think, is everyone's trying to move to a more modern architecture. But particularly in the biotech industry, people are quite cautious to change and adopt new technology. So particularly initially working with Ignition in this space, it was a challenge both internally and externally to push that on people in a typically conservative industry. But I think we're starting to see people more willing to adapt, as it was mentioned here in sort of more modern technologies. And that's something we're looking to do. But I guess you can mention some of the integrations that potentially worked on.

37:25
Andrzej Kolon: Yes. So pretty much in PD scale, where we operate at the moment, customers don't really require off-the-shelf solutions. Well, they do, but we don't provide it at this stage. We have a lot of proof of concept that we are working on how to make things more plug-and-play. And obviously with the solution that we have, OPC UA connections for servers actually are pretty, pretty easy to do. But customers, they start to ask for that more and more, but it's still considered a PD scale. It would be nice to have everything orchestrated or pulled even into one database. But they're more concerned about actually making the thing work in general. So what I do in order not to kill all my cell cultures, what to do not to produce anything, not even a big amount, just make it work, actually. So that's where they concentrate on, obviously.

38:30
Andrzej Kolon: So we're getting it more and more, and we're getting there. We do a lot of proof of concept, like Chris mentioned here, batch engine, but overall the integration bit is more for us. Like if a customer doesn't want to use our standard offering in terms of PC that we're running on, we would be installing or he would be installing the software on their servers or a different kind of thing. So bigger deployments, we basically prefer to do it on the servers or maybe even bigger desktops. It's like really that kind of scale. So you can have like five, six bioreactors running and then basically you're still pretty much using a benchtop. So integration is more like where you install that thing. We did a few OSI PI integrations and things like that to some higher level logic, but that's with OPC UA so it's really simple with Ignition.

39:35
Cindy Smith: Thank you, Chris and Andrzej for your presentation today, and thank you all for joining us. Enjoy the rest of ICC.