SILS 統合・接続設計根拠 (SILS System Integration & Connectivity Rationale)¶
[!NOTE] ドキュメントのスコープ 本資料は、シミュレータの物理運動モデル内部の計算構造ではなく、**「シミュレータと実際のフライトソフトウェアの接続（アルゴリズム移植性）」および「シミュレータと地上局の接続（インターフェース透過性）」**というシステムレベルの統合・接続設計の選定根拠をまとめたものです。
1. 一般論・基本原理の提示 (解空間の起源)¶
① フライトソフトウェア（FSW）とシミュレータの「ロジック対称性」¶
組み込み開発におけるアルゴリズム検証では、シミュレーション側のロジックと実機（Pico SDK / C++）側のロジックが乖離していると、検証の意味が失われます。これを防ぐ基本原則は、状態遷移ロジック（コントローラ）を完全に独立モジュール化し、異なるプラットフォーム（Python / C++）間で同じ状態決定フローをミラーリングすることです。
② 地上局連携における「インターフェース透過性 (Interface Transparency)」¶
地上局のサーバー・UIにとって、データの発生源が「実機（Pico W）」であるか「シミュレータ（SILS）」であるかは本来意識されるべきではありません。これを透過的に結ぶ手段として、共通のデータバス（メッセージブローカー）を中継し、同一のトピック名およびデータスキーマで抽象化する設計パターン（疎結合 Pub/Sub）を適用します。
2. 候補の列挙とトレードオフ分析¶
【SILS・地上局統合パス】候補の比較¶
候補A（内部モック呼び出し方式）: UIやバックエンド内部にシミュレーション用のモック関数を作り、ネットワーク通信を介さずに値をダミー更新する。
候補B（TCP 完全エミュレーション方式）: SILS側に Pico W と同様の TCP サーバーソケットを構築し、地上局接続用の
bridge.pyを経由して MQTT に中継する。候補C（直接 MQTT パブリッシュ方式） [採用]: SILSコントローラ自身が直接 MQTT クライアントを持ち、同一トピック・同一 JSON スキーマでブローカーに直接投げる。
評価項目 |
候補A (内部モック) |
候補B (TCPエミュレーション) |
候補C (直接 MQTT 接続) [採用] |
|---|---|---|---|
地上局側のコード共通化 |
低 (シミュレータ用の例外分岐が必要) |
高 (実機接続時と全く同じ) |
高 (実機接続時と全く同じ) |
ローカル環境構築の容易さ |
高 (ブローカーやブリッジの起動不要) |
低 (ポート重複や bridge.py 多重起動のリスク) |
高 (MQTTブローカー起動のみで動作) |
ネットワークの複雑度 |
極小 (通信なし) |
高 (TCPソケットとMQTTの2レイヤー) |
中 (MQTT 1レイヤーのみ) |
検証性の網羅範囲 |
低 (通信遅延やパケット処理が検証不可) |
高 (通信レイヤー含め検証可能) |
高 (シミュレータ透過性による結合検証可能) |
3. 意思決定と選定根拠 (Justifications)¶
① 実機なしでの結合開発スピード最大化 (検証性の確保)¶
根拠: 実機ハードウェアが完成していない段階でも、地上局ダッシュボードのグラフ描画やデータベース保存、ユーザーコマンドの処理フローを実戦的にテストするため、インターフェース透過性の高い「候補C」を採用しました。地上局側は通信相手が実機かSILSかを意識する必要がなく、実機納品後の接続テストをほぼ瞬時に完了できます。
② PCローカル開発での不必要なTCPソケットバグの「防御的回避」¶
根拠: 候補B（Pico W TCPサーバーの完全なエミュレーション）は、PCローカルで動作させる際にファイアウォールブロックやローカルポート（Port 80/81）の競合を招き、学生が「シミュレータが起動しない」という技術外の問題で立ち往生するリスクを高めます。SILSコントローラが直接 MQTT ブローカーにデータを流し込む構成にすることで、ネットワークスタックの複雑性をそぎ落とし、簡素で堅牢なテスト環境を提供します。
4. 合理的なブラックボックス化 (Rational Black-Boxing)¶
① MQTT メッセージブローカー（Mosquitto）およびクライアント（Paho）のブラックボックス化¶
SILSコントローラから MQTT ブローカーへの非同期パブリッシュやハートビートパケットの送受信、パケット再送制御などは、ライブラリ（
paho-mqtt）および中継サーバー（Mosquitto）の標準機能に全面的に依存し、その通信プロトコルの詳細についてはブラックボックスとして扱います。割り切りの根拠: 信頼できる通信ミドルウェアを使うことで、学生は「TCP通信のパケットドロップ制御」や「セッションキープアライブの再送タイムアウト」といった低レイヤー通信制御の泥沼に捕まることなく、姿勢制御の物理法則やコマンド駆動ロジックの動作検証に学習の時間を集中させることができます。
② 制御ロジックのPython-C++自動翻訳の排除¶
controller.pyからcontrol.cppへの自動トランスパイラ（コード変換器）などは導入せず、人間による「状態遷移マシンの手動ミラーリング」として割り切っています。理由: 変換ツールの保守コストやエラーハンドリングが、本ゼミの規模（状態数4、制御ループ1つ）に対して過剰（Over-engineering）であり、手作業でコードを移植する方が、C++とPythonの文法差分の理解にも繋がり教育効果が高いためです（YAGNI原則の適用）。