医療機器ネットワークの遅延を予測可能に:TSNとSDCの統合による自動化ワークフロー

· 論文解説

🎧 この記事を音声で聴く(AI生成Podcast)

解説対象論文: Evaluation of an automated workflow for TSN-based bounded-latency communication in ISO IEEE 11073 SDC-based medical networks
International Journal of Computer Assisted Radiology and Surgery|被引用数: 0(2026年10月1日時点)

手術室などの時間制約が厳しい医療環境では、医療機器間の確実で予測可能なデータ通信が不可欠です。ISO IEEE 11073 SDC(Service-oriented Device Connectivity)規格は相互運用性を可能にしましたが、予測可能な伝送挙動は未標準化でした。本研究は、標準イーサネットの拡張であるTSN(Time-Sensitive Networking)をSDCベースの医療ネットワークに統合し、時間分割メカニズムを通じて遅延の範囲が限定された(bounded-latency)通信を実現するための自動化ワークフローを評価しました。このアプローチは、複雑なTSN設定作業を簡素化し、医療アプリケーションの安全性と信頼性を向上させる可能性を秘めています。

研究サマリー(FINER & PICO)
Feasible実施可能性 SDCベースの医療ネットワークでのTSN自動設定は技術的に実現可能であることが実証された。
Ethical倫理面 対象者安全向上に貢献するが、具体的な倫理的側面は本研究で直接評価されていない。
Interesting面白さ 手術室などの時間制約が厳しい医療環境における機器間通信の課題解決に貢献する。
Novel新規性 MDIBから通信要件を自動抽出し、TSN設定を生成するワークフローの統合が新規性を持つ。
Relevant切実さ 相互運用性のある医療ネットワークにおけるリアルタイム通信の信頼性向上は、臨床現場に直結する。
Measurable測定可能性 さまざまなネットワーク条件下でのSDCメッセージ遅延が詳細に測定され、評価された。
Modifiable派生・改善 TSNのスケジューリングパラメータを調整することで、通信挙動を最適化できる可能性が示された。
Structured文章構造 SDC標準の構造化された情報(MDIB)をTSN設定に活用するアプローチが取られた。
PICO / PECO対象・介入・比較・結果 医療機器ネットワーク(P)におけるTSN統合(I)と非統合(C)の通信遅延と安定性(O)を評価。

はじめに:手術室の医療機器連携とリアルタイム通信の課題

どうも、Beyond the Pixelです。
手術室のような高度な医療環境では、様々な医療機器が連携し、正確かつ迅速な情報伝達が求められます。2019年以降、ISO IEEE 11073 SDC(Service-oriented Device Connectivity)という標準規格により、ベンダーに依存しない医療機器間の相互運用性が可能になりました。しかし、この規格だけでは、データ伝送の挙動を予測可能で確実なものにするメカニズムがまだ標準化されていません。フットスイッチを使った高周波外科機器のトリガーや、ロボット支援手術における力覚・位置フィードバックのように、わずかな遅延が対象者の安全を損なう可能性のある時間制約の厳しい医療アプリケーションにとって、この課題は極めて重要です。これまでの研究では、SDC通信の平均遅延は低いものの、ネットワークの状態変化によって変動が大きく、遅延のピークが発生することが報告されており、厳格な遅延制限が要求されるアプリケーションへの適用を制限していました。

Table 2
Table 2. Table 2 Statistics of latency distribution of SDC messages with and without background traffic, without TAS configuration解説: この表は、TAS(Time-Aware Shaper)構成なしの場合において、バックグラウンドトラフィックの有無がSDCメッセージの遅延分布に与える影響をまとめたものです。各メッセージタイプ(Activate Request, Activate Response, Metric Report)について、最小値、最大値、平均値、中央値、標準偏差がミリ秒単位で示されています。バックグラウンドトラフィックがない場合とある場合で、特にActivate RequestとMetric Reportで最大遅延が大きく増加していることが分かります。

