トロンフォーラム

本格始動! IoT-Engine & IoT-Aggregator

本格始動! IoT-Engine & IoT-Aggregator

IoT-Engine & IoT-Aggregator

坂村 健

IoT-Engineプロジェクト共同記者会見が2016年4月27日に行われた。半導体メーカー7社とソフトウェア会社2社が一同に集まりプロジェクトへの取り組みを表明した。坂村教授からは本プロジェクトの詳細が発表された。

オープンなIoT

IoT(Internet of Things)が、今、世界的なブームになっています。私は常に、IoTが大きく社会を変えられる鍵はオープンにあると言っています。このオープンということが非常に重要です。インターネットというのは、誰でも何にでも使えるオープンなネットワークだったからこそ社会を変えてきました。IoTのIは、まさにインターネットのIですから、広く誰もがインターネットにモノを自由につなげられることを示しています。

本日の共同記者発表でのポイントは、オープンアーキテクチャに基づくIoT-Engineというエッジノードを規格標準化したということです。ここに数社が試作をしたIoT-Engineがあります。CPUは違いますが、ボード、コネクタはまったく同じ規格で作られています。たとえば、今、私の隣りにあるこのドアの錠の中には、IoT-Engineが入っており、開け閉めのコントロールをしています。直接インターネットにつながっているので、インターネットにつながったスマートフォンから、ドアの錠をON/OFFしたりできます。同じ原理で電灯の点け消しもできます。こうした環境を標準化により容易に実現するのがIoT-Engineプロジェクトです。

ガバナンス管理

次にインターネット経由でモノを制御したりモノ同士を連携動作させたりするには、ガバナンス管理が重要になります。簡単にいうと、誰がいつ何をどのように制御できるかを管理するということです。適切に使うための高度な管理には、高度な判断が必要になります。ガバナンス管理のメカニズムがなく、単にモノがインターネットにつながるというだけでは使いものになりません。

これからの組込みシステムは、これまで以上にセキュリティが重要だと言われます。もちろんセキュリティは重要なのですが、単にデータが漏れないようにするといった単純なセキュリティではなく、データベース資源を使った高度な処理に基づくガバナンス管理が重要なのです。

たとえば、今日の発表会場になっているこのビルのすべての設備はインターネットに直結しています。この照明や空調もインターネットにつながっていて、そのAPI(Application Programming Interface)をオープンにしています。ですから、学生でもこれらの設備を自由にコントロールできます。しかし、きちんとガバナンス管理されているので、私がこうやって講演しているときには学生はいたずらできない。照明は消えないようになっている。これがガバナンス管理です。

けれども、私が講演していないときには、自由に照明を点け消しして構いません。セキュリティを強固にしようというと、いっさい学生にはコントロールさせなければいいといった方向に行ってしまう。しかしそれは違います。誰が、どのような時に、どのような権限で、何をコントロールできるのかを的確に制御するのがガバナンス管理です。これが重要だということです。

ガバナンス管理はクラウドで

さてこういう仕組みをどう作るかですが、組込みシステムのガバナンス管理を強くしようとして、エッジノード側を複雑にしてしまいがちです。しかしそうすると、本日各チップメーカーさんに発表していただくようなワンチップのマイクロプロセッサではパワー不足です。そこでもっと強力なマイコンを持ってくると高価で消費電力の大きなものになってしまう。私の考え方はエッジは軽くクラウドは重くです。今やエッジノードのマイコンだけで全部を処理しようというのは古い考えで、高度な処理はクラウド側で担うべきです。

そのためにはIoT-Engineだけでは不十分で、これがクラウドにつながるためのメカニズムとクラウド側のソフトウェアが重要になります。TRONでは、軽いエッジノードをモノの中に入れてその値段を安く低消費電力にすることを重要視しています。先ほどの例で、ドアの鍵を開け閉めするだけの装置にいくらガバナンス管理が必要だからといって、エッジノードが高価になってしまったら誰も買わないからです。そこら中に入ったコンピュータが大量の電力を消費したら大変です。IoTに必要なのは軽いエッジノードであり、組込みシステムはどんどん軽くしなければいけない、というのがこのプロジェクトの基本方針です。

アグリゲート・コンピューティング・モデル

TRONが考えるオープンIoTのモデルを、アグリゲート・コンピューティング・モデルと呼んでいます。アグリゲート(Aggregate)は“総体”という意味です。たとえば家の中にエアコン、テレビ、オーディオ装置、洗濯機があるとします。これまでは、これらをホームオートメーションでつなごうとすると、各家電に高度なマイクロプロセッサを搭載してホームLANというような名前のLANにつなぐ。さらにホームLAN上のホームサーバーからインターネットにつなぐといったアプローチでした。こうすると、エッジノードが重くなります。一つ一つのマイクロプロセッサ上にセキュリティ機能を実装しないといけない。

