Hi, everyone. Welcome back to the series on modeling an infusion pump. My name is Rodney, and I'm an application engineer at MathWorks. In this final video, we'll go over the integration, and testing aspects of the infusion pump. So far in the first video, we took a look at what makes of the infusion pump, that is the three subsystems, namely the command generation, the control the logical subsystem, and the plant model. In the second video, we dived a little deeper and took a look at the individual blocks that make up the entire infusion pump under each of the three subsystems.
In this final video, we'll take a look at the test harnesses that are built into the model, and also how you can generate power from this infusion pump example, and put it onto hardware prototypes. And finally, we'll also take a look at how you can link your model in Simulink to requirements, and thereby keep track of the design process. Let's go over to Simulink.
In the previous two videos, we took a look at each of these subsystems. We saw that the command generation module takes in input from the user. The controller logical subsystem takes care of the decisions of the entire model such as detecting occlusion and render it off the entire system, and finally the plant subsystem. We saw that it's made up of some key components, which represent the real world components of the infusion pumps such as a DC model, the needles, the tubing of the delivery line, and the interaction of fluids, et cetera.
In order to take a look at the test harnesses, let's open up the control and logical subsystem. One of the test harnesses resides in the supervisory subsystem in the baseband chart. This internal test harness consists of the baseband chart. It test harnesses in the generator, or the signal build a block and a test assessment book.
Now, for the within Simulink you can generate test cases for an individual unit of your model, which is why it's called unit testing framework, or else you could also generate test cases for the entire model consisting of multiple blocks. In this instance, the baseband chart is the unit under test, and then we have take the test vectors coming in from the signal build a block, which comprised of various signals, which we'll take a look at, and also the test assessment block, so as to assess how the entire unit fares under the process of testing.
Does the unit under test perform exactly the way we expect it to, And the output to match the signals that are expected from it? With the signal build a block, when I open it up, we have different signals that will be acting as test vectors going into the internal test harnesses test unit. In this instance, I have six different scenarios that I've created in order to run the baseline chart through the test that I want.
So I'll go ahead and run a single simulation for fusion after turn off and take a look at what that does, if I have one. So what happens here is, when I run test on it I get a credit report in this instance for that particular signal that I choose. The coverage of what goes over some of the basic aspects like the author of the model was what version it was created, sorry, what version is the numbers, what the version of the model is, et cetera.
It also gives us metrics about the coverage that was generated, how many decisions were of the chart covered, what conditions were done, and what amount of coverage was taken care of in this Simulink test. Now, the summary here provides a few details, but if you want to understand better, you can open up this chart that stands alongside the coverage report. And you'll notice that it has more state charts within it.
Now at these stateflow chart, there are some transitions that are green in color, and the rest are red in color. This goes to show that the test that we just ran cover just these few transitions such as going in from off to the on state, and so from the base to this loft based on into under certain conditions. Though the transitions that are red in color basically speak out to the fact that, they're not all aspects of the test were covered.
Now, as a result, what we can do is run the entire set of signals through the test again. So for that I can go over the signal to the block, and simply hit them all and produce coverage. So that we have Simulink running for each of the signals of the signal build a block, and is the same here in this state flowchart.
So, you see the transition between the different states, that's Simulink transitioning from one signal or input test vector to the next test vector. And recording the performance of the basel chart, and then summarizing it into the coverage report. Once Simulink is through with all of the six signals or the sinks into vectors, it then summarizes the report and puts it alongside this model, that we've been observing.
And here we have the report, once again. And all of the details that we previously saw, but with a more complete list of tests that we ran. You'll notice that in this instance, the chart is green and when they go deeper into it, all of the transitions are green again, which goes to show that the entire unit test unit was completely tested with these test vectors, and it has passed with flying colors. So in that manner you can run tests, and take a look at how well the model fits.
So now, we took a look at the internal test harness. Let's see another example of the same instance. We saw a test harness built into the stateflow chart. The next example obviously is that of the occlusion detection, and how that is different this time is because of the thresholding method. Similar to the test have decided in this chart, for this instance of the occlusion detection algorithm, the algorith itself is the unit under test. And the input in this instance basically, a one day lookup table, which is a collection of data from the previous rounds of the infusion pump.
And finally, we also have the test assessment block, which will assess to see if this unit performs according to the way it was designed and and passes our test. Now, when I open up the test assessment block, you'll notice that gives me the option to write statements, for the test cases. So, basically, here if I were to pull out the scope of the delivery line preassure.
The statements for the test assessment basically, say that we have designed this occlusions detection thresholding algorithms is in this testing framework. In order to identify occlusion when the delivery line pressure shoots beyond a certain threshold. If all is well, and the software is designed right then the system performs exactly the way we want it to.
However, should the occlusion be detected before 50 seconds, or before the occlusion occurs here itself, obviously it is reporting a false alarm and thereby the model is not performing the way we want it to, and therefore we can show that the system has reported a false alarm, and the next statement is that, in case, the occlusion occurs and the system identifies it 30 seconds before, but even 0.5 seconds after obviously, the system is not designed to report it the right way and therefore, gives us the result that it failed to report the alarm. So in such a manner you can come up with the statement for your test assessment block and create a test to run, and thereby test your unit if it works.
Now, we took a look at the internet test harnesses. We will move over to the next aspect which is co-generation. Once the model of the infusion pump is complete, and all tests are run in order to check the performance, we then go to the next level, which is testing the software on hardware prototypes. In order to do that, you need to write C, C++ code, and then deployed on hardware prototypes. The nice thing is Simulink provides these features as well.
And in order to generate code all you need to do is enter the coding perspective in the Simulink environment. You can also take a look at the different codes that we have available under the apps tab. So once you drop that down you can see that for co-generation of that idea of other products like the embedded coder, Simulink coder, HDL, PLC coder, et cetera. In this instance, I simply enter the coding perspective, and at the click of a button, I'm able to generate C and C or C++ code for my entire model.
The code that generated comes in alongside the model, but it also creates a summary report for the user to share with the other end users, and also take a look at the metrics. Now, this report is really neat in that it summarizes the entire model, the author and such, and then it also gives us what's called, a static called metrics report going to show the memory usage, number of lines for each of the subsystems, et cetera. And as you scroll down further, you have the main C files and the header files as well.
So in such a manner, all of the code pertaining to each of the blocks of the infusion pump is generated and summarized and stored in this report. If I were to take a look at a code alongside the model. The only thing is I can navigate between the two linkcode traceability to see what aspect of the model for instance, if I were to click on supervisory control supervisory subsystem, it will point to forward pertaining to that particular build a block. In such a manner you can navigate between the two and see what line of code correlates to which section of your model.
Along similar lines of traceability, in the link also lets you connect your model requirements. So in that manner what you can do is link all of the model features to requirements. I can enter the requirements perspective and take a look at the requirement editor. The new thing is it gives us the IDs associated with each of these requirements, a brief summary on what the title of the requirement is, and when you go deeper into it, it gives you the description for each of the associated requirements.
Aside from giving us a summary and ID and when, or how it was created by, similar requirements also gives us the option to keep track of whether or not that aspect of the model was verified. And then you can take a look at all of these details in the form of a document. In this instance, we've linked it to a Word document, and thereby it's pointing out the requirement that I'm currently taking a look at, which is the multispeed control of. Such a manner, to thank your requirements and keep track of your workflow at your medical device from scratch all the way to through typing them on a hardware device.
That brings me to the end of the integration and testing phase of the infusion pump. So in this video, we took a look at the integration and testing aspects of the infusion pump by observing how a internal test harnesses can be created, how you can generate code, and also how you can link requirements to an infusion pumps model within Simulink. That's how you can implement or design your medical device starting from requirement all the way to implementation, with the help of tooling and model based design.
Overall, are tools maped well with the 60 to three, or four software development process. And there are several such examples that can bring you up to speed and help with any questions that you might have. There are some other real world examples that you can develop using a similar workflow with Simulink Stateflow and semi-skimmed such as the fully based surgical tooltip, neonatal ventilator, or mechatronics bed in order to analyze the effect of the vibrations on the movement, and finally decontamination process with the endoscope. Thank you.
