Main Content

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 diabetic humans 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.

systemcomposer.openModel("InsulinInfusionPumpSystem");

The 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 InfusionSet. 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 Clinician, Regulator, and Reimburser components.

System Requirements and Links

Use Requirements Toolbox™ to identify 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 dies 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 Pump component.

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 a compliance score based on different metrics in the system. The compliance is a function of other properties that represent the burden to a user versus the benefits. The compliance score includes these considerations.

  • Energy consumption

  • Size and weight

  • Accuracy

  • Non-recurring engineering cost (NRE)

  • Mean time between failures (MTBF)

  • Consumable cost

  • East of use

Navigate to Modeling > Profiles > Profile Editor, or enter this command.

systemcomposer.profile.editor

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:

  1. Collect all variant combinations.

  2. Activate variants one by one to represent all the combinations.

  3. Iterate over the model to calculate compliance and compute the outcome using the stored and calculated parameters.

  4. Collect outcomes and weight them using the same units.

  5. 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 PeristalticPump, SyringePump, and PatchPump.

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.

run("OutcomeAnalysis.m")

Figure contains an axes object. The axes object with title Net outcome contains an object of type bar.

The normalized compliance 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:

  • Alarm mode, where the system is be suspended, repaired, and restarted once clear

  • Bolus delivery mode to deliver insulin quickly with food intake

  • Basal delivery 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.

The Controller implementation model in Simulink demonstrates requirements traceability for the Alarm handling requirement.

Load and view the Test Manager (Simulink Test) using these commands.

sltest.testmanager.load("Controller_Tests.mldatx");
sltest.testmanager.view

The 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).

sltest.testmanager.view

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

See Also

| (Requirements Toolbox) | (Simulink Test)

Related Topics