Model-Based Systems Engineering (MBSE) applied to Medical Device Development - MATLAB
Video Player is loading.
Current Time 0:00
Duration 43:49
Loaded: 0.38%
Stream Type LIVE
Remaining Time 43:49
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
  • en (Main), selected
    Video length is 43:49

    Model-Based Systems Engineering (MBSE) applied to Medical Device Development

    Overview

    Working on large systems that involve multiple teams?  How do you coordinate the interfaces between each of them? Do your developed features always match the original System Requirements?

    Architecting large systems that involve multi-discipline engineering can get complicated. Model-Based Systems Engineering (MBSE) is the formalized application of modeling to early development tasks, such as concept selection and architecture breakdown. The goal is to use models to create a structured and auditable approach to identify requirements, specify interfaces, and control risks throughout the product lifecycle – both at the component level and the system level.

    What does this this look like in action? Learn how you can implement an MBSE developmental approach utilizing System Composer™, Requirements Toolbox™ and the Simulink® platform.

    • Using models of an infusion pump as an example, we’ll demonstrate how to use models to
    • Break down and detail system architectures
    • Quantify early project decisions using trade studies
    • Communicate design specifications across multiple teams
    • Validate designs by integrating and testing engineering models

    About the Presenter

    Gaurav Dubey is a Consultant Application Engineer in MathWorks and specializes in the fields of Model-Based Design and System Engineering workflows, Implementation, verification and validation, and certifications for safety-critical applications. Gaurav works closely with engineers across industries to help them in adoption of Model-Based Design, and Model-Based System Engineering workflows.

    Gaurav brings more than 19 years of experience in embedded system development for automotive and aerospace applications. Gaurav holds a master’s degree in instrumentation engineering and a master’s degree in electronics and communications.

    Vamshi Kumbham is a senior application engineer at MathWorks India specializing in modeling, simulation, automatic code generation, and verification and validation. He works closely with customers across domains to help them adopt to MATLAB and Simulink in their Model Based Design and Model Based System Engineering workflows. He has over 11 years of industry experience in design and development of safety critical embedded applications.

    He has been a part of complete lifecycle of projects pertaining to automotive. Vamshi worked for Bosch as a senior software engineer and for Hyundai Motor India Engineering as assistant manager. He holds a bachelor’s degree in electronics and communication from Sri Venkateshwara Engineering College, Jawaharlal Nehru Technological University, Hyderabad.

    Recorded: 17 Aug 2023

    Good afternoon to all, and thank you for joining us for the second topic of our MathWorks Medical Device webinar series.

    Thanks, Prashant. Good morning, good afternoon, and good evening, everyone as Prashant mentioned, I'm Gaurav Dubey. I'm working as a consultant application engineer based in MathWorks Bangalore office. I, along with Vamshi, who is also from application engineering team based in Bangalore Hyderabad office, are going to take you through the workflow for model based system engineering for medical devices development.

    So in today's session, we are going to cover three major topics. First, we will go through the basics of what system engineering is, why we should do it, and how we can implement the system engineering, what are the key activities involved in implementing model based system engineering.

    And very important point is that how we can transition from model based system engineering to model based design smoothly. To start with, let me take you to the very brief introduction of what system is. If we look into the theoretical definition of a system, a system is a group of interacting and interrelated entities. These entities are connected with each other and they have defined boundaries, structure, and purpose, and then they communicate with the surroundings. So this is a theoretical definition of a system.

    But if you try to understand that in a simpler words, anything that you work on in today's world is a system, whether you are dealing with a mobile phone, a wristwatch, a car, or an aircraft or a spacecraft. Everything is a system or system of system because it has multiple components inside it, which are connected with each other and interacting with each other. And you can understand when you say systems, it directly indicates the complexity of the systems too.

    And that is why we use the system engineering. So system engineering is an interdisciplinary field of engineering and engineering management. System engineering deals with all the phases of your development cycle, starting from the capturing the requirement from your client or the customers or the stakeholders, all the way to the deployment and the operations of the system in the field. And why do we need a system engineering?

    As you know, today systems are getting more and more complex. We are supposed to develop more and more features with higher complexity in a shorter time with more reliability. Right? Everything which is making the system development are difficult tasks, and system engineering is all about coping up the complexities. It helps us in avoiding omissions and invalid assumptions. System engineering helps us understand the problem better. It helps us in doing a lot of the analysis and trade studies at the beginning of the requirement phases so that we can come up with a better solution.

    Unless you have a right problem in front of you, you can never develop a right solution, and that's what one science team said. If you had an hour to solve a problem, he would invest 55 minutes in understanding the problem. Then just five minutes finding out the right solution for it. So emphasis on implementing a better workflow for better analysis of the problem statement is not new. It's been there for centuries, and model based system engineering or system engine provides us a better way to implement that.

    Now system engineering, as I mentioned before, is a vast field. It covers everything from requirement to deployment, operation, engineering design, to the engineering management. If we talk about a component of system engineering, we are talking about model based system engineering. Now, what is model based system engineering?

    Model based system engineering or model based-- or MSE is an approach to engineering that uses model as an integral part of the technical baseline. It includes requirement, architecture, analysis, design, implementation, everything. So system engineer sits in between a very critical position between the customers and the development team. The job of system engineer to understand the client problem articulated in a way so that it can pass it on to the development team.

    System engineers is responsible to identify the alternate solutions, understand the requirements, avoid the omissions and invalid assumptions, and then pass on the filtered refined requirements to the development team and act as a bridge between the customer and the development. For doing this, system engineers need a lingua franca, a common language which can be understood by all the stakeholders across the development cycle.

    And that lingua franca for us are the models. We will use models as an architecture for a better communication and better understanding of the problem statement, and that is what the model based system engineering is. Now, let us go through the very simplified model based system engineering workflows. What are the stages involved inside that? And then later on in the second part of the session, today we will take you through an example to implement each and every stage of model based system engineering workflow.

    As we know, everything starts with the stakeholder needs. And today our stakeholder need is to develop an infusion pump or infusion set which can deliver the medicine to the body of a patient. We get the stakeholder needs into a very scattered way in a very basic language. For example, one of the stakeholder need for us is that the system should continuously do the glucose monitoring and the reading should be within the 10% of the tolerance.

    While another stakeholder has a requirement related to the bolus delivery or basal delivery of the insulin. Right? So we get these type of requirements in a scattered manner. It might be in the form of a PPT, PDF, or an email. We take those requirements and start capturing that into more systematic way. Into a textual requirement it can be those Word PPTs, or any of the textual requirement management tools that you might be using.

    Then we use those requirements to define our architecture of the system. It is a sort of a block diagram that we define for a system in which we explain what all components will be there in our system and how these components will interact with each other. That is something that we call the architecture. Then, as a system engineer, one of the responsibility that we have is to identify the alternate solutions for a one problem statement.

    Now in our case, we have to develop an insulin pump. For that insulin pump I have multiple options available in the market. I can use a peristaltic pump. I can use a syringe pump. I can use the patch pump. So system engineer job is to identify the best solution that can fit or that can satisfy the stakeholder need in terms of cost, the power consumption, the weight. Whatever the stakeholder criteria is, we have to identify which architecture is fitting best into their stakeholder need.

    Once we finalize the architecture, we have to communicate the architecture or the views or the ideas with the stakeholders. And that's the core of the system engineering. Until and unless you cannot understand your problem or your understanding of the problem with your stakeholder, it is of no use. Remember, we have to articulate the problem statement better and then pass it on to the stakeholder. And for doing that, we have multiple stakeholders available.

    When we develop an architecture, the architecture usually tend to become too complex because our system might have a mechanical component, hydraulic component, electronic software, multiple types of the components involved inside that. And not every stakeholder is interested in every part of your architecture. So we should be able to convert our architecture into the form which is relevant or of interest for the particular stakeholder.

    It can be a block diagram, or the stakeholder might like to see it in a different way, like a composition diagram. So we should be able to represent our architecture in any form, whichever is required by the stakeholders, and pass on our thoughts to or the thought process or understanding of the problem to that particular stakeholder. And at the end, when you finalize the whole architecture, obviously your architecture cannot run the system.

    We end up-- we went to the next stage of developing the behavior of those components. For example, if I have a controller, I need to start developing the algorithm for the controller. And that is where we move from model based system engineering to model based design, because here we are using models for designing the algorithm. Whether you are doing the design in Simulink, State Flow, or MATLAB, you should be able to connect your designs with your architecture for the system level simulation.

    So these are the key stages of the activities which are involved in implementing the model based system engineering workflow. So as I said in the beginning, everything starts with a stakeholder need. Right? You cannot develop a system until unless you have a requirement. Now, this requirement can be in a PPT, it can be an Excel, it can be Word. In any format, right? In my case, I had two stakeholders, and they shared their own requirement.

    So what I start doing is that I start capturing those requirements. If you are using Word, DOCs, or Excel, or any tool in capturing the requirement, we have a more formalized or more sophisticated segment, and that is something what we call the requirement toolbox. This is the view of the requirement toolbox that you can see. On the right hand side, you can see you have all the requirement captured into the hierarchical form. Right?

    So you have a requirement related to the accuracy, calibration, requirement related to the alarm, requirements related to the blood glucose reading, and so on. On the right hand side, if you see, you can capture that what type of requirements. You can capture a few of the attributes of the requirements. For example, what is the type of the requirement, the custom ID of the requirements, summary, et cetera. You can capture the details of the requirements, the whole text that basically represent your requirement.

    You can capture the other attributes like revision history. You can capture the custom comments. You can capture who modified, who captured the requirement, and when. All that information basically consists as a requirement. Having a Word document as a requirement is a very common workflow, but Word document is a textual tool in which you can capture whatever you want.

    But if you want to have a more systematic way of capturing the requirement, you need a requirement management tool, like requirement toolbox we have. And I will show a bit extra parts of the requirement toolbox, and that will give you an idea that why we have to capture in this form. So you can capture the requirements in the requirement toolbox, as I mentioned before. Having said that, we can have multiple types of requirements with us.

    For example, you can have a system requirement, which explained the system. You can have the hardware requirements, which basically explain what hardware goes inside your system. You can have a software requirement, which explains what will be the functionality of the software inside your system. So you can have any type of the requirement or multiple types of the requirement representing the same system, which gives us a problem statement is that how we organize our requirement and show the relationship between them.

    For example, on the top left hand corner, you can see that I have captured all the system requirements in requirement toolbox. In the same toolbox, at the bottom you can see I also have a software requirement set. Now these software requirements are developed for the system requirement, which I captured from my stakeholders. Right? So the software requirements are related to the system requirements. How do we show that relationship?

    In requirement toolbox you can link any of the software requirement. For example, in this case, I have a hardware alarm requirement. If I click on there, on the right hand side, you can see all the hyperlinks which takes us to the system requirements, which are satisfied by the software requirements. Similarly, if you click on the system requirements, it will take you to the software requirement and tell you what also software requirements are implemented for a particular system requirement.

    Now, why are we doing this? Why do we have to do-- why do we have to have the traceability between the different requirements which are dependent on each other? The reason is in future, if your stakeholder system requirements are updated-- for example, if your hardware alarm requirement and system level are updated, the tool should point you to all the dependent software requirement which need to be updated because one line of the system requirement is updated.

    If you have this traceability implemented, you can implement the change impact analysis very easily at the requirement level, and that is why we need to capture the requirements into this type of the requirement management tool. We can establish the traceability easily.

    Gaurav? I have a question here, Gaurav. So it's good that you're managing the requirements, you're managing the traceability inside MATLAB and Simulink tools itself. But as a software architect, as a system architect, I get my requirements from my stakeholders. So those requirements are managed in the other tools, like let's say those are a Word document or Excel sheet. So how do I manage the requirements which are written in the other tools?

    Excellent question, Vamshi, and then this is a very common workflow. Your client might provide you the requirement into the different tools. For example, Vamshi, as you said, Word, it can be DOORS, it can be Excel, or any requirement management tool. We understand that, and that is why we allow you to import the requirement from your external third party tools into the requirement toolbox environment.

    We can import it directly from Word, Excel, or DOORS, or can also use the industry standard ReqIF to import the requirement inside the Simulink environment. Then further, in case if your requirements are updated by stakeholders in your original form-- let's suppose DOORS-- we can synchronize those changes back into the requirement toolbox and can update the requirement in Simulink environment. You can go further and add or alter your own requirements on the top of it, or you can edit the requirement that you imported from the third party tool.

    Not only that. As we understand that you need a roundtrip solution, that means you want to maintain your requirement in your original form. They also provide the facility to export the requirement back into your original tool from which you imported the requirement. So you can implement the complete roundtrip with the third party tools which you are using for the requirement management. I hope I answered your question, Vamshi.

    Yes. Yes, Gaurav.

    Right. And then we move forward, right? So we captured all the requirements that we had. We ensured that our requirements which are dependent with each other have the traceability in between the requirements. We ensure that the different attributes of the requirements are being captured. Now the next stage is to develop the architecture for that particular system. For that I go to my system expert, who is Vamshi here. Vamshi is going to help us in developing the architecture of our system. Vamshi, over to you.

    Thanks, Gaurav. Yeah. Yeah. So as a system architect, I have to read all the requirements that are coming from different sources, like let's say stakeholder or let's say all my architects, all the analysis that is coming in. And then, as a system architect, my job is to architect the system. So for that I need to thoroughly read my requirements and then express the requirements in the form of an architecture. So to express that, we have a tool called System Composer wherein you can create these components easily, directly by dragging and dropping from this left hand bar.

    So for this system, for this insulin infusion pump, I have-- mainly I have three components. First I need to read the body glucose level, so I need to have a body glucose sensor, and then a controller which calculates the pump command, and a pump which delivers the insulin to the human body. So finally when I develop the system, it has come in a very detailed manner wherein I also developed a human interaction device also which can be a mobile or Android application wherein you can see how much insulin is getting injected into your body and per day how much insulin is getting injected into your body.

    So all the statistics that you can see on your screen. So finally, when I complete my architecture-- so it looks like this. On the top part you see the home setting wherein I have captured all the requirements of the device, but this device can also be interacted with the outside world. So this can-- the data that I see on the Android app can be sent-- the data can be sent on to the server.

    And this data can be analyzed by the regulators, by the reimbursers, and also by the clinicians. Maybe they use this data for different purposes, reimburse users for a different purpose, and clinician use it for a different purpose and regulators use it for a different purpose.

    Right. It's very interesting. So you know now whatever the textual requirement I captured, you nicely articulated that into an architecture and now have a better understanding how my system is supposed to behave. When I share this architecture with my stakeholders, what I need is some sort of a text involved inside it. I want to show how each component inside my architecture is satisfying my requirement of why a component is added into the requirement. Can you tell us how can we do that?

    Sure. Sure, Gaurav. That's a good question. So you explained about how you have a different hierarchy of your requirements. You have system requirement, you have software requirement, you have functional requirements, and you have hardware requirements, and so on and so forth. So in the same way from these requirements, as a system architect, I do create different architectures.

    And these architectures are also linked with one another, and I also ensure that these architectures are properly linked to my requirements, prospective requirements, so that we create the whole infrastructure of requirement linking and we create a digital thread between these functional requirements and your functional architecture. So if anybody wants to see how this requirement is implemented, you can directly open your requirements on the bottom and you can also see your architecture on the middle. Right?

    This view gives you both requirements and your architecture in the same way, so we call this as a perspective. So we are looking at the model in terms of a requirements perspective. So here you might have observed-- so we can read the requirement on the right hand side, or you can also read the requirement on the model itself. Right? So you see the architecture. You read why this architecture is developed this way. So by that you have an understanding that-- so this architecture component is originated from this particular requirement. I hope I have answered your question, Gaurav.

    Thanks, Vamshi. It looks fantastic. Now I can see my architecture and requirement in the same canvas. If I share it with my stakeholder, they can read the architecture. They can also understand the requirement behind it, so it provides them with more visibility, more readability on the architecture, and it's a fantastic workflow on that. Now, as you develop the whole architecture, this is leading to another question that I have. Right?

    In your architecture, you did mention the interaction between the components. For example, controller is getting the user command from a HID. Right? Or HID is sending telemetry data to the patient server. Now, when I pass this architecture to the software team to develop the behavior of it, the first question they will ask is that, what do you mean by data? What is all inside that? Is there a way to provide more insight of the communication or interaction between the components?

    Yes. That's a good question. So first you saw me creating the boxes, and then you saw me creating-- easily creating just these boxes together based on the requirements. Right? But now we do need to define what are these interfaces. Right? So at a high level, I'm just connecting one. Just this one connector from one block to another block, but that carries a lot of information.

    If you take this telemetry as an example from a HID, human interface device, if you see the telemetry, so you can see a blood glucose level carbohydrates and bolus, basal information, and main information. We can define. And not only we define this information, we can also say that we can define some properties of this information. If you take an example of a blood glucose and blood glucose level so you can also see what type of variable this is, what is the unit of this variable.

    So all this can be useful for your software engineers to easily understand and model, or can create the detailed behavior of the models. And then moving on, I do have a lot of information that I can define on my architectures. But the thing is you also need to define a lot of information that you need to pass it on to do a lot of analysis on your models.

    So here there's a concept called CDO types, in which you add a lot of additional metadata to allow the system engineers to define the domain specific information. So for example, if you are working on a software component. So let's say in your system architecture there are multiple type of components. As Gaurav mentioned, there are mechanical engineers involved. There are electrical electronics. There are multiple types of engineers involved. So to give a different metadata to different components involved here.

    So we use the concept called stereotypes by which, let's say if you have a physical component in your system, we define some IDs of those systems. We define a part number. We define weight. So we define this for each and every physical component inside your system. Right? And if you have, let's say, a software component, who is the owner of the software component? What's the skill level of the software component, or what's the status? What's the review status of that?

    And what's the task that you're performing on that software component? So all this can also be defined on your architecture. If you ask me how that'll help the system engineers, it will very well help you to do a lot of analysis on your system. So let's say for a controller, which is kind of a physical component in your system, I am defining a unit cost of my controller. And I'm also capturing what's the size that it occupies and what's the weight of my controller. Right?

    And what's the mean time between failure, MTBF? So I capture all the information we are calling it as a metadata or a stereotype information of a controller. Right? So in this way, I can capture this information for all the components, all the different components inside my system. And you must have observed there is a pump component also. The pump component, the properties or the stereotype of the metadata information is little different.

    So for a pump, how much noise it makes, or what's the unit cost of the pump. And there are some similarities. I mean, the cost information is same, I mean, for a component. But again, the noise level, how much power it draws, what is the energy consumption. So these are all we can understand and we can give. So this information, if you ask me, this comes from a controller vendor or a pump vendor who is selling it. Right?

    So this info comes from them, and we give this info and we will use this info to analyze the info. And if you remember, Gaurav said that there are multiple options. So let's say I spoke about a pump. Right? So there are different pumps that are available in the market. Patch pump, syringe pump, and there are other type of pumps in the market. So while I do the architecture modeling itself or while I am creating my architecture, I can accommodate all these options in my model to reduce the risk.

    Basically, before you even give it to your software engineers to develop, you would like to see whether my solution or the whole insulin infusion pump, which will work in all the cases, which will work in all the scenarios, or will it have any impact on the human body? Because the device is working on a human body, so we need to mitigate the risk. So for that, you need to wisely choose a choice between all these things. Right?

    So that's when you need to do-- you need to define the system characteristics and you need to do a lot of analysis on your system. Right? So while modeling my architecture, I have considered these three pumps here, and each pump has its own characteristics. And in the same way, if you see the blood glucose sensor, I have considered two different type of sensors and the data of these two sensors also I have captured using the stereotype information.

    So now my job is I have put all the data in my system, but now my job is how I can evaluate this data to see which pump and which sensor combination works well for my system. For that I can use a powerful MATLAB engine. I can write using this info, using, let's say, the cost info or using the energy consumption info, I can find which sensor and which pump combination gives me the better results. So MATLAB engine.

    Using a MATLAB engine you can write some script using all these values and create these graphs to see which one clearly stands out. So here, sensor A and syringe pump is giving me a very good returns, let's say if I use this combination. I mean, I can reduce my risk and I can exactly put the required amount of insulin into the patient's body. So once I have this clarity, I can go with this sensor A. I can purchase.

    I can go ahead and inform my purchase team to go ahead to purchase the sensor A and also the syringe pump for the production level activities. Moving on. Another area. So here we said an architecture is a combination of multiple disciplines. So these disciplines comes from different-- let's say mechanical discipline. Let's say electrical discipline. Right? So controller can be modeled by a person who knows about embedded systems, control system development, basically.

    And pump will be developed by a person who has more understanding about mechanical structures. Right? So again, in the same way the human interface device is developed by a person who knows about the Android and these kind of-- basically a software engineer who knows about the front end GUIs. Right?

    So if you would like to see how my information is flowing to another discipline or how my system affect the other system, you would like to concise this or you would like to reduce the huge architectural spaghetti model. I mean, I saw a lot of systems which becomes more and more complex over the years, and at some point you cannot even place where you, I mean, you would like to change, if you get any change request. Right?

    So what these viewpoints or what these architectural views helps you helps you to do is you could reduce or you could filter out some of the components in your system and create your own view of your system. Right? So you could filter, let's say, using all the stereotype data that we give. You could say that.

    Which consumes some energy. So if you filter out that data in that way, you could see a concise architecture which gives you only the architectural view which involves an electrical component which draws some power from the system, or which draws powers from your battery of battery of your system. So on the System Composer Canvas, if you click this architectural views and if you apply some filters using all the data that you have given, you could create these kind of class diagrams.

    You could create these kind of hierarchical diagrams or class diagrams and see what's the impact of my system onto the other system, or just see how all the electrical components in my system are interacting with each other, and how my electrical components are having an influence on mechanical system. So that's about the views.

    So after this, I now got the confidence that my system can work. So now as a system architect, I can pass on this system architecture design to the software engineers. So they will clearly design how a controller should be designed. So in the controller, what we are doing is we are calculating the command. We are calculating how much the pump should inject the insulin into the patient's body.

    So that calculation is happening in the controller, and the software engineer who knows about the control system is designing this. Right? So here there are multiple disciplines too. So a control system engineer develops the controls, and let's say a physical engineer or physical modeling engineer develops the pump. Right? So I'm using a different-- or the engineers may use different languages to express this, for suppose control system development is done using a Simulink.

    Our pump development is done using Simscape language. But you're integrating this into your bigger architectures, so you are integrating your Simulink detailed behavior or design behavior and you're integrating your pump behavior, which you have developed using, let's say, a Simscape language into our architecture model. And the use of integrating this into the architecture model is you can run.

    You can simulate this model to see if it is giving you the right results or not. So the detailed behavior-- or you have already transitioned from model based system engineering concept to model based design now, so you are giving this to-- I mean, the system level requirements are further drilled down into, let's say, low level requirements, which are software requirements.

    And your software engineers developed this, integrated this so that, as a system architect, I can run this and see how all the components are interacting with each other and whether all the components are giving me the exact result or not. Right? So once I can simulate the system, I can write some test cases. I can write some test scenarios.

    And I can also, let's say, write a sequence of scenarios, let's say from 0 to 10 seconds. I'll run my model with certain steps and then I'll go to another step and I'll run another type of commands and see how my system is responding. And during this process, I can also see how much coverage I have from my test cases or test scenarios.

    So not only just running the test cases. So if you see the whole workflow that we have discussed from the start, from the requirements management, if you define your system, you do the analysis, you create a detailed behavior, you simulate it and test it. So all this workflow is mapped to your IEC 62304 workflow. So here you can see how our tools are mapped to the software development process workflow that is followed according to the IEC 62304.

    And in each process you are collecting some artifacts which will serve as a proof. So in detail development stage you need architecture reports, you need detailed description reports. So in each stage you will-- when you run some tests scenarios, you will get a test results report. So by doing or by following all this workflow, you are also collecting the artifacts in each stage, which will help you to certify your products or certify your medical devices. Right?

    To summarize the whole model based design and model based system engineering workflow, first you can alter and manage your requirements in Simulink itself, or you can also import the requirements into Simulink from DOORS or from multiple other tools like Word or Excel. And then you can also create the architectures. You can create the test cases and you can automatically run all the test cases on the software units, and also accumulate the coverage.

    And then you can follow-- I mean, by following all this workflow you can also maintain the traceability between each stages of the development. And then you can generate the documentation. As I said, you can create the reports, you can save the reports, and these reports basically helps you to achieve the certification. And we do already have a TUV SUD pre-qualification certification, which certifies that all the tools, all the MathWorks tools can be used for your medical device development.

    So if I would like to summarize my whole system engineering workflow that we have discussed till now, first I'll be getting very high level requirements from my stakeholder needs. You heard Gaurav saying 10% tolerance is the requirement that is coming from a stakeholder, or a bolus delivery, how you deliver the insulin to the patient. And then you clearly write the requirements and the use cases, and from those requirements you are creating the architecture.

    And after creating the architecture, you are giving the attributes to this architecture. You are creating the interfaces and you are giving a lot of metadata to this architecture, and you are always doing some analysis on this architecture and you are always optimizing this architecture. And this whole thing is a very highly iterative process. Right?

    And because the architecture is so complex and it involves multiple disciplines, you need to collaborate and communicate with multiple stakeholders involved in this project development. Right? So it will also-- your architecture should also allow you to create multiple views and also needs to create an environment to communicate easily with your stakeholders. So it should be highly collaborative environment. And from there, an architecture should also accommodate to include or integrate with the detailed behaviors, detailed design behaviors.

    So by using Simulink, we could achieve that. So from architecture, we could easily move from architecture to your detailed design model. And this requirement should also extend-- I mean, as I said, the low level-- the high level requirements are decomposed into a low level requirement, and again, these low level requirements also should be linked.

    And the entire process you should create-- should be creating a digital thread between all this to respond to the multiple changes involved here. And there are multiple deliverables involved in this process, and using these deliverables and using these artifacts you could even go for IEC certification. So this is the whole story. I hope, Gaurav, you have understood the whole thing. If you could summarize what you have understood, maybe that will be helpful for everybody.

    Thanks, Vamshi. It was a fantastic overview. So what I could understand and hopefully all the attendees could understand is that we can implement the complete workflow starting from the requirement to the architecture development, trade studies, views, all the way till the model based design workflow, which includes VNV and implementation into a single environment.

    And most importantly, we can establish a digital thread across the different phases of the development. And digital thread is an extremely important component of model based design or digital engineering that is being implemented everywhere nowadays, because you should be able to address every development stage to the other development stages.

    So if there is a change in any stage-- for example, at requirement to stage, you should address it all the way till the architecture, design, test, VNV, or generation. At every stage where all the development will be impacted because the requirement is changed. So this whole workflow with the digital thread provide us the base for implementing the model based system engineering or the digital engineering in our day to day activities.

    Thanks, Gaurav. So I would like to give a couple of white papers. So let's say if you are new to model based design or if you are new to model based system engineering, or if you'd like to know more about how can I start my journey towards certification. Because I know for a medical device developer, developing the devices according to these FDA standards or IEC standards, so this is very important.

    So I could leave you with some white papers here. You could read these white papers. And we do have a lot of resources here if you are-- I mean, if you are new to System Composer, requirement toolbox, if you would like to know more about Simulink test or IEC Certification, we do have a lot of webinars, videos, resources available. So once you get this presentation at your end, you can click all these links and read. This is for you.

    And as a company, MathWorks, we also provide a lot of different types of support. We also can give you trials and evaluate. You could do some evaluations on our tools. And also if you have some type of critical projects, we can also offer you some consulting services. And if you would like to quickly ramp up your team, we can also give some trainings and technical support for you.

    Related Products