このような時間的制約を満たすために、現在では独自のソリューションや別のリアルタイムネットワークに依存しているシステムが多く、追加のケーブル配線が必要となり、設置・保守コストが増加する傾向にあります。そこで本研究では、標準イーサネットの拡張であるTSN(Time-Sensitive Networking)を用いて、医療機器ネットワークにおける予測可能な遅延(bounded-latency communication)を実現するアプローチを評価しました。TSNは、時間同期され制御されたデータ伝送を可能にし、信頼性と時間決定的なデータ配信を実現します。

TSNとSDCの統合による自動化ワークフローの実現

この研究では、SDCベースの医療ネットワークにTSNを統合し、時間分割メカニズムを通じて遅延の範囲が限定された通信を提供することを目的としています。著者らは、SDCデバイスから伝送要件を抽出し、ネットワーク展開用のTSN設定ファイルを生成する自動化プロセスを開発しました。この自動化プロセスは、SDCデバイスのMDIB(Medical Device Information Base)から通信パラメータを抽出することから始まります。MDIBは、医療機器の機能構造と動的挙動を記述する中央コンポーネントです。XMLベースの解析を用いて、MDIBから指標(Metric)とサービス制御オブジェクト(SCO)が通信ストリームとして特定されます。ペイロードサイズはSDCメッセージ構造に基づいて推定され、伝送周期は決定周期(指標)および呼び出し周期(SCO)から導き出されます。安全分類は優先度レベルにマッピングされます。

Table 1
Table 1. Table 1 MDIB analysis results for a high-frequency surgical device解説: この表は、高周波外科機器に関するMDIB解析の結果をまとめたものです。Handle、Payload (Byte)、Safety classification、Cycle (s)、Source、Destinationの各項目について、3つの通信ストリーム(HFGEN_ACTIVATE_CUT_MONO1、HFGEN_CUTPOWER_1、HFGEN_COAGPOWER_1)の通信パラメータが示されています。例えば、HFGEN_CUTPOWER_1は1644バイトのペイロードを持ち、Safety classificationはMedA、サイクル時間は0.5秒であることが分かります。

スケジュール生成には、オープンソースのTSNKitフレームワークが使用され、ルーティングとスケジューリングを同時に行うJRS-WAアルゴリズムが採用されました。スケジューラには、ネットワークトポロジとストリームセットが入力として必要です。ストリームパラメータはMDIB解析から自動的に導出され、トポロジは手動で提供されます。ストリームセットの仕様に基づいて、SDCプロトコルメッセージのみがスケジューリングされ、TCPおよびHTTPトラフィックは予約されていない時間スロットを使用すると仮定されます。PTP(Precision Time Protocol)同期メッセージは、TAS(Time-Aware Shaper)の動作に不可欠であるため、各リンクに含められ、最高の優先順位が割り当てられます。

生成されたGCL(Gate Control List)は、CNC(Centralized Network Controller)を介して展開されます。Linuxエンドシステムでは、TAPRIO(Time-Aware Priority Scheduler)と呼ばれるトラフィック制御キューイング規律が設定に使用され、TSN対応スイッチには設定ファイルがリモートで展開されます。

Figure 2
Figure 2. Fig. 2 TSN network structure解説: この図は、TSNネットワークの構造を示しています。ネットワーク参加者とCNC(Centralized Network Controller)の間にCUC(Centralized User Configuration)が位置し、そこから通信要件がCNCに提供されます。CNCはこれらの情報に基づき、デバイス固有のGCL(Gate Control List)を計算し、TSN対応デバイスに配布します。TSNデバイスとTSNブリッジが相互に接続されている様子が描かれています。

この自動化されたワークフローにより、TSN構成の展開にかかる労力を削減し、医療分野での実用性を高めることが期待されます。

プロトタイプネットワークでの評価:TASスケジューリングの効果

評価は、2つの仮想エンドデバイスとTSN対応イーサネットスイッチで構成されるプロトタイプSDCネットワークで実施されました。1つの仮想デバイスがSDCプロバイダー兼CNCとして機能し、もう1つがSDCコンシューマーとして機能します。著者らは、最大遅延を最小化するのではなく、システムレベルの安定性と実現可能性を評価するために、十分に高い遅延境界を設定しました。SDCプロバイダーは500ミリ秒ごとに2つの数値指標更新をコンシューマーに定期的に送信し、1秒ごとに1つのアクティベート操作を処理しました。

