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:

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:

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:

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:

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