私の考えはこれとは違い、各家電をインターネットに直結させます。直結先が各メーカーのクラウドで、そのクラウド同士がネットの中で連携します。その連携の要になるシステムを、IoT-Aggregatorアグリゲーターといっています。クラウド側のプラットフォームです。エッジノード側だけでなく、クラウド側のこのプラットフォームも一緒に提供していきます。

たとえば、ここにM社のエアコンがあったら、この中にIoT-Engineが入っています。クラウド上のプラットフォーム側にも、その受け口が用意されています。機器同士を接続するというのは、エッジノード同士を直接つなげるのではなくて、クラウドの中でつなげるということです。これがいちばん大きな特長です。これは新しい情報処理の形であり、世界に先駆けてこのアグリゲートモデルを提唱しそれを開発していくことをTRONプロジェクトは表明しています。

トンネリング

組込み製品はそのメーカーのクラウドに直結する。そして、そのクラウドでのAPIをオープン化して他社のクラウドと連携して動作するようにします。そうでなく情報処理系OSを搭載して直接APIを公開する製品とも連携は可能です。しかし、情報処理用のOS、たとえばAndroid機器を直接ドアの錠の中に入れたらハードウェアが高価になってしまいます。

そこで機器とクラウドの間はトンネリングで直結します。特定クラウドとの常時直結通信しか考えなければ、少ない資源で、単純かつ強固なセキュリティが実現できるというのが私の考えです。極端に言うとトンネリングの際、接続先の情報をROMに入れてしまい特定の場所にしかつながないとすれば、これだけでも一定のセキュリティ向上につながります。

エッジノードの本体をデバイス実身じっしんと呼んでいます。クラウド側ではこれに対応するものをデバイス仮身といいます。エッジノードに対応する仮身があって、そこに向けてトンネリングという技術で、オープンネットワークでも、セキュアな通信経路を確立します。エッジノードにアクセスするときは、直接通信するのでなく、IoT-Aggregatorを経由してデバイス仮身経由でアクセスします。エッジノードとクラウド間は仮想的な常時直結状況と考えていいので、ローカルには複雑なガバナンス管理機能が要らなくなります。

高度な処理はクラウドで

TRONの基本的な考えは、システムの総体としてインテリジェンスを高度化するということです。単体のエッジノードのほうはどんどん軽くして、高度な機能はクラウドに持っていくということを徹底的に推し進める。これがIoT-Engineの大きな特長です。

たとえば人工知能を使った画像認識をエッジノードのマイコンだけで処理すべきではありません。最近のカメラには、カメラ側で認識しようとするものがありますね。だから安くはないですよね、こういうカメラ。しかし、すべてクラウドで処理すればカメラは安くなります。自然言語による音声認識も同様です。きちんと実現するには辞書やコーパスを大量に持たないといけない。それは安価なエッジノードでは実現できません。他にも、家電の動作データから故障の前兆を知って予防メンテナンスするとか、ヘルスケア用品の測定値を元に高度な医療アドバイスをするといったビッグデータに基づく解析も同様です。

私は、これからLTE、5Gなどの通信技術によりネットはもっと速くなると考えています。したがって、特に都市部で過ごすときには、高速な常時接続ネットワークを前提にできる。そこで、こういった情報システムの探求に、最大限力を入れたいと思っています。

IoT-Aggregator

今後、総体を管理するためのクラウド側のいわばメタOSが新たな主戦場になります。コンテクストアウェアな処理、ビッグデータ解析、異種データベース統合、異種APIの統合、セキュリティ、アクセスコントロール、ガバナンスポリシー。メタOSは、これらを制御する機能を持ち、既存プラットフォーム(OS)同士を結び付けるものです。

TRONで実現するメタOSを「IoT-Aggregator」と名づけ、そこに「u2(uIDアーキテクチャ2.0)」という統合フレームワークを採用します。この統合フレームワークでは、すべてのIoT-Engineにucodeを振ります。ucodeは名前のようなもので、ユニークな認識を可能にするIDです。ucodeが付いたIoT-Engineがこの統合フレームワークに登録されます。インターネットでは電子メールアドレスを知っていればその人にメールが届くように、ucodeを使ってどの機器とつなげたいという指定ができます。そのときの状況に応じて、その通信を許可する許可しないという判断もこのフレームワークの中で行います。