TAS(Time-Aware Shaper)構成なしで評価されたSDC通信では、バックグラウンドトラフィックがない場合、遅延は23ミリ秒以下に収まり、分散も低いことが確認されました。しかし、負荷がかかると散発的な遅延ピークが発生し、中央値の10倍以上になることもあり、ネットワーク負荷に対するSDCの感度が示されました。(表2)

次に、異なる3つの送信ウィンドウ寸法設定戦略(75 µs固定、ペイロードサイズに比例して10倍、100倍)を用いて、TSN-TASによるSDC通信の安定性が評価されました。

Figure 5
Figure 5. Fig. 5 Comparison of schedules for SDC traffic regarding window durations. Number of time slots in parentheses解説: この図は、SDCトラフィックにおけるゲートオープンウィンドウの期間について、異なるスケジューリング戦略(オリジナル、75µs、ファクター10、ファクター100)を比較したものです。各リンクにおける最小値から最大値の範囲と平均値が示されており、ファクター100スケジューリングが他の設定と比較して、大幅に長い送信ウィンドウ期間を持つことが見て取れます。括弧内の数字はタイムスロットの数を示します。

内部iPerf負荷(コンシューマーとプロバイダー間のトラフィック)の下では、スケジューリング戦略間で違いが観察されました。75 µsスケジューリングでは、状態更新メッセージの遅延が時間とともに増加し、最終的にコンシューマー側での状態更新が途絶えました。これは、大きな頻繁な状態更新メッセージに対して送信ウィンドウが不十分であったため、ゲートが閉じている間にフレームが蓄積し、遅延が増加したためと考えられます。持続的に状態更新遅延が増加すると、コンシューマーはサブスクリプションを終了させます。ファクター10スケジューリングでは、アクティベート要求と応答は類似の挙動を示しましたが、最大遅延は異なりました。ファクター100スケジューリングでは、状態更新トラフィックが周期的な鋸歯状の遅延パターンを示し、遅延が約100~200ミリ秒まで徐々に増加してから低下しました。これは、ゲートが閉じている間に定期的なキューの蓄積が発生し、ゲートが開くと空になることを示唆しており、状態更新周期とGCLサイクルとの間の位相のずれを示しています。

Figure 6
Figure 6. Fig. 6 Latency distributions for 75 µs, factor-10, factor-100 scheduling with internal iperf shown as boxplots for a Activate Request, b Activate Response and c Metric Report解説: このボックスプロットは、内部iPerf負荷(コンシューマーとプロバイダー間のトラフィック)の下での75µs、ファクター10、ファクター100スケジューリングにおける遅延分布を示しています。(a)はアクティベート要求、(b)はアクティベート応答、(c)は指標レポートの遅延を示しています。75µsスケジューリングでは、特に指標レポートで大きな遅延と分散が見られますが、ファクター100スケジューリングでは、一般的に遅延が低い傾向にあります。

外部iPerf負荷(第三のノードから両エンドポイントへのトラフィック)の下でも、同様の傾向が観察されました。75 µsスケジューリングでは、状態更新の遅延が数秒以内に急速に上昇し、その後コンシューマーで更新が受信されなくなりました。ファクター10スケジューリングでは、測定開始から状態更新が不安定で、ほぼすぐに失われました。これに対し、ファクター100スケジューリングは、状態更新トラフィックとアクティベートトラフィックの両方が顕著な外れ値なしに安定しており、十分な長さのゲートオープンウィンドウがトラフィック到着と構成されたGCL間の位相ずれを吸収できることが示唆されました。

Figure 7
Figure 7. Fig. 7 Latency distributions for 75 µs, factor-10, factor-100 scheduling with external iperf shown as boxplots for a Activate Request, b Activate Response and (c) Metric Report with statistics in table below解説: この図は、外部iPerf負荷(第三のノードから両エンドポイントへのトラフィック)の下でのSDC通信における遅延分布を示しており、75µs、ファクター10、ファクター100スケジューリングごとのボックスプロットと統計表が含まれています。(a)アクティベート要求、(b)アクティベート応答、(c)指標レポートの遅延が示されています。ファクター100スケジューリングが、他の設定と比較して、遅延の中央値、最大値、標準偏差が低いことが分かります。

