Android対抗の「Tizen」から派生した「TizenRT」はRTOSらしくないRTOS：リアルタイムOS列伝（14）（2/3 ページ）

[大原雄介，MONOist]

「TizenRT」は「Tizen」のサブセットではない

　さて、このTizenには目立たないが派生型（？）としてリアルタイムOS（RTOS）を志向した「TizenRT」というものがある。TizenRTのWikiによれば、TizenRTは例えばディスプレイを持たない家電機器や、ウェアラブルながら小さな液晶ディスプレイしか持たない、要するにスマートウォッチのさらに下のグレードなどのものといった低価格製品をターゲットにしたRTOSであり、「Cortex-M」あるいは「Cortex-R」をターゲットとし、SRAMで2MB、フラッシュで16MB未満のメモリ環境で動作することを目的としたRTOSだという（図3）。

図3　「TizenRT」のコンセプト（クリックで拡大） 出典：TizenRTのWiki

　面白いのはこのTizenRT、別にTizenのサブセットではないことだ。TizenRTの開発は2015年にスタートしたが、ベースとなったのは何と連載第10回で紹介した「NuttX」である。このNuttXカーネルをベースに、IPv4/v6スタック、ファイルシステム、「AraStorage」と呼ばれる軽量データベース、デバイスモニター、IoT（モノのインターネット）プロトコル（OCFやLWM2Mなど）を実装していった。AgaStorageとIoTプロトコルを組み合わせることで、いわゆるセンサーノード（Constrained Device（制約されたデバイス）なんて呼ばれ方をすることもある）を簡単に実装できるようになった、というのがその主張だ。

　ちょっと余談になるが、そもそもセンサーノードを検討する場合、センサーがそのままネットワークに直結されているような構造を考えることが多い。ただこれは本当に最小構成であって、これだとセンサーからの入力があると常に送信が行われるから消費電力（と、もし携帯電話ネットワークを使っている場合はその通信費）がかさむことになる。さらに、ネットワーク層でサポートしているレベルの再送しかカバーしないので、例えば受け取る先が何らかの事情で一時的にデータを受け取れないとそのままデータがロストするという、冗長性の少ない設計になってしまう。それもあって、センサーノードであってもある程度はデータをストアできる設計が好ましいし、普通はそうした実装のされ方をしている（どの程度か、というのはさまざまな要因が絡むので一概には言えないが）。

　こうした場合にオンメモリ（正確にはオンSRAM）で格納できる程度なら話はまだ楽だが、Constrained Deviceではそれほど大量のSRAMをデータ格納に充てるのは難しいことが多い。必然的にフラッシュ、場合によっては外部ストレージ（SDメモリカードなど）を活用する方向になりがちだが、これを自分で全部ハンドリングするのは面倒である。そこでファイルシステムを入れるという話になるが、組み込みデータベースをファイルシステム替わりに使う、というのは結構昔からある話である（15年前ともう大昔だが、「組み込みデータベースカタログ」という連載記事をMONOistで書いたこともある ）。AgaStorageはちょうどこういう使い方に適したデータベースである。これを使って普段はデータを格納し、タイミングが来たら必要なデータをピックアップして、まとめて上位ホストに送信なんていう実装が、TizenRTではOSに用意されているサービスだけで完結するというのは、なかなかツボを心得た実装のような気がする。

　話を元に戻す。RTOSの場合は一般に、通常のOSに比べると制限が多い。もちろんリソースが最小限の構成で動くことが多いから、リソース占有とのトレードオフの結果ではあるのだが、TizenRTはあえてこれに逆行。動的なモジュール追加を可能にしたり、Linuxに近いランタイム環境を提供したり、という方針を取っている。もともとNuttXがローダブルカーネルモジュールの実装や動的なメモリ管理などの基本的な機能を搭載していることもあり、これをさらに拡充。また、ランタイム環境としてPOSIX APIやBSD Socket API、Shell、Kconfigのビルド構成などをサポートしている。BSD SocketなどはNuttXからの継承だが、POSIX APIの場合NuttXはあくまでPOSIX「風」であって、このあたりは手が入ったようだ。また2017年にはJerryScriptとIoT.jsから構成される、軽量JavaScript環境も追加された。