エッジコンピューティングの逆襲 特集
連載
» 2023年08月01日 07時00分 公開

今は亡きセンサーネットワーク向けRTOS「Nano-RK」はカーネルを持たないリアルタイムOS列伝(37)(2/3 ページ)

[大原雄介MONOist]

なぜPriotiryベースのSchedulingなのか

 さて、Nano-RKはこのFireFlyを動かすためのRTOSとして開発されたものである。こうしたセンサーネットワーク向けRTOSとしては、既に「Contiki」や、スマートメーターまで範囲を広げれば「Phoenix-RTOS」などもある訳で、FireFlyのプロジェクトでも当初は「Tiny OS」や「Mantis OS」の他、「μC/OS」「Emerald」「OSEK」などを検討したものの(図3)、うまくニーズにミートしないと判断し、「では作ってしまえ」の結果がNano-RKになったわけだ。

図3 図3 さすがにOSEKは論外だとは思う[クリックで拡大] 出所:CMU

 設計目標は図4に示されている。加えて言えば、上述したようにSRAM 8KB/Flash 128KBだから、これに収まる(使い切ったらアプリケーションが動かないので、当然アプリケーションの分を残す必要がある)省フットプリント性が求められた。

図4 図4 センサーノード向けRTOSとしてはごく普通の話ではある[クリックで拡大] 出所:CMU

 Nano-RKの特徴は以下のようになっている。

  • クラシックなPreemptiveのマルチタスク対応Abstractions
  • リアルタイムのPriority Based Scheduling
  • エラーハンドリング機能を内蔵。LVD(Low Voltage Detection)やHardware/Software Watchdog Timerに対応。
  • Stack統合
  • ノードの非同期リセット対応
  • リソースのOver-Useに対応
  • Tickless Timerを実装
  • 省フットプリント(RAM 2KB未満、Flash 16KB。ここにはLink Layerを含む)
  • SLIP(Serial Line IP)を利用したstreamを実装
  • TimeScope(実行時の実行時間測定機能)を搭載

 エラーハンドリング機能と、それに伴う非同期リセット機能をOSで持つのはちょっと珍しい(が、用途を考えれば納得できる)し、ネットワークとしてSLIPを利用したstreamを実装しているのも、ちょっと珍しいがこれも理解はしやすい。ちなみに、なぜPriotiryベースのSchedulingか? というと、センサーの種類によってプローブの間隔と処理時間が異なるからだとする。

 実際に以下のような性能が実例として挙がっている。

  • ネットワーク:非同期、処理時間10ms
  • 騒音センサー:200Hz、処理時間10μs
  • 輝度センサー:166Hz、処理時間10μs
  • スマートカメラ:1Hz、処理時間300ms
  • 位置センサー(資産追跡用):5Hz、処理時間10ms

 さすがにスマートカメラは他のセンサーと併用するのは厳しそうな感じだが、他のものについては1台のFireFlyで複数のセンサーを取り付けてデータ収集なども可能な範囲である。問題はこれをTimeベースのSchedulingにするのが著しく困難(そもそも周期がでたらめすぎるし、非同期のものまである)だからで、Priorityベースにすることは必須、という話であった。

 この設計目標に対する実装の結果が図5である。Context Swapの45μsは一般的には高速とは言いにくいが、ATMega128Lの動作周波数が8MHzということを考えると360cycleほどでContext Switchが行われているわけで、これは十分高速かと思う。またTaskとMutexが8つずつに16バイトのネットワークバッファーを抱えた状態でSRAMの占有サイズが2KBというのもやはり十分優秀かと思う。

図5 図5 OSとネットワークのSRAM占有サイズが合計664KBというのもかなり少ない。ただStackが128バイトとやや大きめなのは仕方ないところだろう。何にせよ、アプリケーション用にSRAM 6KB/Flash 110KBが余っているのだから、センサーノードとしては十分と思われる[クリックで拡大] 出所:CMU

Copyright © ITmedia, Inc. All Rights Reserved.