同時複数機開発・運用のDevOpsサイクル高速化のための取り組み

第69回宇宙科学技術連合講演会 11/25（1日目）
OS-39 超小型衛星で切り開くビジネスと将来展望 （1）1A05 にて発表した、
『同時複数機開発・運用のDevOpsサイクル高速化のための取り組み 』のスライドです。

Transcript

1. 同時複数機開発・運用の DevOps サイクル 高速化のための取り組み 株式会社アークエッジ・スペース 坂本優太、鈴木聡宏、杉本健太朗、石原拓哉、細谷知之 第69回宇宙科学技術連合講演会 OS-39 超小型衛星で切り開くビジネスと将来展望 (1) 1A05
2. 開発チームと運用チームの（よくある）分断 2 画像出典: AWS re:Invent 2019 [REPEAT 1] Amazon's approach to building resilient services (DOP342-R1) Dev |壁| Ops フィードバックループが回らない DevOps フィードバックループが高速に回る
3. 運用チーム 開発チーム 例：FDIR の改善ループ（ナイーブな方法） 衛星A での Fault 衛星A の開発 Fault の 引き継ぎ文書 衛星A の 運用手順書 衛星A の運用 衛星B の開発 3
4. エンジニアリングチーム 例：FDIR の改善ループ（Dev + Ops のチーム統合） 衛星A での Fault 衛星A の開発 衛星A の運用 衛星B の開発 4
5. エンジニアリングチーム 軌道上再構築能力による FSW の継続的デリバリー 衛星A での Fault 衛星A の開発 衛星A の運用 衛星B の開発 5 軌道上再構築能力 （継続的デリバリー）
6. 人工衛星における DevOps 実践の課題 • 人工衛星をゼロから作るのは（やはり）とても大変 ◦ 試行回数の少ないクローズなカルチャーでは使いやすいパターンがない • プロダクト指向ではなくスケジュール指向になりやすい ◦ 「＊＊試験」「基本設計」などの「フェーズ」からのブレークダウン ◦ ハードウェアのリードタイム >>> ソフトウェアのリードタイム • 1イテレーション = 1ハードウェア = 1打ち上げになりやすい 地上の技術を活用した 作りやすい6U汎用バス 同時に複数機の 開発と運用 ソフトウェアを重視し 柔軟性を確保 アークエッジ・スペースでの 解決手法 6
7. 同時複数機開発・運用 • タイムラインが長い → 1イテレーションにかかる時間が長い ◦ 「次」をやるときには最初の痛みを忘却・前提が時代遅れに • 同時複数機開発・運用 ◦ 6U汎用衛星バスによる1イテレーションの短期化 ◦ イテレーションを越えたフィードバック 7 今回は AOCS（姿勢・軌道制御系）チームでの事例を紹介
8. AOCS チームにおける DevOps の事例 • チームとして AOCS 系の開発と運用の両方に責任を持つ ◦ 運用で起きた問題を目の前の衛星開発に即座にフィードバック ◦ 今後の開発上の課題を運用の中やメインの運用のついでに検証 • 6U汎用バスを採用した衛星の同時複数機運用 ◦ 運用手法の改善・障害対応方法の高速な横展開 • Rust を地上でもフライトソフトウェアでも活用 8
9. 作りやすい AOCS 系 OBC の開発 第68回宇宙科学技術連合講演会 1N03（2024） 『地上のコンピュータ技術を応用した高性能で作りやすいDH系の設計』 の DH 系 OBC をベースに新たに AOCS 系 OBC を開発中 9 Rust のエコシステムを用いた FSW 開発 →1チームが地上システムと FSW の両方を開発しやすくなる
10. 試験専用のソフトウェア 不足分開発 試験Bのための不足分開発 搭載ソフトウェア抽象のパターン化による 「試験」と FSW 開発の分離 10 FSW開発（すべてを作る） OBC 開発 HAL (Hardware Abstraction Layer) c2a-core App Component Driver • 「試験のためのソフトウェア」を作る ◦ 不必要／価値の薄い「共通化」をしない • その過程でコンポーネントのライブラリを開発 HAL (Hardware Abstraction Layer) Component Driver Lib 試験用インターフェース 試験対象が（OBC ではなく） コンポーネントであれば 別のマイコン／OBC でもよい 開発過程で育ったライブラリを 「試験」のタイミングとは 独立に移植 試験A 試験B 出荷
11. contact-watcher によるテレメトリ自動監視 • アークエッジ・スペースにおける衛星運用の pain： ◦ 衛星機数・地上局の増加によるコンタクト数の急増 ◦ 膨大なテレメトリ（2万フィールド／1衛星）の監視 • コンタクトの度に起動し、テレメトリを自動監視 ◦ 可視中のテレメトリ変動の監視 ◦ 直近の非可視中のテレメトリデータも込みでの解析・アラート発火 • Rust を EDSL としたプラグイン機構 ◦ 複雑な監視ロジックを実装可能 ◦ Claude Code などの LLM を活用したプラグイン開発 ◦ テレメトリ監視のためのノウハウ as Code 11 contact-watcher（コア部分） プラグインとして 様々な監視ロジックを柔軟に実装 時系列 DB（テレメトリデータ）
12. • DevOps サイクルを回したい vs 全部を1チームでやるのは大変 ◦ プラットフォーム（チーム）を作ることで分業 ◦ チームとプロダクトの界面を API として定義する OBC 開発チーム プラットフォームを作ることでラクにする 12 API: HAL (Hardware Abstraction Layer) FSW 開発/運用チーム FSW OBC Aegs チーム AOCS チーム テレメトリ監視ロジック contact-watcher OBC ランタイム API: EDSL Aegs API: 時系列 DB
13. 同時複数機開発・運用の DevOps サイクル高速化のための取り組み • DevOps というアプローチは衛星システム全体においても有効 ◦ そのための手段としての同時複数機開発・運用 • 同じチームが運用をしながら開発する（C&DH、AOCS、etc） • DevOps のサイクルをより高速に回すために： ◦ 積極的に抽象化してプラットフォームを作り開発をラクにする ◦ 地上とフライトソフトウェア両方での Rust の活用 ◦ 開発チームの視点で開発と運用をラクにするための仕組み作り 13
14. 継続的・加速度的成長のためのフィードバックループ 14 画像出典: AWS re:Invent 2019 [REPEAT 1] Amazon's approach to building resilient services (DOP342-R1)