著者らは、ファクター100スケジューリングは最も堅牢で再現性が高いと結論付けていますが、タイミング制約は一貫して満たされておらず、厳格なスロット順守が保証できないことを示しています。

QUICプロトコルを利用したSDC通信の評価

この研究では、さらに、転送遅延の低減を目的として、HTTP/2 over TCPをHTTP/3 over QUIC(UDPベースのトランスポートプロトコル)に置き換えるsdcXライブラリの実験的な変更も評価しました。現在の実装ではアクティベート操作のみをサポートしているため、この評価ではアクティベート操作に焦点を当てています。

Figure 8
Figure 8. Fig. 8 Comparison of schedules for SDC over QUIC traffic regarding window durations. Number of time slots in parentheses解説: この図は、QUICプロトコルを介したSDCトラフィックにおける、異なるスケジューリング戦略(オリジナル、75µs、ファクター10、ファクター100)でのゲートオープンウィンドウの期間を比較したものです。従来のSDCトラフィックと比較して、スケジュールされたメッセージ数が少ないため、各リンクで必要なタイムスロット数(括弧内の数字)が減少しており、ファクター100では他の設定よりも長いウィンドウ期間を示しています。

スケジュールされたメッセージ数が減少したため、必要なタイムスロットも少なくなり、全体的なゲートオープン時間は短縮されました。

ベースライン測定では、従来のSDC通信と比較して、わずかに低い中央値遅延が観察されました。これはQUICベースのトランスポートがTCP固有のメカニズムを回避するためと考えられます。バックグラウンド負荷の下でも同様の挙動が観察され、中央値遅延はTCPベースのSDCよりもわずかに低いものの、時折遅延ピークが発生しました。スケジュールされた測定では、以前の実験で最も堅牢であったファクター100スケジュールが使用されました。元のスケジュール、75 µs、またはファクター10スケジュールでは安定した接続を確立できませんでした。これは、SDCトラフィック用にスケジュールされた送信ウィンドウが減少したため、メッセージを他のトラフィック用に予約された時間ウィンドウにシフトできなかったことが原因と考えられます。

ファクター100スケジューリングと内部iPerfトラフィックを組み合わせた場合、最初は単一の外れ値を持つ高い遅延が観察されましたが、その後安定しました。これは接続確立中のシステム負荷による一時的なものかもしれませんが、正確な原因は不明です。外部iPerfトラフィックの場合も、単一の初期外れ値が発生した後、バックグラウンドトラフィックがない場合と同程度の遅延が維持されました。これは、メッセージ送信サイクルがGCLサイクルと一致する場合、バックグラウンド負荷の下でも安定した遅延を維持できることを示唆しています。

Figure 9
Figure 9. Fig. 9 Latency distributions for baseline measurement with and without load, factor-100 scheduling with internal and external iperf shown as boxplots for SDC over QUIC解説: この図は、SDC over QUICにおける遅延分布を、ベースライン(無負荷)、ベースライン(内部iPerf負荷)、内部iPerf負荷(ファクター100スケジューリング)、外部iPerf負荷(ファクター100スケジューリング)の各条件下でボックスプロットで比較したものです。ベースライン測定や負荷条件下でのファクター100スケジューリングにおいて、比較的低い遅延と安定した分布が維持されていることが示されています。

全体として、スケジュールされていないSDC通信は、不十分に寸法設定されたウィンドウを持つスケジュールよりも、ネットワーク負荷やタイミングずれに対してより耐性があることが示されました。スケジューリングは限定遅延挙動を改善できるものの、過度に厳格なスケジュールは堅牢性を低下させる可能性があり、評価された設定では、スケジュールされていない通信の方が一時的な負荷や位相ずれをより良く吸収できることが示唆されました。

結論と今後の展望

