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

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第37回は、現在は入手がほぼ不可能になってしまった「Nano-RK」を取り上げる。

[大原雄介，MONOist]

なぜPriotiryベースのSchedulingなのか

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

図3　さすがにOSEKは論外だとは思う［クリックで拡大］ 出所：CMU

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

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