【コア#2】Space ROSはRealTimeOSでなきゃいけないの？

はじめに

背景紹介を交えて

　Advent Calendar 2024の企画として、Space ROS (Robot Operating System)について集中的に解説/紹介しています。Space ROSの以下の機能構成のうち、本編前後ではコア（中核）について話しています。

　Space ROSは宇宙品質ROS(2)を目指すプロジェクトで、その「宇宙品質」とは、いわゆるNASA規格 NPR7150.2のClass Aを目指す、としています。

　Space ROSで採用しようとしているリアルタイムOS（RTOS）であるRTEMSについては昨日こちらで紹介しています。

本編について

　私はかなり初期からのROS1ネイティブユーザですが、組み込み対応を謳うROS2が出てきたときに、ようやく組み込み系が、ロボティクスが進むか！と心躍らせたものです。しかし、（私の勝手な意見ですが）思ったより進んでいない印象もあります。（悪いことでもなんでもないのですが）ROS2ユーザは、やはりPCを用いてUbuntu上にROS2をインストールし開発を進めることがほとんどです。ROS2使用のロボット設計で組み込み系に手を出すの？は１つの大きな判断ポイントになります。それはPCから組み込み系に移行するのはやはり１つも2つもハードルが上がる行為になるからです。まず処理系ハードウェアを見つけなければいけませんし、使いたいソフトウェア（ライブラリやツール）は使用可能か、また、ポーティングがどれだけ必要になるか、など調べてもあまり情報が出てこないこと多いです。組み込み系ハードウェアやライブラリがたくさん出てきていますけどどれが一番ハマるかの検討をしているより、結局うーんよくわからんけど仕方ないから自作しよう（そしてハマって後悔する）…となることも少なくないと思います。

　また、ROS2を組み込み系で使用する場合必ずRTOSを使用しなければならないの？という議論もあると思います。Raspberry PiやJetsonシリーズなどOSを組み込める組み込み系での使用を目した処理系ハードウェアも充実してきています。一方で、今回の対象である宇宙機は組み込み系の１つであり、先程出てきたClass Aにもあるように結局固めに作るんだよね、というイメージがあろうかと思います。

本編では、Space ROSはRealTimeOSでなきゃいけないの？という素朴な疑問について考察してみます。結論から言うと、やりたいこと次第だけどClass AアプリケーションならYesだろうなぁ、だからやっぱりRTEMSなのかなとなります。

ROS2使用のロボット設計で組み込み系に手を出すの？

　ロボット設計で組み込み系に手を出すかどうかは、まず、設計対象のロボットがどれくらいリアルタイム性の要求が強いか？に依存します。

処理系が実現しなければならない要求　

処理系が実現しなければならない要求として(私と周囲のある人々が以前プレインストーミングして)挙げたのは以下のリストです＊。

1. 応答性能
   • システムの要求に対して必要なタイミングに応答する性能
     • 例：自動車のエンジン制御やブレーキ制御などはリアルタイム性をもって対応が必要
     • メッセージ（ROS2の場合Topic等）が確実に意図したタイミングで計算処理系AプロセスA'から計算処理系BのプロセスB'に伝わること
2. タスクスケジューリング
   • タスクの優先度に基づいたスケジューリング。重要なタスクが迅速に実行される
   • 初期化や終了化などのシーケンスを適切なタイミングで実行できること
3. 時間管理
   • 決まった間隔での処理やタイミングの制御の実現。
     • 例：ロボットの制御周期は一定であって欲しい
4. マルチタスク
   • サポートするコアの場合は、複数のタスクを同時に実行する。上記タスクスケジューリングと時間管理の難易度が上がる。
5. ハードウェア込のシステムとしての高い信頼性の実現
   • ハードウェアに対応した仕立て
     • 例：FIT値
     • 例：放射線対応、RADHARD vs. RAD TOLERANT vs. 民生グレード品

　１～4はかなり相互に依存関係があって、要するに、優先順位が付いた処理やモジュール間データのやりとりを決められたタイミングでできるかどうか、つまり、リアルタイム性を、切り口変えながら言及している感じです。5は処理系電子部品そのものの話になっていて、通常品、産業品、MIL品、宇宙品など異なるグレードの話があり、また、宇宙の場合には放射線耐性の値があったりします。計算処理系を選ぶときには5も重要になりますが、リアルタイム性の考察をするときには1～４が直接の対象となります。

　ロボット設計で組み込み系に手を出すの？という設問に対しては、ハードウェア込のシステムとしての高い信頼性の実現（上記５）の設問は別途あるとして、リアルタイム性の問いかけには、時間的な期待を外れて処理されても問題ない制御系にたいしては、非リアルタイム系のUbuntuやWindowsを使えばよいし、その要求が厳しくなれば、しっかり組み込み系を使うとなります。

ROS2使用の組み込み系の場合必ずRTOSを使用しなければならないの？