この研究は、SDCベースの医療機器ネットワークにおけるTSNの自動オフライン構成の実現可能性を示しました。MDIBから通信要件を導出し、TSNスケジュールを自動的に生成することで、初期設定後に介入をほとんど必要とせずにデバイスを構成できるようになり、安全な臨床展開にとって不可欠です。しかし、いくつかの限界も明らかになりました。スケジュール生成は現在、静的な処理時間の推定に依存しており、トポロジ情報は手動で提供されると仮定されているため、動的な臨床ネットワークでの適用は限定されます。また、スケジューリングに関連するSDC固有のいくつかのパラメータはMDIBで完全に指定されておらず、拡張が必要です。例えば、ストリームの許容ジッターや、ペイロードサイズを制限するために使用される文字列型指標の最大文字列長などが挙げられます。通信の安定性がウィンドウサイズに敏感であることが示されたため、SDCトラフィックのタイミング制約とスケジューリング要件については、さらなる調査が必要です。

小さな送信ウィンドウは無制限の遅延とメッセージ損失を引き起こし、より大きなウィンドウは時間的精度を犠牲にして堅牢性を向上させます。報告されたウィンドウサイズとスケーリングファクターは、評価された設定に対する経験的な観察であり、一般的に転用可能な設計ルールではありません。スケジュールが十分に寸法設定されている場合、負荷に依存しない遅延が測定で示されました。QUICベースのSDCライブラリはTCPと比較して中央値遅延をわずかに減少させましたが、スケジューリング下では、スケジュールされていない通信よりも遅延が高く維持されました。

全体として、SDCとTSNの組み合わせは、スケジュールが慎重に寸法設定され、システム特性に適合していれば、相互運用可能な医療機器ネットワークにおける伝送の予測可能性を向上させる有望なアプローチです。今後は、自動デバイス検出、集中型デバイスマネージャーを介した処理およびキューパラメータの動的な取得、実行時のスケジュール検証と適応に取り組むべきです。安全性が重要な医療アプリケーションのタイミング要件を満たし、遅延ピークを排除するためには、さらなる最適化と信頼性のある最悪ケース遅延境界の確立が必要です。より大規模なネットワークや、リアルタイム通信アンサンブルを形成する協調的なデバイスグループへのアプローチの拡張、およびより厳格なタイミング要件の評価も今後の課題となります。

用語集

  • SDC(Service-oriented Device Connectivity): ISO IEEE 11073に基づいて、医療機器間の相互運用性とベンダー非依存の通信を可能にする標準規格。
  • TSN(Time-Sensitive Networking): 標準イーサネットの拡張であり、時間同期と制御されたデータ伝送により、信頼性が高く時間決定的なデータ配信を実現する技術。
  • MDIB(Medical Device Information Base): SDCプロバイダーの中核コンポーネントで、医療機器の機能構造と動的挙動を記述する情報モデル。
  • GCL(Gate Control List): TSNにおいて、各時間スロットでどのトラフィッククラスの伝送が許可されるかを定義するリスト。
  • CNC(Centralized Network Controller): TSNネットワーク全体でGCLを計算し、TSN対応デバイスに展開する中央ネットワークコントローラー。
  • CUC(Centralized User Configuration): ネットワーク参加者とCNCの間に位置し、CNCがGCLを計算するための通信要件を提供する。
  • PTP(Precision Time Protocol): IEEE 1588で定義されたプロトコルで、すべてのネットワーク参加者間の正確な時間同期を実現する。
  • TAS(Time-Aware Shaper): IEEE 802.1Qbvで規定されたTSNのメカニズムの一つで、GCLに基づくスケジュールされた伝送を導入する。
  • QUIC: UDPベースの多重化された安全なトランスポートプロトコルで、転送遅延の低減を目指したもの。
powered by visionary imaging services, inc.
免責事項

発行 Beyond the Pixel 編集部(Visionary Imaging Services, Inc.)

編集責任者 小林 達明(診療放射線技師/博士(情報学)) ORCID

本記事は生成 AI を用いて作成しています。公開後に気づいた誤りは編集部が随時修正します。

論文の引用・解釈の方針は免責事項をご覧ください。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です