Design Insulin Infusion Pump Using Model-Based Systems Engineering

This example shows you how to use a model-based systems engineering (MBSE) 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.

openProject("scExampleInsulinPumpSystem");
systemcomposer.openModel("InsulinInfusionPumpSystem.slx");

The BGSensor component measures the blood glucose level. The Controller component makes a decision about the insulin rate. The Pump component provides insulin to the body using the InfusionSet. The Patient receives 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 to the PatientDataServer component, which sends analyses to the Clinician, Regulator, and Reimburser components.

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 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 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:

• Energy consumption

• Size and weight

• Accuracy

• Mean time between failures (MTBF)

• Sound level produced during operation

• Ease 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")

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®. To access the Controller model, navigate to the InsulinInfusionPumpSystem architecture model and double-click the Controller component. 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. This section requires a Simulink® Test™ license.

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

Load and view the Simulink 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 or Import 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 Simulink 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