　結局この回答も上記の結論と同じく時間的な期待を外れて処理されても問題ない制御系にたいしては、非リアルタイム系のUbuntuやWindowsを使えばよいし、その要求が厳しくなれば、しっかり組み込み系を使うなのですが、そのとき、"しっかりした組み込み系"にはどのような種類があるか、というところから始められればと思います。

組み込み系の種類

1. RTOS

　RTOSは比較的シンプルな作りであり、マイコンのように何も他にOSが入っていないようなプロセッサに実装していきます。OS非搭載で、アセンプラレベルまで落とし込められれば、もうほかに邪魔は入らないのでタイミング制約を外さない、だからリアルタイムを謳える、ということになります。安全信頼性の高い宇宙機では基本的にはこれが使用されています。また、ROS2を使おうとなるとmicro-ROSなど対応するプロジェクトがありますが、この場合も使用するRTOSなどの制約があります。
　RTOSには、VxWorks、LynxOSなど有償品があるのと、現在SpaceROS推奨の無償RTOSであるRTEMSにもツール群があります。有償のVxWorksの場合以下のツールを（一部さらに追加で有償ですが）提供しています。

• CPU使用率、メモリ、割り込み分析
  • Workbench Analysis Tools/CPU Profilerは、各処理のCPU使用率を推定するツールです。システム内のスレッドやタスクのCPU使用率を測定し、各コアごとの詳細なアクティビティ（カーネルメモリ、割り込みなど）を分析
    _
• TimeStamp精度と測定
  • システムクロックのレートは、sysClkRateSet()関数を使用して変更でき、これによりクロックの精度向上可能。また、sysTimestampで高精度なタイミング測定が可能
    _
• ﾏﾙﾁｺｱﾀｲﾐﾝｸﾞ分析
  • Rapita SystemsのRapiTimeを使用。RapiTimeは特にリアルタイムシステムの最悪実行時間（WCET）解析に特化。視覚化ツールでユーザーが実行時間のボトルネックを特定しやすくする。またDO-178CやISO 26262などの認証基準に対応したレポートを生成する機能。

　RTEMSはCPU使用率、メモリ、割り込み分析のプロファイリング情報を取得するためにrtems_profiling_iterate()関数を使用し、XML形式でレポートを生成するためrtems_profiling_report_xml()関数を使用するのですが、VxWorksほどツールが充実されていないです。

　当然そうだろうとなりつつ抑える必要があるのは、あるRTOS上で書かれたソースコードが自動的に先述した「処理系が実現しなければならない要求」を満たすわけではないです。ソースコードを書く人は自分で秩序立ててソースコードを記載したうえでツールを駆使して要求を満たすか確認をし、必要があればソースを変えていき自分の要求にはめていく流れになっていきます。

2. リアルタイムLinux

　（工事中）

3. Ubuntuでそのまま使用（Ubuntu + ROS2）

　組み込み系ではないと思いますが敢えて挙げさせて頂きます。結局のところはこれでそのままフルでROS2を含むLinuxのインフラをそのまま使えるメリットは大きいからです。
　実装出来るPREEMPT-RTパッチ（ソフトリアルタイムとも呼ばれる）を適用したLinuxを使用することが多いと思います。PREEMPT-RTパッチを当てると、タスクを切り替える走査を行う頻度が高くなります。

結局Space ROSはRealTimeOSでなきゃいけないの

　基本的には宇宙ではRTOSを使用することがほとんどですが、何をするかによって使いこなすべきです。 通信のハンドシェイクや精細なモータ制御等、リアルタイム性の要求が厳しければ、あまり何も考えずRTOSを使用すべきでしょうが、Global path planningなど処理時間が大きくなり、かつ「若干」増減があっても問題ない場合には、この処理固有の非RTOS計算処理ホストを準備して対処する場合もあるかもしれません。例えば（Web情報ですが）SpaceXのStarlink衛星のクリティカルではない（確率で故障を抑えていい）モジュールに関してはLinuxをそのままを使用しているようです。

　いずれにせよ、非RTOSを使用した計算処理系においては、最悪実行時間（WCET）が読めなくなるのが問題となります。その場合、このリスクをどのように回避や許容まで持っていくのかが全体設計の肝になっていきますが、こういう系も実態としてはこの先存在しても良いのではないか、と考えています。

　そのため、宇宙ロボティクスの拡大の過程においてはRTOSを必ず使うことが選択肢にならない可能性もあると私個人は思っています。そのシナリオにおいては普通にそのままROS2使おうか、という世界観に繋がりますので、そうすると確かにSpace ROSはとりあえず（？）RTOS/RTEMSで棲み分けて行こう、という考えも１つの方向性と私は考えています。

＊　私としては自信を持って出す項目群ですが、もしこういうのがまとまった文書とか規格になっているならばコメント頂けますと幸いです。