　Phoenix-RTOS 2.0はモノリシックカーネルで構成されており、当初から商用を念頭に開発された。ターゲットはまずx86で、次いでArmが追加、さらに後追いでEnsilicaの「eSi-RISC」も追加されている。フットプリントはバイナリイメージが300K～600KBと、x86としては比較的コンパクトである。ただLoC（Lines of Code：コード行数）は200K（20万行）ほどあったようで、恐らくはこの膨大なコードに起因するメンテナンス性の悪さが次のPhoenix-RTOS 3.0につながったものと思われる。

　このPhoenix-RTOS 2.0、最初に利用されたのでは電力メーターである。いわゆるスマートメーターのことだ。スマートメーターの場合、もちろん電流（というか、電力）の測定やロギングをリアルタイムで、かつそれなりの精度で行う必要があるからプロセッサ側にもそれなりの処理性能が必要である。昨今だとMCUでもそれなりの性能が出せるが、2000年代前半だと100MHz未満の「Cortex-M」などになるので、ちょっと性能的には厳しい。となるとx86などを考慮するのはまぁ妥当だろうし、コスト面はともかく消費電力に関しては何しろ電力メーターだから（法外に大きいのはともかく）バッテリー駆動並みに落とす必要はないわけで、x86が最初のターゲットになるのは当然である。

　もう1つ要求されたのが、電力線通信（PLC：Power Line Communication）への対応である。日本では結局ほとんど使われず、国内のスマートメーターはWi-Sunが主流になってしまったが、欧州などでは個々のスマートメーターと、その上位のDCU（Data Concentrator Unit）の間の通信はPLCを使うことが圧倒的に多い。このPLCも、G3-PLC（ITU-T G.9903）やPRIME（ITU-T G.9904）、IEEE 1901.2、G.hnem（ITU-T G.9955）など複数の通信規格が存在しており、どれが利用されるかはその地域別（というか電力会社別）に決まってくる。こうしたPLCへの対応も要求される。

　このスマートメーターへの傾倒は、そもそも親会社であるAtende Softwareがスマートグリッド向けのソリューションを手掛けていることと無縁ではないだろう。こうしたソリューションには、コンポーネントとしてのスマートメーターやDCUなどが必要になるし、そうしたものの開発のためにキーになるコンポーネントの開発を子会社に任せるというのもよくある話だ。そしてそのキーコンポーネントがRTOSのPhoenix-RTOSだった、ということである。実際、Phoenix-RTOSに関する市場分析を見ると、既存のRTOSではスマートメーターの要件にいろいろ足りていないという判断があり、それもあってPhoenix-RTOSの開発が進んだように見える（図2）。

図2　まぁこれらの理由も取って付けたように見えなくもない。ただし、PLCモデムの通信スタックなんて、これらの汎用RTOSには当然存在しないし、それを作る際にはRTOS側に手を入れたいシーンも出てくるだろう。となれば、全部自分たちで作った方がマシ、という判断は理解できる（クリックで拡大）

　ちなみにArmのサポートであるが、これはFreescale Semiconductor（現NXP Semiconductors）との協業により、「Cortex-A5」コアへの移植を行ったためである。同社は2012年、Cortex-A5と「Cortex-M4」をヘテロジニアス構成にした「Vybridシリーズ」プロセッサを発表しており、これは性能的にスマートメーターやDCUに利用するのに最適と判断されたようだ。かくして、Phoenix-RTOS 2.0や、ここにPRIMEのプロトコルスタックを積んだPhoenix-PRIME、同じくG3のプロトコルスタックを積んだPhoenix-G3といったカスタム版のPhoenix-RTOSもリリースされ、これらを搭載したスマートグリッド製品が登場することになった（図3～6）。

（左）図3　ある展示会でのEl Swedy Electrometerの展示ブース。Phoenix-PRIME／Phoenix-RTOS 2.0ベースで実装されているDCUとスマートグリッドが登場。（右）図4　図3に出てきたDCUと同じものであろうと思われる。全部で3万台生産され、うち2万台が設置されたとか（クリックで拡大）