今は亡きセンサーネットワーク向け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　さすがに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