テレコマシステム設計根拠 (Telemetry & Command System Design Rationale)¶

[!NOTE] ドキュメントのスコープについて 本資料は、模擬衛星の物理的・機械的構造やミッション全体に関するものではなく、衛星・地上局間の**「テレメトリ（データ送信）およびコマンド（指令送信）の通信経路・データ処理アーキテクチャ（テレコマシステム）」**の選定根拠に限定したものです。

1. テレコマシステムにおける3つの一般アーキテクチャ（解空間）¶

分散システムやネットワーク通信、あるいは宇宙開発における地上運用システムにおいては、データ送信（テレメトリ）と指令送信（コマンド）を構築する手段として、一般的に以下の3つの基本設計パターンが存在します。

これらは、汎用的なソフトウェア工学、産業用遠隔監視制御システム（SCADA）、ロボットミドルウェア（ROS）、および宇宙データシステム標準（CCSDS）などの歴史と実例に基づいています。

flowchart TD
    subgraph P1["パターン1: 点対点・同期接続 (Point-to-Point)"]
        direction LR
        Sat1[衛星] <--- "直結ソケット\n(密結合)" ---> Console[専用地上端末]
    end
    
    subgraph P2["パターン2: クライアント・サーバー・ポーリング (Request-Response)"]
        direction LR
        Sat2[衛星 (サーバー)] <=== "定期GET/POST\n(同期リクエスト)" === Ground2[地上局ブラウザ (クライアント)]
    end
    
    subgraph P3["パターン3: イベント駆動型 Pub/Sub (Broker-driven)"]
        direction LR
        Sat3[衛星 (Publisher)] -- "Telemetry (QoS0)" --> Broker[メッセージブローカー\n(MQTT)]
        Ground3[地上局 (Subscriber)] -- "Command (QoS1)" --> Broker
        Broker -- "コマンド配信" --> Sat3
        Broker -- "テレメトリ配信" --> Ground3
    end

パターン1：点対点・同期接続モデル (Point-to-Point Sync)¶

一般論・類似システム: 送信元と送信先を物理的または論理的な単一ソケット（RS-232Cシリアル、Raw TCP/UDPなど）で直接つなぐ最もシンプルな構造です。宇宙開発の黎明期における「1つの専用パラボラアンテナと1つの専用表示端末を直結した運用システム」や、シリアルポート通信によるデバッグモニターがこれに該当します。
特徴: プロトコルのオーバーヘッドがなく高速ですが、1対1の接続に強く縛られます（密結合）。他のプロセス（シミュレータやロギングDB）を横から割り込ませることが極めて困難です。

パターン2：クライアント・サーバー・ポーリングモデル (Request-Response / Pull)¶

一般論・類似システム: 現代のWebシステム（REST API、HTTP/HTTPS）で最も広く普及しているアーキテクチャです。クライアントが「要求（Request）」を出し、サーバーが「応答（Response）」を返します。宇宙開発においては、地上局の保守用コマンドインターフェースや、Webベースの地上機器診断ツールなどで採用されています。
特徴: ステートレスでデバッグが容易ですが、データの流れが常に「クライアント（地上）起点」になります。高頻度なテレメトリ（10Hz〜100Hz）を受信する場合、無駄なHTTPハンドシェイクによる帯域消費とマイコン側の処理負荷（パース処理）が致命的なボトルネックになります。

パターン3：イベント駆動型 Pub/Sub モデル (Decoupled Messaging / Push)¶

一般論・類似システム: データの配信元（Publisher）と受信先（Subscriber）の間に仲介者（Broker）を置き、トピック（チャネル）を介してデータを非同期で流すアーキテクチャです。 IoT向けの MQTT、産業用遠隔監視（SCADA）システムの通信規格（OPC UA等）、ロボット開発で広く使われる ROS (Robot Operating System) のトピック通信、および宇宙開発における分散地上局ネットワーク（CCSDS SLEや複数の地上局を経由するパケットルーティング）がこのモデルを採用しています。
特徴: 送信側と受信側がお互いのIPアドレスや状態を知る必要がない（疎結合）ため、システムの変更やシミュレータの差し替えが容易で、ネットワーク切断（リンク切れ）に対する耐性も高いのが特徴です。

