Space ROS の目的
そのSpace ROS の目的ですが、公式サイトを確認します。
https://space.ros.org/
以下を引用はすべては公式サイトからになります。
ロゴです：
Mission Statement
目的は以下のMission Statementから読み取れます。
（訳は私の意訳です。）
Space ROSとは：宇宙フライト品質と自律宇宙システム開発向けの、宇宙ロボットのオープンソースフレームワークです
目的：人気のあるROSフレームワークの宇宙ロボットシステムへの導入を容易にすることです
航空宇宙規格：Space ROSは航空宇宙規格に準拠したソフトウェアと成果物を提供します
オープンソースとオープンコミュニティ：ROSのメリットを宇宙ロボットに適用します
Space ROSとは、一言でいうと、
「ロボティクスのデファクトスタンダードであるROSを宇宙品質で宇宙にも持っていこう」
というプロジェクトになります。修飾子を取り除けは、 「宇宙品質ROS(2)」 です。
「宇宙品質ROS(2)」のうちの「ROS(2)」
（昨日の記事の繰り返しになりますが）ROSはPlumbing(配管)＋Tools＋Capabilities＋Ecosystemでその機能を表現される、50万超えユーザコミュニティに支えられるロボット工学のデファクトスタンダードです。Space ROSのスコープとしては、特にこれら4つの機能を宇宙ロボットに適用しようとしているわけです。
H. Kato and T. Saito. “RACS2: the ROS2 and cFS System, launched” Flight Software Workshop 2023 in March 2023
https://drive.google.com/file/d/1VBsiUEW6Z8pG8LvbM7lEyZMRMz9w-sjX/view （数値は最新に更新）
ROSはすでに地上で絶大な支持を得ていますし、実はユーザー数も4年間で倍増以上しています。なので、ROS的要素が必要とされる理由というか目的について説明に窮する心配はしていないです。
「宇宙品質ROS(2)」のうちの宇宙品質
一方で、そのソフトウェアが「宇宙品質」であることとはどういうことでしょうか？ **宇宙品質である、ということに関して、よく聞かれる質問が2つあります。
- Space ROSさえ使えば「自動的に」宇宙品質が担保できるのですか？
- 宇宙品質を担保するには何を満たしていればいいのですか？
1. Space ROSさえ使えば「自動的に」宇宙品質が担保できるのですか？
1のSpace ROSが「自動的に」宇宙品質が担保できるか、についてはいろんな考え方があると思いますが、私の考えは一義的にはNoだと思います。その理由は、ユーザの使用方法次第では宇宙品質が担保出来ていないケースが容易に見つかる からです。
単純な例ですと、ゼロ割り（例：3/0）です。Space ROSを使用しているからと言って、プログラム内でゼロ割りしてしまうと、宇宙品質的には当然アウトで、境界条件として対処が必要になります。ただし、セロ割りの場合は、単純な3/0みたいなケースのときには、コンパイルしたときにはワーニングを吐いてくれると思いますので、その言うことを聞けば防げます。ただ、3/xという演算があり、その演算時にx=0であることを防ぐとなると少し防ぐのが難しくなってきます。なので、この状況を（これは実はSpace ROSの標準装備品となり、別トピック内で後述しますが）静的コード解析ツールを用いて防ぎます。
要するに、Space ROSにおいても現状はツールを使って宇宙品質の一部を担保しようとしていると思いますが、そのツールの限界を超えた場合には対応出来ない、というのが、当たり前ですが現状に即した答えになると考えます。単純なゼロ割りのケースでも、マルチスレッドや割り込みが入ってきたり、不確定性の高い人間のユーザー系や時間のジッタが入ってきたりするだけで、問題が一気に複雑化するのは御存知の通りだと思います。また、不具合が出るのがゼロ割りのようなわかりやすいケースではなく、きちんと数値計算通りにロボットが挙動しているにも関わらず設計的に制御理論が発散し強振なり暴走してしまうケースも防ごうとすれば相当ハードルが高くなると思います。
ツールを使用して宇宙品質が担保できるか、は、どこまでツールが賢く対応できるか次第、また、人間がそのツールをいかに使いこなせるか次第、（または、自動的にその問題を適切に修正できるか？次第）にはなると考えられますが、Space ROSが「自動的に」宇宙品質が担保できる世界を目指していくことは良い究極的の目標となるのではないでしょうか。
2. 宇宙品質を担保するには何を満たしていればいいのですか？
2の宇宙品質を担保するには何を満たしていればいいか、については、以下Space ROS公式ページの記述からです：
_
品質についての言及が下半分にあります。（筆者日本語訳）
DO-178C や NPR7150.2 などの航空宇宙および NASA 標準に準拠することにより、高保証ミッションに採用できるようになります。
このうち、NPR7150.2がNASAの規格です。（DO-178Cは航空分野です。）サイトをリンクしたところ
https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2
現状（2024/12/3時点）サイトがメンテナンス中なのかアクセス出来ない状況でした。
（少し前まではアクセス出来ていたのですが。）
以下
NPR7150.2の解説記事 https://ldra.com/npr7150-2d/
海賊版サイト(？) https://govtribe.com/file/government-file/npr-7150-dot-2-dot-pdf
を参照にします。
NPR7150.2では、ソフトウェアのクリティカリティクラスを６つ定義しています。
Class A: Human-Related Space Software Systems （宇宙有人システム）
Class B: Non-Human Space Related Software Systems or Large-Scale Aeronautics Vehicles (人間以外の宇宙関連システム)
Class C: Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility Software
Class D: Basic Science/Engineering Design and Research and Technology Software
Class E: Design Concept and Research and Technology Software
Class F: General Purpose Computing, Business, and IT software
下記を見ると、Space ROSは上記のうちの一番クリティカルなClass Aを目指すとあります。
https://ntrs.nasa.gov/api/citations/20220017761/downloads/Space_ROS_SciTech.pdf
ただし、いつでもClass Aを目指せばいいということではなく、ミッション次第ということがわかります。
目次を見て内容の構造がわかると思います。事実上の内容は3,4,5章に記載があります。
- Chapter 3. Software Management Requirements
3.1 Software Life Cycle Planning
3.2 Software Cost Estimation
3.3 Software Schedules
3.4 Software Training
3.5 Software Classification Assessments
3.6 Software Assurance and Software Independent Verification & Validation
3.7 Safety-Critical Software
3.8 Automatic Generation of Software Source Code
3.9 Software Development Processes and Practices
3.10 Software Reuse
3.11 Software Cybersecurity
3.12 Software Bi-Directional Traceability - Chapter 4. Software Engineering (Life-Cycle) Requirements
4.1 Software Requirements
4.2 Software Architecture
4.3 Software Design
4.4 Software Implementation
4.5 Software Testing
4.6 Software Operations, Maintenance, and Retirement - Chapter 5. Supporting Software Life-Cycle Requirements
5.1 Software Configuration Management
5.2 Software Risk Management
5.3 Software Peer Reviews/Inspections
5.4 Software Measurements
5.5 Software Non-conformance or Defect Management
上記はミッション要求やソフトウェア要求から設計を進めて製造に落とし込み、単体試験を経てユニット試験に移行する、宇宙産業やシステムエンジニアリングでおなじみのいわゆるウォーターフォール型の**「V字カーブ」**に倣うキーワードが出てきていると思います。ソフトウェアを少し頑張っておられる方なら書いてあることはまあこんなものか、という感じで、目玉が飛び出るようなことはないのではないかと考えています。
まとめ
Space ROSが目指す「宇宙品質ROS(2)」についてのゴール地点について、特に「ROS(2)」と目指す「宇宙品質」を中心に記載しました。もう少し時間をかけてNPR7150.2の深掘りをする機会があれば実施したいです。