モデルベース システムズ エンジニアリングを使用したインスリン注入ポンプの設計
この例では、モデルベース システムズ エンジニアリング (MBSE) ワークフローを使用して最適なインスリン注入ポンプの設計を調べる方法を説明します。インスリン ポンプは糖尿病患者が使用する医療機器であり、インスリンを継続的に供給し、食物摂取に合わせて可変量のインスリンを供給することでヒト膵臓を模倣します。
ウェアラブルなインスリン ポンプ デバイスの目的は、インスリンを必要に応じて、また食物摂取に応じて注入することで、装着者の血糖値を健康な設定値に近い値に維持することです。この例では、設計上で切り替える選択肢である 2 つのセンサー バリアントと 3 つのポンプ バリアントを含むインスリン注入ポンプ システムの提案を示します。
まずシステム要件を決定し、次にコード生成と検証テストを含む詳細な設計モデルを作成します。最後に、変化する要件を満たすシステム アーキテクチャ モデルをシミュレートします。
インスリン ポンプ システムのアーキテクチャ モデル
次の図は、インスリン ポンプ システムの System Composer™ アーキテクチャ モデルを示しています。この例では、Stateflow® ブロックを使用します。Stateflow ライセンスがない場合でも、モデルを開いてシミュレートできますが、ブロック パラメーターの変更などの基本的な変更しか行えません。
openProject("scExampleInsulinPumpSystem"); systemcomposer.openModel("InsulinInfusionPumpSystem.slx");
BGSensor コンポーネントは血糖値を測定します。Controller コンポーネントはインスリン速度について決定を下します。Pump コンポーネントは InfusionSet を使用して身体にインスリンを供給します。Patient は治療を受けます。BGMeter は BGSensor のキャリブレーションを行います。HID (ヒューマン インターフェイス デバイス) コンポーネントの最終的な形態は、患者がシステムと通信するための携帯電話のモバイル アプリかもしれません。HID は PatientDataServer コンポーネントに情報を提供し、このコンポーネントから Clinician、Regulator、および Reimburser の各コンポーネントに解析が送信されます。

システム要件とリンク
Requirements Toolbox™ を使用してシステム要件を解析し、それをさらにサブシステム要件に分割して、派生した要件をそれを満たすアーキテクチャ コンポーネントにリンクします。System Composer で要件をリンク、トレース、管理するには、Requirements Toolbox のライセンスが必要です。
Requirements Toolbox の要件パースペクティブで要件とアーキテクチャをまとめて管理します。Requirements Manager (Requirements Toolbox)を開くには、[アプリ]、[要件マネージャー] を選択します。要件パースペクティブで要件をコンポーネントにリンクするには、要件マネージャーから要件をクリックし、コンポジション ブロック線図のコンポーネントにドラッグします。
要件を編集するには、[要件]、[要件エディター] を選択するか、次のコマンドを入力して要件エディター (Requirements Toolbox)を開きます。
slreq.load("Infusion_Pump_System"); slreq.load("Insulin_Pump_Controller_Software_Specification");
slreq.editor

この時点での要件の分解と解析は、次の懸念事項を表します。
供給の精度
危険なレベルの低血糖を引き起こす過注入の軽減
バッテリー切れの状況やデバイスで薬剤がなくなる状況などのマイナスの結果を防ぐための故障解析
アーキテクチャ モデルで要件アイコンを選択すると、コンポーネントに関連付けられた要件が表示されます。たとえば、以下に Pump コンポーネントにリンクされた要件を示します。

逆に、要件を選択すると、その要件を実装しているコンポーネントが強調表示されます。たとえば、BGSensor コンポーネントは Sense blood glucose 要件を実装しています。

設計の最適な選択肢を見つけるための結果解析
結果解析は、重み係数を指定したさまざまなコンポーネント プロパティを合計する計算に基づいて設計オプションのビジネス価値を最大限に高めることを目的としたトレード スタディで構成されます。コンポーネントを開発するための非反復エンジニアリング (NRE) コストなど、多くのプロパティは直接入力します。ただし、コンプライアンス スコアは、コンポーネントのタイプごとに異なるデータに基づいて導出されるプロパティです。これらのプロパティは、システムのエンド ユーザーの負担をモデル化します。コンプライアンス スコアには、次の考慮事項が含まれます。
エネルギー消費
サイズと重量
精度
平均故障間隔 (MTBF)
動作中に発生する音レベル
使いやすさ
[モデル化]、[プロファイル]、[プロファイル エディター] に移動するか、次のコマンドを入力します。
systemcomposer.profile.editor
プロファイル エディターで定義する System Composer プロファイルは、プロパティが定義されたステレオタイプで構成されます。ステレオタイプをモデル内のコンポーネントに適用して、特定のプロパティ値を各コンポーネントに割り当てることができます。

