さらば「Mbed OS」、RTOS淘汰の波にはArmも逆らえない：リアルタイムOS列伝（49）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第49回は、ついにEOL（End of Life）がアナウンスされたArmの「Mbed OS」について、なぜ淘汰の波に飲まれたのかを考察する。

[大原雄介，MONOist]

Mbed OSを含むMbedの役目はほぼ終わっていた？

　当たり前の話ではあるが、Mbed OSというかMbedそのものはArmがエコシステムパートナーを大量に巻き込んで始めたものであるから、いきなり「止めた」というわけにはいかない。当然、パートナーへのネゴシエーションはずっと前に行っているはずだし、相談を受けたパートナーとしても「現在代替プラットフォームを検討中です」と顧客にアナウンスするわけにもいかない。パートナー各社は代替プラットフォームにめどを付けた上で、Armの発表に合わせてアナウンスをできるように準備を整えていたものと思われる。そう考えると、6.2.1のリリースが出たころには、Armの内部的には既にMbedのEOLは既定路線だった可能性もある。

　もっとも、Mbed OSを含むMbedの役目はほぼ終わっていた、という見方もできる。もともとMbed、というか当時の言い方で言えばmbedは当初、ちょうどArduinoの対抗馬的な位置付けとなる「Cortex-Mをベースにしたホビーにも使える安価な評価ボード」を狙っており、この目的のためにオンラインの開発環境や、USBケーブルでPCとつなぐだけでダウンロードと実行が可能な動作環境が提供された。

　それが、Sensinode Oyの買収でNanoStack／NanoService／NanoRouterといったコンポーネントを入手し、これをベースにRTOSやそれと対になるエッジサーバを構築するに当たり、開発環境としてmbed向けのオンライン開発環境を流用したことで話がややこしくなった。

　mbed OS向けのオンライン開発環境は、当然従来のmbed向けの開発環境と非常に似ているから「移行は容易」とするが、そもそもベアメタルで動作する従来のmbedと、RTOSであるmbed OSでは、プログラムの書き方は当然変わってくるし、デバイスに対するアクセス方法も異なる。NXPのLPC1768（と、実はLPC2368も当初のmbedプラットフォーム向けに提供されたが、こちらはほとんど流行らなかった）のみをサポートしていた当初のmbedと、複数のメーカーから提供されるMCUをまとめてカバーするmbed OSの間で互換性を取るというのは土台無理だし、2014年の時点でArduinoプロジェクトはCortex-M0+コアを内蔵するATSAMD21G18を搭載したArduino Zeroを発表しているし、2012年にはRaspberry Piも登場。ホビー向けの高性能評価ボードの市場はこうした競合製品に押さえられることになり、LPC1768ベースのmbedボードのシェアは次第に縮小し、mbedというとmbed OSと、そのmbed OSが稼働する各社の評価ボードを指すようになってきた。

　そのmbed OS、当初の目的はIoT（モノのインターネット）デバイスの標準プラットフォームになるのが目的であった。ただ途中から、その目的がむしろクラウドとのコネクティビティに切り替わっていったのは仕方がないことだろう。

　2016年10月、Armはクラウドサービスのmbed Cloudを発表するとと、mbed（とmbed OS）は、このmbed Cloudへのアクセス手段を提供するものに変化した。そのあたりの経緯は以前の連載「IoT観測所」の中でご紹介した通りだ。

　ただ、Armのクラウドサービスに関する意気込みは結実しなかった。2018年にはトレジャーデータを買収し、mbed Cloudはトレジャーデータの提供していたPelion IoT Platformのバックボーンとなったのだが、トレジャーデータはArmによる買収前からPelion IoT Platformを提供していた関係で、mbed Cloudを利用しなくてもPelion IoT Platformは利用できた。結果としてPelionのビジネスは発展していっても、Mbedの方は伸び悩みのままとなっていた。