Design Insulin Infusion Pump Using Model-Based Systems Engineering
This example show you how to use a model-based systems engineering workflow to investigate optimal insulin infusion pump design. Insulin pumps are medical devices used by people with diabetes that mimic the human pancreas by delivering insulin continuously and delivering variable amounts of insulin with food intake.
The purpose of an insulin pump wearable device is to keep the blood glucose level of the wearer near a healthy set point by infusing insulin as needed and in response to food intake. This example shows a proposed insulin infusion pump system with two sensor and three pump variants that represent alternate design choices.
Begin by determining system requirements, then create detailed design models with code generation and verification tests. Finally, simulate the system architecture model that meets the evolving requirements.
Insulin Pump System Architecture Model
This figure shows the System Composer™ architecture model for the insulin pump system. This example uses Stateflow® blocks. If you do not have a Stateflow license, you can open and simulate the model but can only make basic changes, such as modifying block parameters.
BGSensor component measures the blood glucose level. The
Controller component makes a decision about insulin rate. The
Pump component provides insulin to the body using the
Patient recieves the treatment. The
BGMeter calibrates the
BGSensor. Finally, the
HID (human interface device) component may be a mobile app on the phone for the patient to communicate with the system. The
HID provides information the the
PatientDataServer component, which sends analyses to the
System Requirements and Links
Use Requirements Toolbox™ to analyze the system requirements, further break them down into subsystem requirements, and link derived requirements to architectural components that satisfy them. A Requirements Toolbox license is required to link, trace, and manage requirements in System Composer.
Manage requirements and architecture together in the Requirements Perspective from Requirements Toolbox. Select Apps > Requirements Manager. To edit requirements, select Requirements > Requirements Editor or enter these commands to open the Requirements Editor (Requirements Toolbox).
slreq.open("Infusion_Pump_System"); slreq.open("Insulin_Pump_Controller_Software_Specification"); slreq.editor
The requirements decomposition and analysis at this point represent these concerns:
Accuracy of delivery
Mitigations against over-infusion, which leads to dangerously low blood glucose levels
Fault analysis to prevent negative outcomes, for example, when the battery is depleted or the device runs out of medication
On the architecture model, select the requirements icon to see the requirements that are associated with the component. For example, below are the requirements linked to the
Conversely, select a requirement to see the highlighted component by which the requirement is implemented. For example, the
BGSensor component implements the
Sense blood glucose requirement.
Outcome Analysis for Optimal Design Choice
Outcome analysis consists of a trade study where the goal is to maximize the business value of the design options based on calculations that sum up different component properties with weighting factors. Many are directly entered properties, such as non-recurring engineering (NRE) costs to develop the component. Compliance score, however, is a derived property that is based on different data for each type of component. These properties model the burden to an end user of the system. The compliance score includes these considerations:
Size and weight
Mean time between failures (MTBF)
Sound level produced during operation
Ease of use
Navigate to Modeling > Profiles > Profile Editor, or enter this command.
A System Composer profile, defined in the Profile Editor, is composed of stereotypes with properties defined. You can apply stereotypes to components in the model to assign specific property values to each component.
The pump and sensor trade study includes these steps:
Collect all variant combinations.
Activate variants one by one to represent all the combinations.
Iterate over the model to calculate compliance and compute the outcome using the stored and calculated parameters.
Collect outcomes and weight them using the same units.
Provide the optimized option.
A Variant Component block named
BGSensor contains two different sensor variants representing example sensors from different manufacturers.
The Variant Component block named
Pump contains three different pumps in this example called
To programmatically cycle between the different variant choice combinations, calculate compliance, and monitor the outcome to determine the optimal design choice, run
OutcomeAnalysis.m. For more information on variant analysis, see Analysis Function Constructs.
The normalized outcome score is at a maximum for the
SensorA + SyringePump combination. This design choice is optimal for the insulin pump.
Controller Implementation Model
Implement the insulin infusion pump controller in Simulink®. The input ports in this implementation include
User input, with user metrics that the insulin pump reads, and
Hardware status, with information about the insulin pump. The block named
ModeControl deteremines in which mode the insulin pump must operate.
The block named
ModeControl contains a Stateflow chart with details on how to select the mode.
The three modes include:
Alarmmode, where the system is be suspended, repaired, and restarted once clear
Bolusdelivery mode to deliver insulin quickly with food intake
Basaldelivery mode to deliver insulin over a longer period of time to keep glucose levels steady throughout the day
After the mode is selected, this component behavior determines the insulin rate for the outport.
Verification and Validation Using Test Manager
You can use model-based design to verify architectural designs and system requirements. The abstract architecture model and the detailed Simulink design model are connected with traceable requirement links. This section requires a Simulink® Test™ license.
Controller implementation model in Simulink demonstrates requirements traceability for the
Alarm handling requirement.
Load and view the Test Manager (Simulink Test) using these commands.
Alarm_Detection functional test verifies the
Alarm handling requirement.
Click the icon to the right of the Harness box to open the test harness. In this example, the block named
Controller is isolated for unit testing using a test harness. For more information on creating a test harness, see Create Test Harnesses and Select Properties (Simulink Test).
Double-click the Test Sequence block to view the steps in the test sequence. The steps define a scenario to verify the functioning of the alarm system.
To run this test, go back into the Test Manager (Simulink Test).
Right-click the test
Alarm_Detection in the Test Browser and select Run. In the Results and Artifacts section, view your test results. A passing test indicates that the system requirement
Alarm handling is verified by the conditions defined in the Test Assessment Block:
Whether the alarm disables insulin delivery when there is low battery, occlusion (line blockage), or low medication (insulin)
Whether the system restarts after the issue has passed