たとえば、各社のビデオ、ドア、エアコン、オーディオ、監視カメラ、環境センサー、など全部にucodeが振られサーバーに登録されます。IoT-Aggregatorでは、これとこれをつなげていいとか、これとこれはつなげてはいけないというルール(アクセスポリシー)をユーザーが書けるようになっています。

そして、IoTデバイスをレゴブロック部品のように組み合わせてプログラミングできます。この電灯とこのドアの開閉は連動させたいといったことを、ウェブ上のブロック部品を組み合わせて模型を作っていくのと同じようにして組み上げられます。

さらに、このプラットフォームの中で、アクセスポリシーが書けます。この人はアクセスしてもいいけれど、この人は駄目というようなことをきめ細かくクラウドの中で設定できます。誰というだけでなく、この日ならはこの人はいいけれど、他の日はだめといった指定もできます。

IoT-Engine

本日の共同記者会見は、エッジノードのところを開発するメーカーの方たちと一緒に開催しています。IoT-Engineでは何を標準化したかというと、ノード側に関しては、第一にコネクタを標準化し、第二にµT-Kernelという私たちのOSを搭載することを標準にしました。こうすれば、クラウドと簡単につながります。一言でまとめると、CPUは何でもいい。コネクタは標準化されている。OSはµT-Kernelを載せる。あとは、それをネットにつなげるということです。

IoT-Engineボードをよく見ると、ピンコネクタがあります(写真1)。このピンコネクタには、センサーやオンオフするスイッチをつなげます。たとえば、今ここにある模型のドアと電灯に対して、今、スマートフォンを操作すると、カチッと音がしてドアの錠が開閉しましたね。スマートフォンからインターネット上のIoT-Aggregatorに指示が飛んで、続いてIoT-Aggregatorからこのドアの錠に向かってコマンドが届き、ロック錠が開いたり閉まったりしたのです。

写真1 IoT-Engine(前面)

6LoWPANの採用

さて、IoT-Engineをどうやってインターネットに接続するかが重要な課題です。そのために見ていただきたいのが、このボードの背面のコネクタです(写真2)。インターネットにつなげるときには、BluetoothとかWi-Fiとか、いろいろな方法がありますが、消費電力を低くする目的で6LoWPANを採用しました。6LoWPANのWi-Fiに対するメリットは消費電力が小さいことです。Bluetoothに対するメリットはIPv6で直結できることです。これも非常に重要で、一個一個にIPを与えたいとなったら、もうIPv6でいくしかない。

現在世の中にあるほとんどの機器では、インターネットへの接続はIPv4によるWi-FiかBluetoothを使います。しかし私たちはIPv6で直結するのが本来の形だろうと考えましたが、さすがに電灯の点け消しや電磁ロックを開け閉めにIPv6のWi-Fiは大げさなので、6LoWPANを採用しました。6LoWPANは、IPv6のサブセットです。組込み機器用の6LoWPANモジュールを開発し、IoT-Engineのコネクタにつながるようになっています。それが背面にあるコネクタであり、ここも標準化されています。

なぜ6LoWPANモジュールが取り外しできるようになっているかというと、電波利用に関する各国の法規制に対応するためです。6LoWPANに使える電波周波数は、世界各地域で異なるので、それぞれに対応するよう6LoWPANモジュールを取り換えられるようにしました。ただし、大量生産すればメインのマイクロチップモジュールの中に6LoWPAN機能が入ったものも開発可能です。そういうものであれば本当のワンチップになります。

写真2 IoT-Engine(背面、6LoWPANモジュール取り付けた状態)

IoT-Engineを構成するもの

IoT-Engineの標準化をまとめると、共通化したものはコネクタ、µT-Kernel OS、もう一つ小型低消費電力が可能なWPAN(IEEE802.15.4)の無線を搭載するというのが条件です。WPANは、Wireless Personal Area Network、近距離無線通信というもので、電池だけでなく、光や振動などのエネルギーハーベストで動作させるような機器にも対応できる無線方式です。たとえばリチウム電池の場合、動作の頻度にもよりますが、数年間電池交換不要といったことも可能です。

IoT-Engineでは、クラウドのWebAPIと親和性が高いCoAP(Constrained Application Protocol、簡易HTTPプロトコル)が標準搭載されています。したがって、6LoWPANプロトコルとCoAPを使って、IoT-Aggregatorにつなげることになります。

