https://physicalaihub.net/tags/%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E8%A8%AD%E8%A8%88/ Recent content in インターフェース設計 on Physical AI Hub Hugo ja-jp Sat, 07 Nov 2026 14:46:34 +0900 https://physicalaihub.net/posts/physical-ai-interface-compatibility-management/ Sat, 07 Nov 2026 14:46:34 +0900 https://physicalaihub.net/posts/physical-ai-interface-compatibility-management/ <p>ロボットの長期運用では、型が一致しているだけで安全に接続できるとは限りません。</p> <h2 id="先に結論">先に結論</h2> <p>ロボットを長期間保守するには、インターフェースをデータ型だけでなく、データの意味、単位、座標系、時刻、品質、通信条件、モデル入出力、変更手順まで含む契約として管理します。センサー、認識、計画、制御の各境界で契約を分け、互換性を層別に判定することが基本です。</p> <p>実装では、バージョン付きスキーマ、旧版と新版の並行運用、変換アダプター、契約テスト、実データのリプレイを組み合わせます。コンパイルが成功しても、単位や座標系の変更、QoSの不一致、モデル前処理の差、制御系の遅延増加までは検出できません。</p> <h2 id="なぜ互換性管理が難しいのか">なぜ互換性管理が難しいのか</h2> <p>Physical AIの処理系は、センサー、通信ミドルウェア、推論モデル、計画器、制御器、アクチュエーターが連鎖しています。一つの変更が複数チームと実行環境に波及するため、「フィールドが同じ型か」だけでは判断できません。</p> <p>数値型が同じでも、単位がメートルからミリメートルに変われば値の意味は変わります。座標フレームが変われば、受信側は同じ数値を別の位置として解釈します。計測時刻と受信時刻の混同、欠測値と有効性フラグの扱いの違いも、型互換でありながら機能を壊す要因です。</p> <h2 id="管理すべき契約">管理すべき契約</h2> <p>ROS 2には<code>msg</code>、<code>srv</code>、<code>action</code>があり、定義から複数言語向けの型と関連コードが生成されます。ただし通信の可否は型だけでなくQoSにも依存します。reliability、durability、history、depth、deadline、lifespanなどの設定がPublisherとSubscriberの間で互換しなければ、通信が成立しない場合があります。</p> <p>DDS-XTypesは、型の拡張性、メンバーの識別、型の割り当て可能性などを扱います。しかし、実際の利用可能範囲は、ROS 2の型サポート、RMW実装、DDSミドルウェア、設定に依存します。仕様上可能な拡張を、そのまま対象環境へ適用できるとは限りません。</p> <p>データ契約には、少なくとも次を記録します。</p> <ul> <li>フィールド名、型、必須性、既定値</li> <li>単位、値の範囲、精度</li> <li>座標系、フレーム名、軸の向き、回転表現</li> <li>計測時刻、生成時刻、受信時刻など時刻の意味</li> <li>共分散、有効性、欠測、品質の表現</li> <li>QoS、許容遅延、deadlineなどの通信条件</li> <li>モデルの入力・出力テンソルの型、形状、前処理、後処理</li> <li>変更理由、サポート期間、廃止予定日</li> </ul> <p>単位や座標の規約には<a href="https://www.ros.org/reps/rep-0103.html" target="_blank" rel="noopener nofollow">REP-103</a> 、モバイルロボットのフレーム関係には<a href="https://www.ros.org/reps/rep-0105.html" target="_blank" rel="noopener nofollow">REP-105</a> を参照できます。</p> <h2 id="推論モデルもインターフェースである">推論モデルもインターフェースである</h2> <p>モデルファイルのバージョンだけでは不十分です。ONNXでは、モデル形式のIRバージョン、演算子セットのバージョン、演算子仕様の変更を区別しています。入力テンソルの形状・型に加え、前処理、量子化、キャリブレーション、後処理も契約として記録します。</p> <p>テンソル形状や演算子セットが互換でも、前処理や学習データの変更による認識精度、さらに制御性能の維持までは仕様書から保証できません。モデル形式の互換性と、モデルを利用した機能の性能維持は別に検証します。</p> <figure class="mermaid-figure"> <pre class="mermaid" role="img" aria-label="センサーからアクチュエーターまで、データの意味、通信条件、モデル入出力、制御条件を連続したインターフェース契約として管理する流れを示します。">flowchart LR S["センサー"] --> SC["センサー契約\n意味・単位\n座標系・時刻\n品質・バージョン"] SC --> M["ROS 2 msg / srv / action\n型・必須性・既定値"] M --> QC["通信契約\nQoS・転送条件\n遅延・deadline・lifespan"] QC --> I["認識モデル\n入力・出力テンソル\n形状・型・前処理・後処理"] I --> PC["計画・制御契約\nコマンド・制約\n許容遅延・欠測・ジッター"] PC --> A["アクチュエーター"] A --> F["フィードバック\n計測値・時刻・品質"] F -. "契約テスト・リプレイ・影響追跡" .-> SC B1["各境界で管理する項目\nスキーマ\n座標系\n時刻\n品質\nバージョン"] -. "境界横断の契約" .-> M B1 -. "境界横断の契約" .-> I B1 -. "境界横断の契約" .-> PC</pre><figcaption>センサーからアクチュエーターまで、データの意味、通信条件、モデル入出力、制御条件を連続したインターフェース契約として管理する流れを示します。</figcaption></figure><p>センサーの意味・単位からROS 2の型、QoSと転送、モデル入出力、計画・制御コマンド、アクチュエーターのフィードバックまでを連続した契約として捉えます。各境界にスキーマ、座標系、時刻、品質、バージョンを置くと、変更箇所と影響範囲を追跡しやすくなります。</p>