Name: Accelerating Complex Medical Device Design with Systems Engineering
Uploaded: 2025-02-27T19:30:05.354Z
Duration: 46 min 24 s
Description: Accelerating Complex Medical Device Design with Systems Engineering

Transcript for "Accelerating Complex Medical Device Design with Systems Engineering": Hello, everyone. Thanks for joining us today. We'll get started in just another minute. We're right about on time. Give maybe thirty more seconds, and we'll get kicked off. Alright. Hi again, everyone. Thanks for joining us today. I'm James Carr. I'm a senior application engineer here at GoEngineer, and I'm being joined today by Benam Afsharpoia, who is a senior industry consultant with Dassault Systems. Today's presentation will focus on, model based systems engineering approach for medical device development on the three d experience platform. So we'd love to have your participation and any feedback you have, during the presentation. Definitely like to keep it a little more interactive, so feel free to use the, the chat or the questions function. You can do that any time during the presentation, and we should definitely have plenty of time at the end to, to review and discuss, anything you have. So with that, I'll just pass it over to Benham to begin the presentation. Thanks. Thank you, James. Thank you, everyone, for listening to this, presentation today, and hello, everyone. Welcome to this presentation. So this presentation is organized by GoEngineer. They help us to present this topic to everyone. This is not about what type of tool you are using. We are talking about a methodology to accelerate design of complex medical devices. This method methodology is called systems engineering approach. Now about me, I have been with Dassault Systemes for almost, early eight years. Before that, I have served in different industries like, medical devices, aerospace, oil and gas, and, also automotive. So I have I have backgrounds in different industries, but always, I had similar type of challenges that I'm going to talk about it. So for agenda today, I start with an introduction. I said why we are interested in this topic. Then, I will give a little bit, introduction about systems engineering approach. Some of you may know already that, but, for some colleagues that they haven't seen system engineering, like, in details, I explain a little bit more. Then I will show this concept or this methodology in some demos. So kind of you would use and see what type of tools they can provide you this type of, application. And at the end, we have question and answer. So first, I start with introduction. So why I'm interested in this topic, why I brought this topic, to everyone is about the challenges that we are facing today in industry. The products that we are designing these days are more complex. And when we are developing a new product, we need a new process to develop new technologies. So they get more complex. They have more type of disciplines that they are involved in the design, and that would cause delay to or kind of longer time to get to market. And, also would have impact on the quality when we want to get this faster to the market, or kind of the cost. We want to keep the cost limited because we are competing with the other companies that they have lower cost, and we want to be sure that we are efficient enough. In this process also, when we are developing a complex system, we have, multidiscipline, disciplines. We have different disciplines working with us, and decision making for the higher managers would be very difficult because they don't they don't have expertise in each discipline. So with the industry strict quality and environmental, regulations, this becomes more difficult because we want to be sure that all the disciplines, they are aware of all of these industry regulations. So transferring all of these details to everyone would be quite difficult. Now when it comes to industry or working in a specific type of industry, you see that during the development of a design or a product, a large number of people, almost 60% of them in the company or in the team that are developing that product, they don't see the prototype. They don't have time with the prototype to work with that. They are just designing something. They are doing calculation, but they don't feel how this product is going to work. And, even 10% of the engineers, they get to the evaluation experience. So when you did have the prototype now, you leave it to ex evaluation team or testing team, and the team that they have developed this tool, now they're not very much involved in that, process. So we need a way to overcome this type of, like, challenges we have. Now I start with model based system engineering as a method that it can help you with most of these challenges. What is this method about? I try to simplify it. First, as a system engineer, I look at the requirements. I see what industry, customer, market, different type of, like, requirements are for my product. Before I design it, I see, okay. What I am going to design, what is the purpose of the design, who is going to have benefit from that, how, when, where. All of these questions that they start with w, I need to answer them. Now I bring some requirements as a result or answers to these questions, and I sort them in different, like, spreadsheets or sources. Now I need to find solutions for all of these problems or requirements. So I need to develop a prototype or simulation models, which is more economic, to see how these solutions are working. Now at the end of the day, I need to find a way to evaluate and validate all of these solutions that I have in mind as a simulation model and a prototype against the initial requirements I have. So this process should be managed by someone or or anyone in this company who has knowledge about model based systems engineering. They can do this process more efficiently, and they have would place it place it in a, framework so they can understand it and do it more, intelligently. Now what would be the framework as a typical, like, work or, or, process for model based system engineering? One of them can be SysML language or methodology is called MBSE that can help you to to the system engineering. In this type of process, first, we look at the requirements. We import requirements from different sources. Now we need to define these requirements. We need to interpret these requirements, for different disciplines and different type of engineers, that the engineering pro teams to kind of analyze them. So we, as a system engineer, we come and develop some, diagrams, like, a a structure diagram to define what components I have in this design or solution. And I made comment define some simulation model, like a very high level. It's called behavior model. So I would say how the product is going to behave in different situations or with with different, use cases. And then I will define some parameters or parametric, like, logical and functional, like, approach to see what would be the, weight, size, shape, different, KPIs for this product. And then I will transfer all of these, like, data to different disciplines. Now when I come with a very good structure of definition of the system and all of these parameters, I would have efficient and accurate way to communicate with my colleagues who are in different disciplines. Now they can read these, inputs, and they can provide their outputs based on their require the, KPIs and the, parameters that I am asking them to provide me. So this may make, our communication quite efficient. The other hand, I need to talk to simulation engineers, and I do the same thing. I can provide the right, inputs and get the right output from them in this framework. Now in this framework, not only we are focused on the design of the product, we are thinking about the product as a part of a system of systems. So we not only if we develop a medical device, we are not only thinking about that medical device. We have other systems above that medical device, like health health care system or insurance system or, patient care system or medical doctors, operation system. So all of these systems, would interact with the system that we are developing as a medical device, and we want to be sure that this system, as a part of system of systems, is also meeting all the requirements for from for higher systems. So this this system engineering approach helps us to be sure that we are interacting with other systems correctly. Now we provide some logical and functional architecture for our design, and now we come, and in different levels, we discuss these definitions with our this disciplines or teams that are working on the design, like enterprise discipline, or manufacturing disciplines or product engineering disciplines. All of these disciplines in different levels, in different stage or steps of the process of design and manufacturing and production and also, distributing of the product, we are discussing this with different disciplines that we have in our team, like mechanical, optical, materials, electrical, electronics, and software. All of these teams, they are on the same page with us. And now at the end, when we want to do evaluation, we want to be sure that we are, interacting with different type of hardware, software, and model in the loop to for evaluation of our product. And at the end, we when we are developing some software or hardware, we keep all the data and information about our product in different repositories so they're not missed or raised. They're not placed in different locations. We have them in one location so we can see all the results, all the designs, and all the kind of information about our product in one location to make the right decision. Now the software is a very difficult part because we have different software developers. We want to be sure that whenever we are developing a software for different functionalities of the hardware, we have everything in different repositories. But in a central place, we can manage all the revision management and version management and change management in one location, not only for the software, for other components of the system. So we can be sure that we have a governance over the whole process. So it's not only an engineering process, it's also a business process. We want to be sure that we have change management, version management, project management, over all of these, like, process to be sure that we are doing this correctly and efficiently. So the first, before we go to their, demos, I explained what you would see in their demos. First, except for the, team would be understanding the requirements. Requirements may come from different sources, but we want to be sure that all of these requirements are centralized, kept in one location, and we can manage them in one location as a single source of truth. So if we are developing some requirements, if we are managing them and we are changing them, we want to be sure that all the team, stakeholders and all the teammates, they are aware of that. And, we can also be sure that all the team members, they have access to the right requirements relevant to them. They may not need to know all the requirements, but we want to be sure that the requirements that are related to them are accessible to them, and, they can access. The next thing is that we want to be sure that requirements, when they are defined, we can connect these requirements to different type of functionalities and or kind of logical or, physical, concepts of the design. So we develop a traceability from our requirements to different type of, like, components for compliance validation to be sure that if we change a requirement, that would have impact on different components in the system as a a design, like a logical components or physical component, and we want to be sure that we can capture that impact. If we change something in the design, let's say, the battery size, that would have impact on the software and on the electronic device also, on the physical shape of the device. And we want to be sure that all of these team, teams and disciplines are aware of this change that we are applying to requirement. So through the traceability, we can connect to all of them and be sure that we can capture the impact and we can notify anyone involved in that. That would help us with risk management because now we know that anything goes wrong with any parameter, any part of the design, what would have the impact of that on the overall design? If I don't choose the right battery, if I my battery has a kind of a wrong function, what would be the, impact of that in overall health of the system and reusability and safety of the system? So all of these can be captured in risk management. Since all of these tools are connected to one platform, we can manage them in one location. So we don't if we change a parameter, that change of the parameter can be traced through the traceability. We can capture that in requirements, and also, we can do run risk management to be sure that what would be the impact of that parameter or tolerances of that parameter on the health of the system. Now today, I will explain this with an example. It's called ISO injection device. This is we are Dassault Systemes and GoEngineer. We are not developing medical devices, but we provide you tools and methodologies that helps you to to your job more efficiently. So my I'm explaining an imaginary or kind of like a an example, that if I want to design a medical device, how it would look like that, and how I do that. So my example, it starts with a wearable injection device. This device should be installed on or kind of mounted on, patient's body. It would measure some, like, blood substances or, like, kind of, parameters. And based on that, would inject some materials to the bloodstream to be sure that the patient would get the right amount of, like a medicine at the right time. So this device should work several times per day at several occasions and maybe over several days. So we want to be sure that all during this operation and the usage of the device, the device, would have the right functionality. Now this device has complex design, contains mechanical, electronic, software, and, hydraulic systems. And, also, there are some requirements to be sure we want to be sure that it's light and also accurate. I mean, we we need to be sure we are meeting all of these requirements at the same time. So the first thing I will explain is that we will think about requirements. This is an example. Now let's say the team decides that we need to get different type of battery. Our battery should have some type of, like, parameters or specifications. So this requirement would be captured and changed in our requirement management tool. Now I can be sure that at this specific time, when I change this requirement, it's captured, and, also, I will send a no notification to the stakeholders, whoever is involved in this, project, and is kind of should be notified about the battery discharge, and for the injection device. Now I can send these requirements to that person. I can modify this requirement and be sure that this is captured in the system. So we define, okay, this injection system needs one minute of, operation every time we started. So the battery should provide the right amount of voltage over the time that we are using. Now when I change this requirement, I can trace through this traceability app, and from requirements, I can look at the logical, functional, and physical components. They they would have impact from this change based on standards. So I would have some standards that would define how my software or, for example, electronic device should behave based on different, parameters that are defined in the requirements. Now as a system engineer, I can take this requirement information captured in my system engineering tool based on system and language, and I can define them in one location. Now I would see who are the stakeholders that they would have impact from this change. Maybe the patient, the doctor, the designer of the electronic component, or the circuit board, or the battery, or, kind of display monitor to show that I have the right voltage on the device. Now based on that, I would define this information for different stakeholders. Maybe I should change my interface or I should change the size of the equipment. Now the person who is modeling the, kind of cat or with the also the person that is involved in the design different aspect of design, like electronics should be aware of that. So we define all of this for different, companies, and we want to be sure that we provide the right communication between different devices that we have in that overall system or device. So we have electronic components. We have the battery. Sorry. And the mechanical system, we want to be sure that we have the right communication among different components, and we define them in our system. And we define what components we have in the system that they contain the battery or they are they have impact from the change of the battery. Maybe if I make the batteries larger, I may have to change the shape or the design of my circuit board. Now I go through the behavior analysis, and I would see, okay, what would be the functions or the operations of my medical device. Based on this operation, I can detect where the battery is involved in this operation. So I will develop a logical, architect model, for the or a state machine in the same process. So it is not separated, like two. Is in the same process, I can see how when and how I am going to use this battery or electronic device through the operation of my system. So I would know where this is going to be used and how much voltage or energy is going to drain from the battery. Now I would have all the parameters of the system defined for different stakeholders. So they would be aware of what parameters would be changed and what parameters are involved in this design. Now the system the team or stakeholders, like the design engineers, they have access to the requirements. They can see all of these requirements and their connectivity to different aspect of design, like functional architecture or logical architecture. So the, team engineer or the discipline engineer can see all these requirements, can connect these requirements to a specific functionality or logical component in the system or even physical model, can see the whole large functional architecture, so would see where that part of design is related in a functional architecture or logical architecture. If I am developing the battery, what would be the connection of the battery to different components of the system? So I would know that that change, what would be the impact. Now in the same simulation model, I can evaluate my battery behavior in the logical architecture. So my simulation model would be placed on the logical architecture. So my evaluation would be done on the design, not only on the logical architecture. As you see, it's related to the physical model or the CAD design. So if I change the shape of size of the battery, immediately, I can modify that change or design in my physical model as well. Now I talk talked about, evaluation of the design on the logical architecture. You see, this tool provides you evaluation method. You can analyze the battery with the pump, with the electron motor, with the patient's body, and see how the battery is providing enough energy to the electron motor and pumping system, to the hydraulic system, and you can evaluate how it's working in the overall system or the design that it would have impact on the behavior of the overall device. So with the different type of battery, with the different voltage or kind of behavior of the battery, you can evaluate how the overall device is going to behave, not only for one step of analysis or one step of operation. You can do it for multiple steps. Let's say five times using it per day or aft kind of consequently. So it's kind of like using it sequentially after each other. You want to see how the battery is performing five times or 10 times, not only in one step or one, occasion, also over through the whole day. And you can see, okay, the battery is changing the voltage. The voltage is going to get lower and lower, but you want to be sure that it doesn't go too low. That would make problem for the functionality of the electromotor pump, or, for example, interface or the microprocessor that is processing the whole system. So you can evaluate how far the battery can, kind of work, how many times I can use it before it gets drained, or kind of if the state of health of the battery is going to get lower, what would be the impact of that on the behavior of the battery and also overall system. So you can run this type of simulations, again, on the logical architecture. And the parameters of this simulation, they are linked to the physical model and your requirements. You change any requirement. You let's say today you decide, I'm going to use different model of battery or size of battery. Immediately, all these parameters would be updated, would be changed, and then you can run the same simulation without asking the simulation engineer to come back and do this analysis for you. So one of the advantages of having a model based system engineering approach, all the models from different disciplines, from different simulation engineers would be on the logical or physical architecture. You would own them. You would access to them anytime you need them. So when you change a parameter, immediately, you can run your simulation without going and asking the simulation engineer. Simulation engineer would make the model once for you, but it's always available to you. You can execute it right away from your model or from your requirement, parameters. Now the model that I showed you, is based on modelical language. Just you saw some kind of models that they look like a kind of very easy as an engineer, you just place a pump or kind of motor, and you run the simulation. You may ask what is tool about. This is, again, based on Modelica language. This language is developed more for engineers. You have all the equations behind all these like, components. You just drag and drop components, and you build different type of models for different disciplines. You have electronics, electrical, mechanical, or fluid. All of these kind of models can be developed by modelical language, so So you may have a whole system like the one that I explained to you, for that device in one simulation model. Different people, they can develop or different disciplines, they can develop the components they are working with, but they have all in one simulation model. They are using one simulation model. Now we I talked about kind of simulation model and dimolar or kind of one d simulation. But, also, you may ask, okay. How about FEA or CFD? What do I do? So in this example, I show you that I bring a SOLIDWORKS model, using, like, a translator or power by. I can directly drop the SOLIDWORKS model to my model or kind of develop it there, or I can do the change management. So I will keep the latest version of my SOLIDWORKS model. I just drop it to the SOLIDWORKS, and I would be access to the SOLIDWORKS model. Or I can transfer the SOLIDWORKS model to my platform. Now this model is accessible to FA FEA or CFD model. So I can immediately mesh it. I can develop, in this case, explicit Abacus model on the platform. I can run different type of analysis for that. So in this case that I'm showing is the explicit, impact analysis. If this component design drops, what would be the impact on the body or the cover of the device and also components that they are inside? So I can detect what would be the damage in different, kind of test cases. If it falls in different locations, in different conditions, what would happen? What would be the damage? So I can analyze it, not only in kind of FEA model, also is kind of, is done by simulation engineer. The simulation model is accessible to project engineer or other disciplines. They can see the model immediately. They can see different results on the platform. They can access to that, and they can analyze it. Let's say they change the weight of this because some companies they change. That would have impact on the weight and the, kind of stability of the device, and I can run the simulation right away from the change of the parameters. So I don't need to call the simulation engineer to run this simulation again for me. The simulation model is there. I just run the simulation, and I can get the report or output from this simulation, right away from, kind of my analysis. So, again, it would reduce the time for simulation engineer to create report, develop, some outputs, write them down in a document, and share it with other team members or for design review. Everything would be done automatically, and would be shared with other colleagues on the platform. The next thing, we always talked about the process of the design, but you will see that not only we can use this type of approach for the design, we can use it for development of the product or evaluation of your product. So, again, we go back to the Daimler model or one d simulation model. As you see, we have now the control system or the logical software that we are using for control of electromotor of this device. Now we want to be sure that the electromotor is behaving correctly based on the control, or the, also the software that we are developing for the tool. But not only we can dev generate that software, we can evaluate the software right away with a physical model as a digital twin or virtual twin. So instead of developing a motor and, testing it with software, I generate the software based on my modelical language, and I evaluate that software with the electro motor that I have also virtual in my simulation. And then now I can see how that electromotor would behave with my software that I have developed as with cogeneration. So this part, I'm showing that. So here you see that I have this controller. I have developed for my electromotor, and now I can analyze how this controller is working with this electromotor. The first thing is that I can run this controller on the plat on the Dimola model to be sure that this controller is working correctly with the, kind of physical model, which is, electron motor. The next thing is that now I am going to develop or generate embedded software with the c code or c plus plus or different type of, industry acceptable protocols. And now when I generate this embedded code, I want to be sure that my embedded code or generated code is working with this prototype correctly. So this in this process, I would define what type of production code I want to generate, what would be the typical target or microprocessor that I'm going to use. And now I generate the production code for my simulation. So here, I define, okay, type of the production code that I'm going to use, and I evaluate the production code before I generate it. I see, okay, I'm providing the right signal output from my controller, and now I build my, actually, code or algorithm in, by this tool. And it doesn't take that long. So already, I can develop the production code. I can reduce the work for software generation or software management by generating the code and using this code with the embedded software to evaluate how this embedded code for the controller is behaving with my virtual twin of physical system. So that would reduce the time of development several times. I mean, some of our customers already use this, and they said this reduce the time of development of the software from several months or weeks to several days. That would be or several hours. So you see that that process would get much shorter, much more accurate because you are evaluating your software before even you have a prototype. And, also, it will it's much much more cost efficient because the software development is very expensive process. So I I try to wrap up everything I explained to you with different examples and demos I showed you. I showed you that, we are using some models for model based system engineering. That helps us to improve communication. With these models, we are explaining or defining the system to different stakeholders or disciplines. We are using in a standard way of modeling. The SysML language in a standard, you share it with anyone, with your vendor or with your customer. They are able to read your models. They can understand it because it's a a global language. Anyone, this MBSE, like, feel they are familiar with this language. And it can model very complex systems and, simplify it or explain it how it's working with different type of behavior or parametric diagram. And, also, you can define what type of quality or requirements you are, expecting from the design. The next thing is that you can also provide collaboration among the team. I mean, you can connect different disciplines. You can help them to communicate with each other. You can govern all the process of communication with change management, validation, and evaluation management, test management, and project management. So you can, kind of govern the process of engineering, among, different disciplines, and you can trace from your requirements to physical, logical, functional architecture, or kind of different aspect of design so you can do the impact analysis. That helps you to develop a virtual system, instead of developing requirements for requirement evaluation validation. Not only you can validate the current design, you can change the parameters, you can optimize them, you can run trade off analysis. Let's say if you are not happy with the pump that you are using and you want to get different pump from different vendor, immediately, you can run a trade off and see what would be the impact, what would be the benefit of different design, and you can, right away, do the verification and evaluation. So this would reduce the time for the decision making. It would also reduce the number of the prototypes of the time that you can need to develop the prototype. And you remember at the beginning, I said people, they are not access they don't have access to the prototype in a large portion of the design. But at the beginning with this process, people who are working on the project, they can access to the virtual, model of the prototype, and, they can run lot of tests on that. So you are you can maximize test and, kind of validation, use cases that you want to do. That would have quite important, kind of, and also a lot on the improving quality of the product. So you can run as many as, you want, test and evaluation, and evaluate your system. Now in the process of the manufacturing and design, you are developing first a digital twin because you have some model in loop and also CAD model that is connected to your model in loop. And then the next step is that now you create virtual commissioning. You can develop, software in loop or hardware in loop so you can analyze your software or hardware with your design. And at the end, when it comes to manufacturing and also, testing or kind of, like, evaluation of a system, if something goes wrong, let's say the product goes, but it has some problem, you can detect the problem with the physical commissioning, so you can see probe, what is the problem, how I can immediately improve the problem and also make the system working better. So this system is or the methodology is not only a methodology for design. Overall, through the whole process of, product life cycle management, you would use it. It's not going to stop at, kind of design process. So I tried to explain model based engineering in very high level in this, presentation, to explain what would be the benefit and how it looks like. There are more details again. If you'd like to know more, I encourage you to talk to co engineer experts. They're very good experts in co engineer that they know about this process. They know how to kind of help you with any part of this process. Again, adoption of this methodology is not a one day job. You can slowly adopt it over through the process of the design, maybe one design, two design, and slowly over a year, you see that you can adopt the whole methodology with help from the experts, from co engineer, or from Dassault Systemes. We are very always very happy to help you to adopt this methodology. Good thing about it is not kind of limited to, software tools that we provide. You can take the benefit from the tools that you already have just doing a better integration among tools you have, and you may kind of use other tools that you may not have. But, over kind of time, that would make allow you to have we do this, slowly and with no kind of stress. So please, don't hesitate to contact us. Now if you have any question, I will be very happy to answer. Thank you, James. Yep. Alright. Yeah. Thanks, Benham. That was great presentation, good review of MBSE on the platform. I know it's like you said, there's a lot of pretty complex topics, and we can definitely get into the weeds if if anyone's interested in more detail on any of those. I do have a few questions to go through, but it's it's not too late. If anyone still, is hanging on and wants to ask some more questions or any feedback in the chat, we appreciate it. Okay. So I'll I'll just read them out to you, Benham, and then you can maybe answer. One is is asking more about how you can connect. I think you mentioned hardware in the loop, but how that can connect, or can you connect that to the three d experience platform? Yes. I mentioned about it, hardware in the loop. So we have tools like ControlBuilt or, some of our tools like Dimola, they have already some methodologies to communicate with hardware in the loop. So you can receive outputs, from the sensors or the test equipment that you are connecting to the platform, and, also, you can generate signals that also transfer to the testing, equipment. So either way is possible through ControlBuild or, Dimola or other tools on the platform. So there is a actually, there are some tools we provide for communication with hardware envelope. Yep. Okay. Perfect. Yep. Thanks. And then, you showed the requirements management in three d experience. So I guess the question is, is it possible to receive requirements from other tools? I know a lot of people use, Doors or Jama, and I'm sure there are others out there as well. Mhmm. So we have actually APIs and threads to communicate with this, software management tool or requirement management tool. So, we don't want to kind of keep everything for kind of like a platform or the tools that we are I I showed you in the example. You can, receive the requirements and the parameters from other requirement management tools. We have, digital trace to receive them, synchronizing with them to be sure that whenever you change a requirement or parameter, it would be automatically modified on our requirement management tool. So we have, we are complying with rectify, rec sorry, recIF, like, method as to communicate with other requirements management tools as well as Excel, PDF, or different kind of documents that we can or website, HTML that we can read requirements and parameters right away from them. Yeah. Okay. Yeah. So it sounds like lots of options. Okay. Perfect. And then I think the last one I have here, unless any more pop in, is asking about if it's possible to develop a more user friendly or custom interface for users, instead of kind of the the direct simulation test. Something mhmm. You're right. That's something that I noticed. I mean, not everyone is expert in FDA or CFD or the one d simulation tool I showed you, like Dimola or MATLAB or Simulink. So when we are using a platform like this, we can develop interfaces that these interfaces, they can communicate with these simulation tools without, any kind of opening the simulation tool or kind of using it directly. So as a user, let's say I'm a system engineer, project manager, or a manager who is not, kind of expert in simulation tools, I can, right away, just communicate with the interface and change the parameters and see the impact to with a very high fidelity simulation tool and understand how it's working. So instead of kind of directly opening the simulation tool, I can open the interface and run my analysis through interface. So this is also possible on the platform. We have tools that they can develop, interfaces. Yep. Okay. Perfect. Just double check one last time here, but I'm not seeing anything else coming in. So, yeah, thanks again, Benham, for the great presentation. And just to remind everyone, definitely reach out to your local account manager or, contact us on the website if you have any questions or wanna see maybe something more tailored, demonstration presentation for your organization. We'd be happy to do that. And it looks like, yeah, I guess we can go ahead and wrap up a little early here. We appreciate your time today and hope everyone has a great day. So thanks again. Thank you, everyone, for listening. Have a good day. Mhmm. Thank you. Alrighty. Bye. Bye bye.