ポンプとセンサーのトレード スタディの手順は次のとおりです。
すべてのバリアントの組み合わせを収集します。
バリアントを 1 つずつ有効にしてすべての組み合わせを表現します。
モデルを反復処理してコンプライアンスを計算し、保存されたパラメーターと計算されたパラメーターを使用して結果を計算します。
結果を収集し、同じ単位を使用して重み付けします。
最適化されたオプションを提供します。
BGSensor という名前のVariant Componentブロックには、異なる製造元が提供するセンサー例を表す 2 つの異なるセンサー バリアントが含まれています。

Pump という名前の Variant Component ブロックには、PeristalticPump、SyringePump、および PatchPump という 3 つの異なるポンプがこの例に含まれています。

プログラムにより、異なるバリアント選択肢の組み合わせを順番に切り替えて、コンプライアンスを計算し、その結果を監視し、設計の最適な選択肢を特定するには、OutcomeAnalysis.m を実行します。バリアント解析の詳細については、Analysis Function Constructsを参照してください。
run("OutcomeAnalysis.m")
正規化された結果のスコアは SensorA + SyringePump の組み合わせで最大値になります。この設計の選択肢がインスリン ポンプに最適です。
Controller 実装モデル
インスリン注入ポンプ コントローラーを Simulink® で実装します。Controller モデルにアクセスするには、InsulinInfusionPumpSystem アーキテクチャ モデルに移動して Controller コンポーネントをダブルクリックします。この実装の入力端子には、インスリン ポンプによって読み取られるユーザー メトリクスをもつ User input と、インスリン ポンプに関する情報をもつ Hardware status が含まれています。ModeControl という名前のブロックは、インスリン ポンプがどのモードで動作する必要があるかを決定します。

ModeControl という名前のブロックには、モードの選択方法に関する詳細を示す Stateflow チャートが含まれています。
モードは次の 3 つです。
システムが一時停止して修復され、クリア後に再起動される
Alarmモード食物摂取に合わせてインスリンを迅速に供給する
Bolus供給モード長時間にわたってインスリンを供給し、1 日を通して血糖値を安定した状態で保つ
Basal供給モード

モードが選択されると、このコンポーネントの動作によって出力端子のインスリン速度が決まります。

テスト マネージャーを使用した検証と妥当性確認
モデルベース デザインを使用して、アーキテクチャ設計とシステム要件を検証できます。抽象アーキテクチャ モデルと詳細な Simulink 設計モデルはトレース可能な要件リンクで接続されています。このセクションには Simulink® Test™ ライセンスが必要です。
Simulink の Controller 実装モデルは、Alarm handling 要件の要件トレーサビリティを示しています。

次のコマンドを使用して、Simulink テスト マネージャー (Simulink Test)を読み込んで表示します。
sltest.testmanager.load("Controller_Tests.mldatx");sltest.testmanager.view
Alarm_Detection 機能テストで Alarm handling 要件が検証されます。

[ハーネス] ボックスの右側にある
アイコンをクリックしてテスト ハーネスを開きます。この例では、Controller という名前のブロックがテスト ハーネスを使用してユニット テストを行うために分離されています。テスト ハーネスの作成の詳細については、Create or Import Test Harnesses and Select Properties (Simulink Test)を参照してください。

Test Sequence ブロックをダブルクリックして、テスト シーケンスのステップを表示します。ステップは、アラーム システムの機能を検証するためのシナリオを定義します。

このテストを実行するには、Simulink テスト マネージャー (Simulink Test)に戻ります。
sltest.testmanager.view
テスト ブラウザーでテスト Alarm_Detection を右クリックし、[実行] を選択します。[結果とアーティファクト] セクションでテスト結果を確認します。テストにパスすることは、Test Assessment ブロックで定義されている次の条件に従い、システム要件 Alarm handling が検証されたことを示しています。
低バッテリー、オクルージョン (ラインの閉塞)、または薬剤 (インスリン) 不足が生じた際にアラームがインスリン供給を無効にするかどうか
問題が解決した後にシステムが再起動するかどうか
参考
アプリ
- プロファイル エディター | Simulink テスト マネージャー (Simulink Test) | 要件エディター (Requirements Toolbox)