RTOSのµT-Kernel 2.0は、WPANのビーコンモードにおいてマイクロプロセッサをディープスリープモードに落とすことができる、超低消費電力対応のOSです。

IoT-Engine規格の標準化

TRONのOSの特長は、プロセッサアグノスティック(agnostic)と言って、マイクロプロセッサは、世界中のどんなものも使えるようにしようとしていることです。そのために、IoT-Engineでは、非常に自由度を持った信号ピンの割り当てをしています。低コストで短期開発に有効なArduino互換I/O信号ピン割り当ても持っています。この背景には、周辺機器を新たにいろいろそろえるのは手間がかかるということがあります。Arduino用の周辺機器は世界中にたくさんあり、それらをこのIoT-Engineのコネクタで全部接続できるようにしました。

こうして大量の周辺機器をいろいろ揃えやすくするために、コネクタ寸法規格、コネクタ信号割り当てガイドライン、典型的なデバイスのドライバインターフェース、ミドルウェアインターフェース、そういうものを開発環境として提供しています。

IoT-Engineのコネクタの信号規格(割り当て)や物理的寸法は非常に細かく定義されています。

しかし、逆にいえば標準化されているのはこれだけですので、世界中のマイコンメーカーにとっては参入しやすい市場です。あとは、ユーザーに対しては、CPUの機能や性能で競ってもらうという環境が提供できたと思います。

T-Car

最後に、IoT-Engineを普及させるため開発中の教育用教材「T-Car」のお話をしましょう。T-Carは、10分1のスケールの模型自動車です。いろいろなセンサーがたくさん載っていますが、もちろんその心臓部にIoT-Engineがあります。

このT-Carを使った世界コンテストを企画しています。これらのたくさんのセンサーが6LoWPAN経由でクラウドにつながっていて、クラウドからいろいろな情報が降ってきます。その情報と車に付いているセンサーを使って、サーキットコースを誰がいちばん早くゴールできるかというコンテストです。ですから、T-Carを動かすのは車の中に組み込んだプログラムだけでなく、クラウドにあるAI(人工知能)の助けを借りても、当然構わないです。今回のコンテストが他のロボットコンテストと違うのはここです。これまでのロボットコンテストでは、その中に組み込んだプログラムだけで何かを達成します。一方こちらのコンテストは、完全にクラウドと一体化しているアグリゲートコンピューティングモデルに基づくコンテストです。この車を効率的に動かすためのいろいろな分析プログラムは、むしろクラウドの中にあるほうが自然です。クラウド上のプログラムと車に搭載されたリアルタイム処理プログラムを組み合わせることによって、いかに早くゴールにたどり着くかを競うコンテストです。

現在トロンフォーラムでは、T-Carを使ってIoTやアグリゲートコンピューティングを習得していただくための教材を準備しています。今後、このIoT-Engineとアグリゲート・コンピューティング・モデルを世界に向けて提案、促進していこうと考えていますので、よろしくお願いしたいと思います。ありがとうございました。

*「u2 Open IoT Platform」は、本記者会見の後、「IoT-Aggregator」に名称変更されました。本稿は変更後に基づき表記しています。

引用元
パーソナルメディア刊 TRONWARE VOL.160 p6-p13「IoT-Engine&IoT-Aggregator」


IoT-EngineとIoT-Aggregatorで実現するIoT

「オープンな」連携のために

IoT(Internet of Things)の世界では、さまざまな製品(モノ=Things)同士がインターネットを介して連携する。そのためには、まずエッジ側のハードウェアやソフトウェアの標準化が必要だが、同時にクラウド側にもその連携のためのソフトウェアが必要だ。このような連携のためのプラットフォームを標準提供し今まで単独独立であった組込みシステムの世界をネット世界の一員にし、IoTの世界を実現しようというのがIoT-Engineプロジェクトの考え方だ。

では、それらを連携させるためにはどうすればよいのだろうか。すでにインターネットに接続し、連携動作が可能な製品は多数登場している。しかしこれらの多くは今までメーカーのクラウドに閉じており、メーカー内で完結したシステム、たとえば自社開発のスマートフォンアプリ以外では制御できないなど限られたものであった。住宅の中の空調を最適制御しようとすれば、買ってきたさまざまな製品が連動して、たとえばエアコンとサーキュレータが連携動作することが求められるが、住宅内が同じメーカーの製品で統一されている状況はまず考えられない。その結果、連携に分断が生じてしまうこととなる(図1)。

