事象発生日:2022-12-09
記事公開日:2022-12-12
アクセス数:3471
寝言 Part 2 です.
どこでだってソフトウェアはアップデートしたいよ.
したいね.
最近,ある宇宙特集を読んでいて,「人工衛星を打ち上げてしまうと,搭載ソフトウェアは修正できないので~」という記述に出くわし,「またか......」となってしまったので,下のものに引き続き,寝言 Part 2 です.
注) 本書での「ソフトウェアアップデート」とは,アプリケーションレイヤのアップデートではなく,OS レベルでのソフトウェア全体のアップデートのことです.
IoT 家電なども,もし販売後にアップデートを実行したことでエラーが発生し起動不能になったとすると,販売した何万台ものデバイスが文鎮化するわけで,かなり気を遣うはずです.
それなのに,「組み込みだから~」とか「リスクが~」とか「人の手が届かないから~」とか,様々な理由をつけてソフトウェアのアップデート可能性を初めからなくすのは,ソフトウェアの強みをみすみすと潰しているようなものだと思います.
確かに通信の問題やリスクの観点なども考慮すべきではありますが,いつでも "ソフトウェアアップデート" という決断が選択肢に並ぶように,軌道上でソフトウェアをアップデートできるようにしておくべきです.
家電メーカーからしてみたら,販売済みの家電だって(衛星と同じく) "手の届かない" 端末ですよ.
修士 1 年の頃に僕が開発した超小型深宇宙探査機 EQUULEUS のブートローダーの実装の説明が,学会予稿 に掲載されています.
この予稿から EQUULEUS のメインコンピューターボード (Main OBC) で使われているマイコンの型番が読み取れますが,ご覧の通りこのマイコンにはブート・スワップ機能などソフトウェア全体のアップデートを支援するような機能はなく,通常の利用では軌道上でのソフトウェアアップデート(部分的な修正ではなく,全体を書き換えるアップデート)は(実用上は)不可能です.
学部 4 年で研究室に配属された頃にはすでに衛星の EM (Engineering Model) 設計は終わっていたためマイコン選定の詳細な経緯は知りませんが,きっと軌道上でのソフトウェアアップデートは要件にはいっていなかったのでしょう.
実装したブートローダーのブートシーケンス図を下に引用しておきます.
このブートローダーは,もちろんソフトウェアアップデート時の安全性を考慮されて実装されていますが,このマイコンとペリフェラルの仕様から「まあ荒っぽいけどこうすれば原理的には行けるな」という感じ設計しているので,実装としてはかなり無理やりな実装がされています.
ブートローダーがメインプログラムのエントリポイントを叩く(下図の 5.)ことでメインプログラムが実行されるわけですが,その直前にエントリーポイントとそれ以下の SRAM に展開されるソフトウェア(=プログラムやデータ)を SRAM に展開(上書き)させる(下図の 4.)ことで,しれっとソフトウェアを差し替えてしまう,というアイデアです.
開発したブートローダーはマイコン視点ではあくまでもユーザープログラムであり,その実行前にマイコンのブートローダーがデフォルトで実行されるソフトウェアを SRAM に展開しているので,Low レベルでそれらのメモリをまるっとアップデート先のソフトウェアの memory dump で上書きしている,という乱暴ぶりです(正確な意味でのブートローダーは作れない).
丁寧なメモリのセクション管理とマッピングをやっているのできちんとワークしてますが,今でもなかなかだなとは思います.
現在所属している ArkEdge Space Inc. (株式会社アークエッジ・スペース) のソフトウェア・基盤システム部(詳細は弊社 tech blog の『 宇宙業界にソフトウェアの力で挑むチームができてから1年が経ちました』を参照)には, "部ポリシー" と "部 OKR (Objective and Key Result)" が設定されています.
このポリシーと Objective(平たく言うと,部の "夢")は,年末あたりに tech blog の方で公開しようかと思っていますが,そのポリシーの1つに,
"開発するすべてのソフトウェアは, update 可能であるべきである."
というものがあり,ArkEdge Space のすべてのソフトウェアは衛星搭載組込みソフトウェアも含めて,ハードウェアの設計段階からアップデートが考慮されています.
アップデート不能のソフトウェアの開発・検証コストは高くなりがちです.そして,今後たくさんの衛星を打ち上げていくとき,様々なソフトウェアの variant を軌道上で管理するのも高コストです.
ソフトウェアのアップデートが容易に可能であるからこそ,ソフトウェア開発全体の工数も削減され,さらに運用のコストも下がっていくはずなのです.
最後に.
Ryo Suzumoto., et al., Design and Development of Low-cost and Highly Reliable C&DH Subsystem for Deep Space Nano Satellites. 32nd International Symposium on Space Technology and Science, 2019-f-33, 2019. | |
xkcd. Software Updates. Retrieved December 9, 2022, from https://xkcd.com/2224/ |
名前
Email (※公開されることはありません)
コメント