坂村健教授講演の写真

平成28年9月24日にオープンソースカンファレンス2016 Shimaneが開催されました。

この日、基調講演をされた東京大学の坂村健教授にmruby/cの進むべき方向などについてインタビューを行い、ご意見を頂きました。

 (聞き手:東裕人専門研究員)


東研究員:mruby/cについて簡単に説明いたします。
まず、Rubyという言語は、開発者であるまつもとゆきひろさんが松江在住であることから、島根県や松江市ともに非常に注目しております。

Rubyは主にサーバーサイドで実績のある言語ですが、これをマイコンなどでも使用できれば、開発効率の向上にも役立つのではないかというのが発端でmrubyという容量の小さなバージョンが開発されました。これは数百kbyte程度のリソースで動くスクリプト言語であります。

しかし、開発の中心人物である九州工業大学の田中先生が、さらに小さなマイコンが多く存在していることから、より小さなスクリプト言語として実装することを目指してmruby/cの開発を始められ、しまねソフト研究開発センター(通称、ITOC)と共同開発をしているところです。

現在、開発中であり、先日ベータ版を公開したのですが、まだまだ実用までには多くの作業が残っている段階です。

mruby/cはVM上で動くものですが、VMのサイズは64kbyte以下を目標とし、これから実務に使えるプログラムを動作させるための環境を整えるにあたり何を中心に進めていくべきか検討をしているところです。

 

坂村教授:IoT時代、エッジノードの動作をカスタマイズするために、マイコン上で動作するスクリプト言語には興味があります。

TRONプロジェクトはこれまで、OSを中心とした開発が主であったことから、OSより上のレイヤーである言語には私は取り組んでいませんでした。TRONは、多くの企業のサポートがあり、半導体メーカーばかりではなく中には開発環境を作っている企業もあり、サポーターの方々がビジネスされている多くのマイコンや開発環境を取り入れてきました。従来型の組込みではメモリマップレベルでの作り込みが必要なので、開発言語の基本はCベースです。

OSに特化して開発し、最新のマイクロTカーネルは最小リソースだとワンチップでROMが10Kbyte以下、RAMも1Kbyte程度で動くものですのでこういう市場を主ターゲットにしています。スマートフォンの中に入っているメインチップよりはるかに小さなものが対象です。

しかし最近になってIoT関連の応用で、エッジノードをアドホックにカスタマイズしたいという話が出てくるようになって、ローカルなスクリプト言語にも私たちの世界でも注目が集まるようになってきました。我々もVMや言語の情報を収集しています。mruby/cの競合製品としてサムスンのJerryScriptやLuaがありますね。

これらの言語について以下の3つの点に注目しています。

(1)OSのネイティブな部分への直接アクセス機能

(2)スクリプトのポータブル性

(3)マルチスレッド対応

mruby/cはマルチスレッド対応されていないようですね。

 

東研究員:CRubyはマルチスレッド対応しているのですが、mrubyに移植する時に対象外となっています。そのため、mruby/cも対応していないという状況です。

移植の対象外となった理由については、CRubyの利用しているPスレッドがマイコンに備わっていないケースが多いことと、マイコンに実装されているRTOSのスレッド機能を利用する方が良いという判断があったと考えられます。

しかし、VM側でマルチタスクに対応するよう検討しているところではあります。

 

坂村教授:実は、マルチスレッド対応をされていないことが悪いこととは我々は考えていません。他の言語ではIoT対応でこれが重要として対応する動きがある中、mruby/cが対応していない理由を聞いただけです。

TRONにおけるIoTアグリゲータのアーキテクチャの考え方でいうと、IoT時代のエッジノードの要求事項の一番は低消費電力です。このことからマルチスレッド対応は必須とは思わない。

Rubyの立場に立てば時代背景から、余裕があるならVMでのスレッド対応しておいても良いかと思いますが、それで消費電力が上がるなら組込みの世界では本末転倒です。

JerryScriptがIoT対応を全面に押し出している要素は、

(1)64kbyteのRAM、200kbyte以下のフラッシュメモリーで動作

(2)ARMのThumb-2対応

(3)マルチスレッド対応

ですが…。

 

東研究員JerryScriptの元になったJavaScriptにはスレッド機能がないので、スレッド対応は戦略的な意味を感じます。

 

坂村教授:戦略的な意味が大きいでしょうね。

