人工衛星の開発体験向上のために、ソフトウェアからできること

夏のプログラミング・シンポジウム2024の発表で使用したスライドです。
https://prosym.org/sprosym2024/

Transcript

1. 人工衛星の開発体験向上のために ソフトウェアからできること 2024/09/21 ArkEdge Space Inc. sksat
2. 自己紹介 ・sksat（えすけーさっと） ・ArkEdge Space Inc. コンピューティング基盤部　/　筑波大学情報学群情報科学類（休学中） ・宇宙オタク -> パソコンオタク -> 宇宙パソコン野郎 ・やってた: OS、x86エミュレータ、数値計算、小型ハイブリッドロケット、自宅サーバ ・やってる: （人工衛星の）OS/Framework、シミュレーション基盤、CI/CD、姿勢制御系、社内システム、... ・気持ちがあるところ: 実在する複雑性の咀嚼と妥当な対処の案組み ・セキュリティ・キャンプ全国大会2024　開発コース　探査機自作ゼミ講師 ↖これ中指じゃないです
3. スペース × プログラミング 今回のプロシンのテーマ
4. スペース × プログラミング 今回のプロシンのテーマ にデプロイする
5. その前に
6. 宇宙開発って 遠い世界のことだと 思っていませんか
7. Q. そもそも宇宙ってどこから？
8. 宇宙 ・海抜高度 100km より上を「宇宙」と呼んでいる ・カーマン・ライン：国際航空連盟（FAI）が使っている基準 ・割と人間の気分の問題なので、別の基準もある ・アメリカ軍は50海里（92.6km） ・国際宇宙ステーション（ISS）は 400km ぐらい
9. そんなに遠くないじゃん ・つくば～ここ（九段下）が 60km くらい ・つくばエクスプレス／車なら1時間 ・東京～大阪が 500km くらい ・「宇宙よりも遠い場所」
10. 宇宙への行き方（？） 1. 新幹線が上方向に開通するのを待つ 2. 出張申請する 3. スマートEXで予約する 4. 乗る
11. だったらラクなんですが
12. 話はそんなに単純ではない
13. 宇宙にとどまるのが大変 ・周知の事実：モノを上に投げたら落ちてくる ・人工衛星は宇宙空間に到達して終わりではない ・横方向に秒速 8km くらいでぶん投げる → 落ち続けて地面にぶつからなくなる ・本当に必要なのは速度 ・回り続けているところ：軌道 　　ex：地球低軌道、太陽同期軌道、静止軌道、... 8km / sec
14. ロケット ・高速にぶん投げる手段：ロケット 　　・軌道へのデプロイ手段 ・ある程度高度を稼いだら横に速度を稼ぐ ・ガスを押し出して反作用で進む ・一番上の部分に人工衛星を入れる ・質量の9割以上が推進剤（燃料 + 酸化剤） 　　・酸素も持っていかないと燃焼できない Image credit: NASA
15. ロケットは輸送業者 ・「宇宙輸送」というカテゴリ ・ロケット自体もとても難しい分野 　　・契約しても実際届くかは少しドキドキ ・ユーザーズマニュアルもある ・輸送料金は超高い（人件費レベル） 普通の輸送サービスのような キャッチコピーが書いてある MHIウェブサイトより引用
16. 輸送料金高すぎ問題 ・元々宇宙開発全体が国家プロジェクトだった ・量産されてないがち（ロケットも一品物） ・ロケットの開発が大変すぎる ・開発費の回収も大変 ・１本買い切るのは超高い 　 →小さい人工衛星を作ってシェアする Image credit: SpaceX
17. ひとつの解：超小型人工衛星 ・小さく／安く／速く作る ・1U：10cm x 10cm x 10cm ・打ち上げコストを1/100程度に 10cm 20cm 30cm 30cm ©NASA
18. じゃあどんどん人工衛星作って デプロイしていくか
19. じゃあどんどん人工衛星作って デプロイしていくか ArkEdge がやりたいこと
20. でも、やっぱり宇宙は大変
21. 宇宙の何が大変のか ・大気が無い ・地面が無い ・軌道上にコンセントが無い
22. 大気が無い問題 ・様々な「いつものヤツ」は大気圧がかかってる前提で作られている ・最悪爆ぜる ・ex：電解コンデンサ ・排熱が大変（空冷できない！！！！！） ・オゾン層や地磁気による保護も無い ・宇宙放射線浴び放題 画像： 情報通信研究機構『宇宙天気現象の発生と、社会への影響』
23. 地面が無い問題 ・立てない ・無の中に浮いてるのでその場でバタバタしても進まないし向きも変わらない ・ナニカを噴く（反作用で頑張る）か角運動量保存則で頑張るしかない ・そもそも今どっち向いてるの？（「姿勢決定」） ？
24. コンセント無い問題 ・太陽光発電でなんとか...... ・確保できる面積で発電量が変わる ・いつもの x86_64 CPU や GPU を載せてドーン、はできない ・能動的に太陽方向に姿勢を変えないと文鎮になる ？ 死
25. 宇宙開発は総合格闘技 ・関連する技術領域だけでもすごく広い ・機構設計、熱設計、電力設計、姿勢制御、無線通信、...... ・SW だけでも広い：数値計算、言語処理系、OS、プロトコルスタック、組み込み、...... ・政治レイヤや業界全体の課題もある ・あるある ・あちらを立てればこちらが立たず ・全体を俯瞰できない！！！（結局何をなんのためにどう作ってるんだっけ？）
26. １機を作るのも結構大変 vs どんどん作って打ち上げたい
27. 「プログラミング」の時間です
28. 「プログラミング」の時間です うまくモデリングし、扱いやすくする営み
29. 「プログラミング」したいもの：「人工衛星の作り方」 ・これまで：どうせ大変だし高額なので、めっちゃ頑張って一発勝負 ・我々：色々な人工衛星をたくさん作りたい（他種類／複数機） ・開発コストを劣線形にしていかないといけない
30. 「開発コスト」とは？ ・モノにかかっているコスト ・ヒトにかかっているコスト
31. 「開発コスト」とは？ ・モノにかかっているコスト ・ヒトにかかっているコスト ← 今日の話
32. 「開発コスト」とは？ ・モノにかかっているコスト ・ヒトにかかっているコスト ← 今日の話 開発体験が悪い
33. どんどん人工衛星を作るには 開発体験をどうにかしなければ
34. 人工衛星の開発体験における課題 １．認知負荷が大きすぎる ２．調整が多すぎる ３．組み込みソフトウェア開発環境が渋い ４．検証／試験が面倒
35. 課題１：認知負荷が大きすぎる ・そもそもやってる領域が広すぎる vs その割に相互に影響する →全体が俯瞰できない！！！ → 素直に分割統治できない！！！ ・関係者が多い：色々な分野の専門家、色々な組織（ロケット屋さん、ミッション屋さん、...） ・技術的な課題もある ・なんだかんだ毎回結構違うモノ作って工数爆発しない？（HW／SW 両方） ・C/C++ の既存資産：パッケージマネージャが無い、抽象化の手札不足
36. ポリシー：すべてのソフトウェアを更新可能にする ・実機に載せる SW（FSW）は組み込みだしデプロイしたら直しにいけない（非修理系） ・一回書き込んで打ち上げたらそれで終わり？ → HW 開発／打ち上げに SW 開発が律速されてしまう ・FSW もデプロイ（物理）後にどんどん書き換えられなければならない ・ただ、文鎮になるのは困る → ブートローダや最低限の生存のための検証は堅牢に
37. 全体の設計レベルでの思い切った分割 ・専門（責務）ごとにコンピュータ（OBC）を分ける ・チームの界面が OBC 間の通信仕様になる ・OS やプロトコルは統一（フレームワークを提供） ・組織と合わせて設計する必要がある（コンウェイの法則）
38. 雑に「冗長化」に逃げない ・宇宙開発「冗長化」好きすぎ問題 → 同じような責務のモノが２倍になったら複雑性は２倍以上！！！ ・超小型衛星だと体積・質量・電力的にも余裕が無い ・そもそも「冗長化」して買っているのは何？ ・意外とただの安心なことも ・要求を整理する（ex：そもそも 24h/365day available な必要あるのか？） ・みなさん大好きメモリ化け ・データの大事さとのトレードオフ ・仕組みを正しく理解してやらないと意味が薄い
39. 課題２：調整が多すぎる ・多分野の専門知識が要る ・関わる人も組織も多い →油断するとカレンダーが会議で埋まる ・分野が離れていると共通言語が無い ・略語が被りまくる！！！！！ ・お互いの領域への理解が浅すぎると調整の意味も薄い こういうことになりかねない 「この無線機は CSS を使ってて～」 「え、ブラウザ載ってるんですか！？」 「？？？？？」 （電波の変調方式の一種）
40. SWE 以外もコードを書きやすくする ・「プログラミング」をするのは SWE だけではない ・事前のシミュレーションや、成立性の確認のためのスクリプト ・毎回乱雑な Python スクリプトがあちこちでできる → rye/uv の導入（開発環境の整備） ・それぞれの専門分野関連のコードをその人本人が書ければ調整が減る ・姿勢制御、熱制御、電源制御、... ・うまく本質部分を抽象化できるシステムソフトウェア／ミドルウェアが重要
41. 調整 as Code ・TlmCmdDB ・人工衛星との通信プロトコルのスキーマ定義 ・CSV／JSON からコード生成／定義読み込み ・各種設定や設計情報も JSON で記述 ・別の職能／部署／組織との界面をコード化 ・調整が会議からコードレビューになる → ◎再現性　◎非同期コミュニケーション
42. 課題３：組み込み開発環境が渋い ・マイコンベンダ固有の謎の IDE がありがち ・Windows 依存だったり、容易に「このマシンでしかビルドできない」が発生しがち ・公式のドライバの質もあんまり高いとは言えないがち → 素性の分かっている自由なソフトウェアで開発したい！！！ ・基本的にC言語のみ ・パッケージマネージャが無い！！！（Git submodule......？） ・抽象化の手札が非常に限られる（そして迫り来る void*） ・そこに無ければ何もない（printf？無ければ実装しましょう）
43. （組み込みを含む）全面的な Rust の採用 ・2024年現在最も開発体験のよい言語のひとつ ・rustup で環境構築、LLVM で多種アーキテクチャ向けに簡単にビルド、core 標準ライブラリ ・cargo doc によるドキュメント自動生成 ・OS のような低レイヤ～Webバックエンドまで書ける → 組み込み開発からシミュレータ、地上局、開発ツール、社内システム全部書ける ・Embedded Rust コミュニティも結構活発
44. 2024年の組み込み（Rust）開発体験 ・VSCode + probe-rs が最強 ・F5 で書き込んで普通に breakpoint 打てる ・設定も Git 管理できる（全員が同じ開発体験） ・defmt で簡単にログ出力 ・core 標準ライブラリ／no_std で動く crate も充実 ・Raspberry Pi Pico で治具を作りまくる ・デバッガ（rust-dap）、実機の自動テスト
45. C と Rust の相互運用 ・なんだかんだC言語の既存資産がある ・いきなり全部 Rust はそれはそれで無理がある ・bindgen が超便利 ・doxygen-rs を使ってC言語側のコメントを rustdoc に持ち込む ・既存の概念（ハードウェア抽象化レイヤ）を trait などで抽象化 → FFI 部分を proc macro で自動実装 ・Web 系の概念／実装を持ち込む ex：Cの既存実装と WebSocket で喋れるように
46. Cargo を任意パッケージマネージャとして使う ・C/C++ はマトモなパッケージマネージャが無くてつらすぎる ・資産の再利用があまりにもやりにくい ・Cargo はパッケージマネージャとして非常に優秀 ・0 byte の lib.rs を生やせば C だけのライブラリもパッケージングできる ・build.rs で自由にビルドロジック書き放題 ・あらゆるモノが git clone & cargo run できるようになる ・開発開始のコストを減らす／オンボーディングをシンプルに
47. 開発者のためのツール開発 ・運用／試験時にやりたいこと != 開発時にやりたいこと ・開発時にはすぐ使えるシンプルなツールが欲しい ・Zenn：リアルタイム通信用のコネクションをタブ間で共有してます ・バックエンドや DSL は地上局システムと共通化
48. 課題４：検証／試験が面倒 ・地上に宇宙環境は無い（残念！！！！！） ・地上で完全な E2E テストができない ・長期的：とりあえず打ち上げて試してみようぜ ・それだけだと開発が打ち上げに律速される ・最低限の制御もできないと即文鎮になって終わる（何も得られない） ・ある程度の試験はできる：振動試験、熱真空試験、放射線試験、... ・姿勢決定／姿勢制御はどうする？
49. 宇宙環境のシミュレーション ・物理的なモデルを作って数値計算 ・宇宙環境シミュレータの中で FSW を動かしてしまう（SILS：Software in the Loop Simulation） シミュレータ「俺が宇宙だ！」 FSW「人工衛星を制御するぞ......！」 センサの模擬 アクチュエータ の模擬
50. 検証／試験のグラデーションを整理する ・素朴にやると安心のために可能な限り大きな E2E テストが発生しがち ・プロトコルスタックの開発してるのに宇宙環境シミュレータを走らせる ・組み上げた後に長大な試験（細かい問題あったらまたバラすの？） ・結局何を「検証」したいのか？
51. 搭載ソフトウェア on PC ・毎回実機に書いてデバッグ／試験する必要は無い ・下のレイヤを模擬して x86 / arm 向けにクロスビルド ・模擬も目的によっては適宜雑なものでよい ・ex：姿勢制御以外は宇宙環境もサボれる ・ハードウェア無しで開発開始できる ・コンテナに固めてしまえば AWS にもデプロイできる → 運用の訓練などにも使える
52. HW 接続の仮想化 ・kble：Virtual Harness Toolkit ・色々なストリームの接続（UART など）を WebSocket に引き出す ・物理的な接続より上のレイヤ（フレーミング後など）での接続も可能 通常（実機など） 仮想化（PC上） 衛星内の接続も模擬
53. HW 試験のためのプラットフォーム ・色々な試験を各々がやっていると何がなんだかわからない ・HW 試験を行うための社内サービスを開発 ・バックエンド: Rust / AWS ・フロントエンド: Typescript ・試験手順／記録の一元化 ・試験のための仕組み作りと試験そのものを疎結合に（技術的にも、組織的にも）
54. 各種ソフトウェアの OSS 化 ・c2a-core：FSW フレームワーク ・Gaia：地上局システムのコア部分（試験システムや開発者向けツールもこれをベースにしている） ・kble：ハードウェア接続の仮想化ツール ・宇宙環境シミュレータも東大研究室から公開・開発協力：s2e-core ・各種フレームワークの公開 → 業界の SW 力向上／共通言語化を目指す → さらなる調整の省略
55. まとめ ・宇宙開発は遠い世界の話ではない ・宇宙開発は要件が特殊でおもしろい ・宇宙開発は総合格闘技 ・どんどん人工衛星を作って打ち上げたい → だからこそ開発体験の向上が非常に重要 → 開発体験の向上に Rust が超便利（組み込み開発含む）