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

[大原雄介，MONOist]

電池寿命を確保する仕組み

　もう1つ特徴を挙げるとすれば、Reservation機能であろう（図6）。これは要するにCPU／ネットワーク／センサーに対して、利用できるエネルギー量（要するに電池寿命から逆算した実行可能時間）を割り当てる形で電池寿命を確保するという仕組みだ。

図6　送信がめちゃくちゃ多いNode Bの電池寿命はわずか3.5日だが、それにつながるdとかeは受信頻度をReservationに基づいて制限することで、電池寿命を延ばすことができる［クリックで拡大］ 出所：CMU

　もちろんそのバーターというか、制限はいろいろとある（図7）。いわゆるカーネルに相当するものはなく、Abstractionsで提供されるSchedulerで制御しているので、安全性は非常に低いというか、お行儀のよいアプリケーションしか動かせないし、MMUすらない（何しろAVR8だ）から、うっかりメモリを使い切って暴走などの危険性もある（その場合はソフトウェアベースのWatchdogのおかげで自動リセットで元に戻るから、ある意味安全ではあるが）。

図7　先に「マルチタスク対応Abstractions」と書いたのは、そもそもカーネルに当たるものが存在しないからだ。強いて言えば、Nano-RK全体がカーネルというべきだろうか［クリックで拡大］ 出所：CMU

　シングルタスクのRTOSよりオーバーヘッドが大きいのは当然で、その代わりネットワーク処理などを別タスクに分離しやすいので、それだけプログラミングが容易になることを考えれば許容範囲だと思う。しかし、保護機能が一切ないのは商用向けとしては致命的で、あくまで研究プロジェクト用のRTOSだから許容されている面はあると思う。

　Nano-RKはオープンソースとしてソースコードがDual Licensing Modelで提供されており（このDual License、Trolltechが提供していた「Qt」のライセンスにならった、というあたりがいろいろ突っ込みを入れたいところではあるが）、2011年位までは活発に活動があった。FireFlyプロジェクトの論文ページは2007年までで終わっているが、2008〜2011年にもNano-RKそのものやNano-RKを利用した論文が出ているし、2020年には“Applications of Nano-RK in Internet of Things (IoT)”という論文が上がっている。

　ただし、FireFlyプロジェクトそのものが2007年あたりで一段落したようで（FireFlyプロジェクトそのものを、先述したxLabが現在メンテナンスしているもよう）、そうなるとNano-RKも必然的にフェーズアウトしてゆく運命にあるのは致し方ない。こんなWebサイトが存在する程度にはNano-RKの知名度が高かったことを考えるとちょっと残念ではあるのだが。