しかし私は、組込み系のシステムの観点からは、APIを利用できることの方がマルチスレッド対応より重要だと思っています。

 

東研究員CRubyの利用するAPIはUNIXを前提としたもので、RTOSのものとは大きく異なりますが、低レベルのAPIを扱うことに長けている言語であることから、RTOSとの接続にもラッパーなどを上手く作っていけると考えます。

 

坂村教授:実際には、いくらマルチスレッドを持っていると言ってもIoTのエッジノードを、JerryScriptを使ってゼロから開発することは非現実的です。基本的にRTOSは特定のハードを前提に、組込み開発のプロが扱うものであり、プロ以外の利用は非常に稀です。このような状況で、試作のためにスクリプト言語を利用することはあっても、最終プロダクトではスクリプト言語を利用するとコスト増につながり、低消費電力にはならない。VMを利用することも同じです。

TRONプロジェクトのIoTモデルでは、アグリゲートコンピューティング「総体」モデルというのを考えており、エッジの機能は必要最小限にして、ネットワークで常時接続しクラウドと合わせた「総体」で高度な機能を実現するというものです。実際、マイクロTカーネルではプロセスという概念がなく、エッジ側は最小限の機能に絞っている。

例えば、IoTのセンサーノードで高度なデータ処理をするより、クラウドでやった方がいい。しかし、ネットワークの負荷を下げるためのデータの前処理のようなものは、エッジでやった方がいい。しかしそういう前処理を応用によって柔軟に書き換えたいことはあり、ローカルにスクリプト言語を利用できると助かる場面もある。

 

東研究員データの前処理では、ノイズシェービングや膨大なデータの圧縮などで、アルゴリズム作成などのために試行錯誤が発生するからでしょうか。

 

坂村教授:試行錯誤とか、応用に合わせた柔軟性といった部分でしょう。IoTでは、設置したセンサーを後から別目的でも共用するといったこともありますから。固定的な部分と流動的な部分はアプリケーションによって異なります。

大学のコンピュータサイエンスの授業でも最初にスクリプト言語を教えて、アルゴリズムを試してみるのはとてもよいですね。

プログラム開発におけるアジャイル方式が組込み系でも要求されてきており、初期段階でスクリプト言語を利用するのは非常によいと思います。

また、ヒューマンインターフェースをどう設計するかは重要ですが、ウェアラブルコンピュータの試作など、試行錯誤しながら作り上げていくときにはスクリプト言語が最適ではないかと思います。

最近は単純なGUIばかりの話ではなく、あらゆるセンサーを使って動作を組み合わせて操作するNUIといった概念もでてきています。こういう時には操作性が重要視されるので、Rubyで「総体」をプログラムして試行錯誤ができるようになると大変良い。

 

東研究員まだ十分な機能を実装できていないのでアイディアの話ではありますが、ユーザーインターフェースの部分にmruby/cを使いたいと考えており、小さな液晶画面を備えたMP3プレイヤーを例にすると、ユーザーインターフェースはmruby/cで開発し、再生などの決まりきったことはC言語で開発するという使い分けが必要だと考えています。

高度なユーザーインターフェースは、プログラマーよりデザイナーの仕事であり、デザイナーにC言語で作ってもらうよりはRubyで開発する方が効率的だし、教育コストも下げられます。

 

坂村教授:JerryScriptなどと対抗するというのではなく、VMのコンパクト化や高効率化、OSのAPIを直接呼べるような工夫で使うOSごとに対応していくしかないと思います。

 

東研究員mruby/cはOSを使うパターンと使わないパターンの2つを考えており、OSを使うパターンではiTRONをターゲットにしてAPIを利用するラッパーを作りたいと考えています。

 

坂村教授:iTRONでもいいのですが、どうせやるなら最新のμTカーネルを使っていただきたい!またOSを使わないパターンは最近減ってますよ。

最近は、通信機能が必須であり、6LoWPANなどIPv6サービスの無線版を利用するような時、下にOSがないのはあまりに大変。送信するデータは簡単なものでも、通信処理は簡単ではない。

 

東研究員IPプロトコルを制御するのは複雑なので、OSが必要になりますね。


まだ話の途中ではありますが、時間が参りましたのでインタビューを終了いたします。今回、非常に有益なアドバイスを頂きましたので、今後のmruby/c開発において利用させて頂きます。

また、今後も引き続きよろしくお願いいたします。