2. 制約条件と要求の分析¶

本プロジェクトの模擬衛星運用においては、以下の要件を満たす必要がありました。

高頻度更新とマイコン負荷軽減の両立: 姿勢制御データ（10Hz以上）を、Pico Wの貧弱なWi-Fiバッファ（CYW43チップ）やCPUを圧迫せずに送信する。
シミュレーション（SILS）環境との互換性: 実機とシミュレータ（Python実装）を切り替える際、地上局のプログラムを一切修正しないこと。
複数クライアントへの拡張性: データベース（ロギング）とWebダッシュボード（リアルタイム描画）に同時に同じデータを配信する。

3. 各パターンのトレードオフ評価¶

上記の要求に基づき、3つの一般パターンをゼミ内で想定される実装レベルへ具体化し、トレードオフを分析しました。

候補A（パターン1ベース）: PythonのTkinter GUIで、衛星のTCPソケットに直接つないで読み書きする構成。
候補B（パターン2ベース）: 衛星で簡易HTTPサーバーを動かし、Reactから毎秒20回ポーリングする構成。
候補C（パターン3ベース）: MQTT（Mosquitto）を介し、FastAPIバックエンドとReactフロントエンドを分離する構成。

トレードオフ比較マトリクス (Trade-off Matrix)¶

比較項目	候補A (モノリシックTCP)	候補B (HTTPポーリング)	候補C (MQTT Pub/Sub) [採用]
Pico W 側の処理負荷	低 (単一ソケット処理のみ)	極めて高 (毎リクエストのHTTP解析)	低 (ヘッダが数バイトのMQTT)
耐障害性 (UIクラッシュ時)	低 (通信スレッドごと停止)	中 (再接続ポーリングは可能)	極めて高 (ブローカーがバッファ・DB保存は継続)
データロギング容易性	低 (UIコード内にDB保存を書く)	中 (APIサーバーでポーリング)	高 (DB用のSubscriberを追加するだけ)
SILS/実機切り替えの容易さ	低 (通信処理をモジュール化して差替)	低 (エンドポイント設計変更)	極めて高 (同一トピックに投げるだけ)
類似プロ宇宙システムとの親和	中 (旧来の個別シリアル的)	低 (WebAPI専用)	高 (ROS/CCSDSに類似した非同期パケット流動)

4. 意思決定の根拠 (Justification)¶

比較検討の結果、**「候補C (MQTT Event-Driven Pub/Sub)」**が本テレコマシステムに最も適していると判断しました。

① 実機・シミュレータの透過的切り替え (Simulated-to-Flight Transparency)¶

根拠: MQTTブローカーを中央に置くことで、地上局はデータの送信元が「実機衛星のPico W」なのか「PC内のPythonシミュレータ」なのかを意識する必要がありません。トピック sat/telemetry にパブリッシュされていれば、全く同じコードで動作します。これは、実機がまだ完成していない段階でも、地上局とシミュレータだけで「地上システム結合テスト」を完璧に進めることができるという多大なメリットをもたらします。

② 関心の分離による堅牢性 (Separation of Concerns)¶

根拠: 地上局のUI（React）が描画処理でどれだけ重くなったり、あるいはクラッシュしたりしても、データの永続化（FastAPI ➡ InfluxDB）やパケット中継（Mosquitto）には一切影響を与えません。通信リンクを維持する責務と、人間へ可視化する責務を分けることで、ミッションデータの一貫性を保証できます。

③ 移行コストの割り切り (Rational Black-Boxing)¶

根拠: マイコン（Pico W C++）側で直接 lwIP MQTT の複雑な非同期APIを記述することは、事前学習期間の制約からゼミ生にとって開発コストが大きすぎます。そのため、現在は**「衛星 ➡ (TCP) ➡ bridge.py ➡ (MQTT) ➡ ブローカー」**という中継構成（Phase 1.5）をとっています。中継の境界（bridge.py）を設けることで、Pico W側はシンプルの極みであるTCPソケット通信に閉じ（ブラックボックス化）、地上局全体はモダンなPub/Subシステムとして統合する、合理的なバランスをとっています。