そこで、異なるメーカーの製品の間での連携を行うために、何かしらの「仲介役」のような立場の仕組みが必要になる。そしてその仲介役は、誰に対してもオープンであるべきとし「仲介役」を実現するクラウド側のプラットフォームとして、TRONプロジェクトではメーカーの垣根を超えた連携を実現する「TRON Open IoT Platform」を提案してきた。今後、同プラットフォームを「IoT-Aggregatorアグリゲーター 」と呼び、以下、その内容を解説する。

連携とアプリを自由化するIoT-Aggregator

IoT-Aggregatorによる機器間連携の概要を図2に示す。メーカーの立場からみたIoT-Aggregatorとは、ネットにつながる製品のためにメーカーが持つクラウド間を接続するものである。製品がIoT-Aggregatorに直接接続するという構成も考えられる。しかし、メーカーが故障データの収集など閉じた形で扱いたいものと、連携のための情報やAPIなどのようにオープンとしたいことを分けることとし、メーカー側の権利を守った上で他社とつなぐ――つまり他社メーカークラウド間をつなぐという構成とした。

さらに、IoT-Aggregatorの仕組みでは、アプリベンダーも重視し、メーカーの公式アプリ以外のさまざまな機能をアプリベンダーやユーザが自由に選択・インストールし、利用できる仕組みを提供する(図3)。従来の携帯電話では、あらかじめインストールされていたソフトウェアをそのまま使うという想定であったのに対し、スマートフォンではGoogle検索やTwitterなど、携帯電話を作ったメーカーとは関係のないさまざまな企業や組織、さらには個人が開発したソフトウェアを自由にダウンロード、インストールすることができる。このようなモデルであれば、メーカー純正アプリでは後回しとなりやすい、たとえば視覚障碍者向けの音声インタフェースを持ったアプリなどを、さまざまな企業や組織、個人などが有償または無償で公開することが進むようなことも期待できる。

つまりIoT-Aggregatorとは、メーカー単体で閉じていた連携を自由化し、住宅や都市といった人が住む環境を「スマートフォン」のような自由なアプリケーションプラットフォーム化するというものである。オープンな枠組みのなかでの協調と競争を実現する、まさにTRON的なオープンプラットフォームを実現するものとなっている。

IoT-Aggregatorの構成と機能

IoT-Aggregatorの構成の概略を図4に示す。先ほど示したように、IoT-Aggregatorはさまざまなメーカークラウドとアプリベンダーの接続の仲立ちをする位置づけとなっており、以下の主要コンポーネントによって構成される:

● uID Accounts

Open ID Connect 1.0に基づく認証メカニズムを提供する。アプリケーションへのトークン発行を行い、ユーザの許可に基づきアプリケーションがユーザの所有するデバイスを制御することを可能にする。

● ucodeマネージャ

APIに基づきucodeを発行する機能を提供するほか、ucodeに関する基本的な属性情報(所有権など)を管理する。

● デバイスマネージャ

デバイスへのAPI発行を受け付け、適切な形式に変換したうえでメーカークラウドに要求を転送する。ユーザの許可に基づくアクセス制御は、デバイスマネージャで統一的に実現する。「合成デバイス」と呼ばれる、部屋・家といったより大きい単位を仮想的なデバイスとして、ソフトウェアによって実現することも可能としている(図5)。

● TRON IoT Dashboard

IoT-Aggregatorで連携された機器やアプリに関する設定や確認を行うためのダッシュボード画面を提供する。A社のアプリケーションBが、Cさんの所有する機器にアクセスすることを許可する、といった権限設定や、設置場所の設定などを統一的な画面を通して設定することができる。

着々と開発が進むIoT-Engine・IoT-Aggregator

IoT-Aggregatorによって実現される「オープンなIoT」の接続に参加するための標準モジュールがIoT-Engineであるが、IoT-Engineの仕様はすでに決定しており、IoT-Engineに関するソフトウェア、ハードウェアの開発もほぼ完了している。2016年8月には製品として提供予定だ。

IoT-Aggregatorについては、トロンフォーラムのIoT WGメンバーに先行して公開し、正式な版は来年2017年第二四半期には公開される予定だ。興味のある方はぜひIoT WGに参加いただき、レビューなどの活動にかかわっていただきたい。

photo

図1 異なるメーカー製品間における連携の分断

photo

図2 IoT-Aggregatorによる異なるメーカーの機器間の連携

photo

図3 IoT-Aggregatorの全体像

photo

図4 IoT-Aggregatorの構成

photo

図5 合成デバイス
 
引用元
パーソナルメディア刊 TRONWARE VOL.160 p14-p17「IoT-EngineとIoT-Aggregatorで実現するIoT」
Return Top