スピーカー :
  • 小泉 耕二 氏 株式会社アールジーン 代表取締役 IoTNEWS 代表
聞き手 :
  • 小島 英揮 氏、Still Day One 合同会社 代表社員 パラレルマーケター・エバンジェリスト


エッジデバイスの流れを追いかける


小島 : 今日は小泉さんとエッジデバイスの動向を深く切り込んで行こうと思います。

小泉 : IoTNEWS の小泉です。木曜日朝の J-WAVE Morning Radio で、記事解説を担当しています。別所哲也さんの番組なので聞かれたことがある方もいらっしゃるかもしれませんね。また、木曜日の夜はフジテレビの Live News α にコメンテーターとして出演しています。

小島 : IoTNEWS についてもう少し教えていただけますか。

小泉 : IoTNEWS というと IoT に関連する技術情報がメインのコンテンツというイメージを持たれる方が多いのですが、私自身はビジネス コンサルティングの出身でどちらかというとビジネスの中でのデジタル活用をどのように行うべきかという観点で情報をお届けしています。したがって、事例やデータ活用の方法を中心にできるだけ事業に役立つことを探して、発信していくことを心がけています。

小島 : コンサルタントの方がメディアに関わるキャリアパスというのはあまり無い気がするのですが。

小泉 : コンサルタントは、基本的に 2 次情報で仕事をしていることが多いんですよ。例えば、調査会社のレポートや海外事例を参考にしながら何かを組み立てるという仕事です。したがって、コンサルタントが自ら現場に行くことは意外に少ないと思います。一方、私自身は自分でその実態を見ないと気が済まない性格なんです。

以前、日本が中国に負けているぞ、これはまずいぞという記事が新聞などで結構話題になりましたが、何がどの程度問題なのかを、そうした記事では踏み込んでいませんでした。雰囲気を伝える報道はあれど、具体的なことには触れていないわけです。実際に深センに行った方がそこで見たこと、聞いたことをすぐにブログにアップというのがもう当たり前になっていて、こうしたブログの方がよっぽど詳しい情報なわけです。

自分が知らないことはまだまだたくさんありますからね。とにかく、行って聞いて、返していく、事業会社さんであればその事業について勉強をさせていただき、そこで得たことをきちんと伝えるようにしています。

小島 : Inevitable ja night は今日が 11 回目、足掛け 2 年ほどになります。今日はエッジデバイスがテーマですが、まずは、細かいところにをいきなり入らずに、技術を俯瞰していただき、皆さんに理解してもらうこと、そして、自分ごととして考えていただけるような内容にしたいと思います。



エッジデバイスとは?


小島 : では、最初にエッジデバイスが何か、言葉の定義から入りましょう。これは、IoTNEWS さんでの定義を引用させていただいたものです。

【エッジデバイス】
エッジデバイスとは、別々のネットワーク間同士で通信をし、データの効果や統合、同期などをシームレスに仲介する機器のことをいう。
ルーターやスイッチのように LAN 環境におけるデータ交換や切り替えをしたりするものから、多数のネットワークのそれぞれのゲートウェイを接続するものまで幅広い製品が存在している。
出典 : IoTNEWS


小泉 : 自動車もある種のエッジデバイス(実際にはエッジデバイスの集合体)と捉えることができます。クラウドとは対極の概念ですね。

小島 : この定義からすると、個々の端末、デバイスに処理系があるイメージですね。一方、IoT はそこには処理だったりインテリジェンスが必ずしもあるわけではないですよね。

小泉 : そうですね。温度センサーや光センサーといった、データを取得するものは IoT と呼んでいます。

小島 : ということは、IoT はデータを送るために通信が関与しているわけですね。一方、エッジデバイスはそれ自体が独立して何かを処理するもの、こんなイメージでしょうか?

小泉 : そういう見方も確かにありますが、実際にはさまざまな機能のものがあります。例えば、お湯を沸かすポットには、単純に温度を上げるための簡単なチップが埋め込まれています。しかし、自動車には高性能なチップが搭載されているわけじゃないですか。ですから、単純なものから複雑なものまで、これらを総称してエッジデバイスと呼んだほうがいいかもしれません。

小島 : では、エッジデバイスで具体的にはどんなものがあるでしょう? TPU がエッジデバイスというのは衝撃的ですよね。

小泉 : ここ数年は曲がる基板が話題です。たとえば、ゴルフクラブのグリップにぐるぐると巻きつけるタイプのものがあります。クラブを振る速度を測るわけです。また、腕時計のバンドの部分に埋め込むというものもあります。物理的にデバイスを小さくする方向もありますが、これらのように一定の大きさを保ちつつ曲げることができる素材もあります。

したがって、コンピュータの処理能力で分類することもありますが、物理的にどういう性質を持っているかという分類もありますね。

小島 : カメラとの融合もありますね。撮影した情報をそのデバイスで処理してすぐに何かを制御するというものです。

小泉 : はい。さらに、自動運転の技術の一部の機能を切り出して使うこともありますね。無人搬送車(AGV)は決められた軌道を通るものですが、これまではビニールテープなどを床に貼るなどして軌道を最初に示しておく必要がありました。しかし、最近はロボット自身がセンシングして自ら移動経路を決めることが可能です。これも、エッジデバイスの進化に寄るところが大きいですね。

小島 : 別な観点ではいかがでしょうか? 情報システムの歴史を振り返ると、ホストから始まって、クライアント サーバーの分散時代に移り、クラウドで再び集約し、そしてまた分散へと集中と分散を繰り返していますよね。

小泉 : そうですね。行ったり来たりしています。処理もそうですが、データを一箇所に集めるべきか、分散管理すべきかという議論は良くあります。

ある工場でのお話ですが、データを一箇所に集約してどうするのという議論がありました。いろいろなデータを一箇所で集中的に管理するのは良さそうな感じもするのですが、最近ではエッジ側が保持するデータ量もそこそこになってきていて、それをすべて一箇所で管理することが現実的では無くなってきています。クラウドがすべてという流れも変わってきているのではないでしょうか。




エッジデバイスが求められる理由


小島 : 次に、エッジデバイスが求められる背景を整理したいと思います。次の図は、上段がエッジデバイスに対するニーズ、下段がユースケースを列挙したものです。

遅延が起きては困る状況、通信環境が整備できない状況、つまりオフラインの状況については詳しい説明は不要かもしれませんね。プライバシーやセキュリティに関しては、外部にデータを出せない、クラウドにはデータを上げずにエッジ側だけで処理したいというニーズはありますよね。これらは、クラウドを推進する際に良く出てくる話題でもありますね。



小泉 : センサーデータをクラウドに上げること無く、エッジ側で処理できたら良いというケースはたくさんありますよね。

小島 : 下段はユースケースですが、これも良く出てくる AI と VR/AR(xR)。体験っていうのはすごい大事ですからね。

小泉 : そうですね。工場の中でタブレットをパイプの上にかざすと、センサーで取得した温度情報がタブレットのパイプの画像の上に表示されるという事例があります。パイプの内部の温度はただいま 20 ℃ ですといった感じです。VR の例ですね。

小島 : パイプの温度情報を単に表示するだけでなく、タブレット側で何か処理することもありますよね。

小泉 : カメラがその典型的な例かもしれません。カメラで撮影したものをすべてクラウドに上げるのではなくて、必要なものだけを選択して上げる。この選択という処理はエッジ側で行われるわけです。

小島 : そして、自動運転。自動運転ができるようになると、そこから技術が切り出されて、使われるようになりますよね。(ロボット)掃除機もそうですよね。

ところで、今後、エッジデバイスはどんどん進化していくと、それを使うための環境も合わせて整備するべきという意見もあります。いかがでしょうか?技術の進化と環境の整備が伴わなければ、社会実装が難しいですよね。

小泉 : はい。さらに言えば、コストも考慮すべきです。スマートシティというコンセプトはとても素晴らしいのですが、では街中にセンサーをつけて、アクチュエータを整備してとなったら、膨大な費用がかかります。

小島 : そして、利用者のコンセンサスを取ることも大切ですね。

先日、中国の杭州市に行く機会がありました。アリババの本社がある街です。そこに、顔認証だけでものが購入できる自動販売機がありました。驚きましたね。ご存知のように、中国ではバーコード決済がかなり普及しています。しかし、もうスマートフォンをかざすこともなく、顔認証で決済が行われる時代になっているわけです。

アリペイを利用する際、本人確認のため顔データを提出するのでその顔データを使っているそうです。利用者からすると便利になるなら顔データを出すことに何ら抵抗は無いわけです。ちなみに、決済のみならず、新幹線の駅への入場も顔パスでした。(顔認証ができない外国人は別の列)


気になるカメラソリューション


小泉 : カメラを使ったソリューションをいくつかご紹介したいと思います。



小島 : 生徒の状態管理というのはどのようなものなのでしょうか?

小泉 : これは、中国の展示会に出展されていたもので、授業中に居眠りをしている学生をチェックするというサービスです。

最近、一番気になっているのが工場での利用です。たとえば、工場のラインにカメラを設置し、定点観測する。ライン上を流れるものを撮影し、画像認識を経てその認識結果をロボットアームに伝えて、アームが正確に物体を掴む。対象物が多少傾いていたとしてもアームが調整してその物体を正しく掴むことができるというものです。

また、インテルが最近発表したテニスボールぐらいの大きさのカメラには加速度センサーが備わっています。先ほどの例では、カメラを工場内に固定して定点観測するのですが、こちらは逆でカメラそのものが移動し、動いている対象物を認識してロボットに伝えることができます。

小島 : つまり、カメラと物体との相対的な距離をリアルタイムで測ることができるというわけですね。とても複雑な処理ができそうですね。

小泉 : これまでは、カメラは固定されていて俯瞰した状況を撮影して、その情報を元にロボットアームが動くというものだったのですが、このカメラはアームそのものにカメラをつけることもできます。

小島 : その次の倉庫の例は?

小泉 : 倉庫に高性能なカメラを設置して、ものや人の動きを把握しようというものです。たとえば、棚にある荷物をピッキングするソリューションがあります。さらに、逆に荷物を棚のどこに収めるかを目的としたソリューションも求められています。むしろこちらの方は技術的に難しくて、荷物を間違った場所に置いてしまうことがあります。倉庫に設置したカメラがその間違いを認識できればこの問題も解決できます。加えて、いちいちクラウドにデータを上げなくても良ければ、もっと良い解決策と言えますね。

小島 : 中国でバーコード決済が広まった理由の一つは、バーコードさえ表示しておけば決済ができる、つまり導入にコストがあまりかからなかったからです。しかし、今後、顔認証で決済することになると、そのためのデバイスが大量に必要になります。その結果、誰もが手に入れられるようなコストになれば、そこで新しいユースケースができて、フィードバックがあり、さらに別なユースケースができる、そういうことが繰り返されることになります。今の中国が持つ社会実装力の高さがなせる技と言っても良いかもしれません。



ロボットアームのリアルタイム制御


小泉 : ロボットアームの分野でも面白い事例があります。1 台の産業用 PC(IPC)で複数のロボットアームを統合制御するというソリューションです(詳しくはこちらの記事をご覧ください)。リアルタイム OS を搭載した IPC にはロボットコントローラが実装されていて、高速ネットワーク(EtherCAT)に接続された複数のロボットアームの協調動作を制御します。ロボットアーム単体でもかなり複雑な動作をしますが、このロボットアームが複数台で協調することで、より高度で複雑な作業をすることが可能になります。

小島 : 海外のカンファレンスで、お掃除ロボットメーカーの幹部が話していたことを思い出しました。人間がロボットに対して「掃除しておいて」というと、まずは部屋の上方の埃を落として、それから床を掃除して、最後は窓を開けて換気をして・・・と一連の作業をその環境にあわせてやってくれるというものでした。

小泉 : なるほど、今日は、外は雨が降っていて窓は開けられないから、埃は落とさずに床掃除だけをしておこうとか、環境にあわせて制御が行われるということですね。

小島 : 単純なシーケンス制御だとイレギュラーなことが起きた時の対応は難しいですが、協調による制御ができれば、人間にとってかなり心地良い結果をもたらしてくれますよね。

小泉 : 指示されたことを忠実に行うだけでなく、状況をきちんと把握して、適切な判断をしながら作業を進めていくということが、このエッジデバイスの世界でも急速に進んでいくと思います。


5G 時代におけるエッジデバイス


小島 : 5G が普及したら、もっと広域で同じような複雑な制御ができそうですね。

小泉 : 5G で世の中すべてが繋がったら確かに実現はできるでしょう。しかしながら、基地局からそのデバイスまでを 5G で接続できたとしても、そのデバイスの先が本当に高速で通信できるのか、また、高速通信に耐えられるコンピュータ リソースなのかということも考える必要があります。従来に比べて良くなりそうというのは間違いないでしょうが、それが保証できるというのは時期尚早だと思います。

小島 : 5G には多数同時接続という特徴もありますよね。

小泉 : 高速通信よりも同時に多くのデバイスと接続できるという特徴の方が IoT にとって喜ばしいことですね。スマートシティを実現することを考えた際に、街中の至るところに設置される大量のデバイス、センサーを超高速で、遅延を抑えて通信できるわけですからね。

小島 : 接続先がインテリジェントな形で協調すれば、さらにいろいろなことができそうですね。


小泉 : 5G で多くのデバイスを接続すれば、クラウド側のコンピュータ リソースとエッジデバイス側のコンピュータ リソースが溶け合うというか融合するというか、どちらでも処理が可能になって、相互にカバーできる状態になります。

小島 : クラウドとエッジデバイスが 1 つの大きなコンピュータ リソースになるということでしょうか。

小泉 : そうです。たとえば、3 つのエッジデバイスが接続されているとしましょう。そのうちの 1 つが機能不全になったとしても、隣のデバイスが代わりに動くというそんな形が考えられます。自動運転カーのコンピュータの動作が、運転中におかしくなった場合、そのコンピュータを停止しようというのは自然な対応です。しかし、コンピュータを停止することはすなわち誰かがその代わりに車を制御しなければなりません。では、いきなり自動から手動運転に切り替えてしまうというのもちょっと乱暴な話で、運転手に負担をかけることになり逆に危険を伴うかもしれません。しかし、隣のレーンを走っている自動車がその異常を検知して、その車の制御を代行することができれば、手動運転の必要は無くなります。

エッジデバイス単体の性能や安全性を高めることは重要ですが、そうではなくて周辺の複数のデバイスと協調することで、自分がダメだった時に他に委ねるとか、あるいは 1 台ではできない大量のデータ処理を複数のコンピュータ リソースと協調して行うとか、そういうことが実際にできる時が近づいていると思います。

小島 : クラウドではコンテナ技術によって可搬性を高める方向の流れがありますが、エッジデバイスでも同様な動きはあるのでしょうか。

小泉 : コンテナ技術を使った機器もどんどん増えています。これが進化すれば、いずれは、ロボットアームのようなところでもコンテナ技術が使われるようになるでしょう。同じプログラムをクラウド側のリソースとエッジ側のリソースのいずれかで動かすこともできるわけです。さらにクラウドとデバイスが 5G で接続されていれば、状況に応じて、すぐに切り替えることも可能でしょう。たとえば、アームが 2 本あった時に、一方のアームの処理の負荷が高いと判断したら、すぐに他方のアームに切り替えて処理を継続するということもできます。

小島 : エッジデバイスというと決められた処理を粛々とこなすものという印象があったのですが、今の話が現実になると、いいようにやってくれる感がさらに高まりますね。協調とかオーケストレーションの世界が楽しみですね。

では最後に、エッジデバイスの今後について、小泉さんはどのように見ていますか?

小泉 : 先ほどもお話ししたように、デバイス単体が自律的に何かをするというよりも、複数のデバイスが協調することで想像以上に面白い動きをするんじゃないでしょうか。もともとプログラムのとおりに動くいわゆるシーケンス処理を得意としており、今後はデバイスに搭載されるコンピュータ リソースも増えるのでますます賢くなることは確かです。ただ、搭載できるリソースも無限ではないですから、無理やりリソースを詰め込むのではなくて、複数のデバイスで協調することで、さらに賢くしていこうという方向に向かっていると思います。

小島 : わかりました。今日はありがとうございました。


Reviewed by Hak Matsuda - Developer Relations Team



Cloud IoT Core クライアント ライブラリ

Cloud IoT Core クライアント ライブラリは、Android Things デベロッパーがわずか数行のコードで使い始めることができるように設計されました。認証、セキュリティ、エラー処理、オフライン操作のベスト プラクティスが実装されており、ネットワーク、スレッド、メッセージ ハンドリングの処理を行ってくれます。

Cloud IoT Core は承認済み端末を追跡する端末レジストリを管理し、各端末は公開鍵を使ってサーバー認証を行います。Android Things では、ハードウェアのサポートによって暗号鍵マテリアルを確実に保護する Android Keystore など、IoT アプリの保護に役立つ多くの機能が提供されています。クライアント ライブラリは RSA 鍵と ECC 鍵の両方をサポートし、Cloud IoT Core での認証に利用できる JSON Web Token(JWT)の生成を実装します。

接続を確立できた端末は、テレメトリー データをテレメトリー トピック内の 1 つまたは複数のバケットにパブリッシュできるほか、個々の端末状態トピックに対して内部状態を報告できます。端末の状態は、ソフトウェアのバージョンや動作しているセンサーの数などの情報を格納することを想定しています。テレメトリー メッセージは、実際のセンサーの測定値など、端末からのその他すべてのデータが対象です。端末は、Cloud IoT Core がパブリッシュする 構成変更をサブスクライブすることもできます。

現実世界の IoT 端末は質の悪い無線条件で動作しているので、クライアント ライブラリは、エラー処理や、イベントのキャッシュと再送信を幅広くサポートしています。オフライン動作をカスタマイズしたいデベロッパーのために、ライブラリのキューをカスタマイズしたり置き換えたりすることもできます。これにより、保存するイベントや、オンラインに戻ったときに送信するイベントの順番などを細かく制御することが可能です。

Android Things を使った端末のプロビジョニングと認証


Cloud IoT Core クライアント ライブラリは、Android Things を使った端末のプロビジョニングや認証の全体像の一部です。この点の詳細については、Google I/O 2018 のプレゼンテーション動画をご覧ください。




サンプルコード

Cloud IoT Core クライアント ライブラリは簡単に使ってみることができます。Android Things プロジェクトの build.gradle ファイルに次の行を追加するだけです。
implementation 'com.google.android.things:cloud-iot-core:1.0.0'

このライブラリは、ご自分でビルドしたい方のために、オープンソースとして GitHub で公開されています。さらに、Android Things でセンサーハブを実現する方法を示すサンプルも公開しています。これは、接続されているセンサーからデータを収集し、それを Google Cloud IoT Pub/Sub トピックにパブリッシュするものです。

独自のコードでクライアント ライブラリを使うのも簡単です。次の Kotlin の例は、プロジェクトに基づいて新しい構成とクライアントを作成する方法を示しています。
var configuration = IotCoreConfiguration.Builder().
                         .setProjectId("my-gcp-project")
                         .setRegistry("my-device-registry", "us-central1")
                         .setDeviceId("my-device-id")
                         .setKeyPair(keyPairObject)
                         .build()

var iotCoreClient = IotCoreClient.Builder()
              .setIotCoreConfiguration(configuration)
              .setOnConfigurationListener(onConfigurationListener)
              .setConnectionCallback(connectionCallback)
              .build()

iotCoreClient.connect()

続いて、次の Kotlin の例では、テレメトリー情報や端末の状態をパブリッシュしています。
private fun publishTelemetry(temperature: Float, humidity: Float) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"temperature" : $temperature,
        |"humidity": $humidity
        |}""".trimMargin().toByteArray()
    val event = TelemetryEvent(examplePayload, topicSubpath, TelemetryEvent.QOS_AT_LEAST_ONCE)
    iotCoreClient.publishTelemetry(event)
}

private fun publishDeviceState(telemetryFrequency: Int, enabledSensors: Array<String>) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"telemetryFrequency": $telemetryFrequency,
        |"enabledSensors": ${enabledSensors.contentToString()}
        |}""".trimMargin().toByteArray()
    iotCoreClient.publishDeviceState(examplePayload)
}


参考資料

Android Things 開発の詳細については、デベロッパー サイトをご覧ください。Cloud IoT Core を使ってみるための詳しい情報については、情報ページやドキュメントをご覧ください。ぜひ Google+ の Google's IoT Developers Community に参加して、皆さんが Android Things や Cloud IoT Core で開発しているものについて教えてください。



Reviewed by Takuo Suzuki - Developer Relations Team


NXP i.MX7D System on Module

 
製品版ハードウェア サンプル  
 
Android Things は、デベロッパーが市場にリリース可能な端末を開発できるようサポートに特に力を入れています。それには、Android Things SoM(System on Module)上で実行するソフトウェアだけでなく、カスタム ハードウェアの構築も含まれます。この取り組みの一環として、ハードウェアとソフトウェアの連動の実例となる製品サンプル シリーズの第 1 弾となる Edison Candle をリリースしました。コードは GitHub に、ハードウェアの設計ファイルは CircuitHub にありますので、第三者企業もそれらを利用し簡単に製造することができます。  
 
Edison Candle サンプルのソースと概略図

 
以前の Developer Preview にフィードバックを送ってくださったデベロッパーの皆さま、ありがとうございました。バグレポートや機能リクエストによって今後も引き続きフィードバックをお願いします。質問はどんなものでもかまいませんので、stackoverflow にお寄せください。Developer Preview 4 のイメージは、Android Things ダウンロード ãƒšãƒ¼ã‚¸ã«、変更点はリリースノートからご覧いただけます。最新情報やアイデアを話し合うことができ、4,900 名以上のメンバーが参加している Google+ の Google IoT デベロッパー コミュニティにも参加できます。Google I/O でも、Android Things と IoT に関する多数のセッションを行いました。YouTube にある Google I/O 2017 のプレイリストから動画をご覧ください。  
 
Posted by Takeshi Hagikura - Developer Relations Team




Posted by Yoshifumi Yamaguchi - Developer Relations Team
Share on Twitter Share on Facebook

接続端末の開発では、他の端末との通信方法を選択し、ユーザーと接続端末の通信を許可する必要があります。そこで Weave が必要となります。Weave では、双方向から操作できる通信機能を端末に直接組み込むことができます。また携帯電話や端末がクラウドから、ローカルやリモートで相互に通信できるメッセージング サービスも提供しており、Weave クラウド サーバーを使用することで、リモート通信でウェブ接続端末にどこからでも安全にアクセスできます。Weave で端末の設定やアクセス制限を安全に行うこともできます。さらに Brillo 内に直接組み込まれているため Brillo に対してシームレスに動作しますが、Weave ライブラリを既存の Linux ベース OS で使用することも可能です。

Weave の優れた機能については、次のビデオをご覧ください。
Weave には iOS 用と Android 用のモバイル SDK が搭載されており、モバイル ユーザーの接続状態を管理し、さらに機能を強化できるアプリを構築できます。アプリを実際の端末まで適用したいと考えるアプリ開発者は、Weave のモバイル およびウェブ API を使用して、機種や台数に関係なく Weave 端末を 1 つのアプリで制御できます。

Brillo と Weave は、デフォルト設定でもオープン、拡張可能、しかも安全なため、さまざまな端末や使用事例をサポートでき、提供されるプラットフォーム、ツール、サービスで端末やアプリがさらに使いやすくなります。

プラットフォーム以外にも、認定 Weave ブランドの端末を提供する Weave 互換性プログラムのほか、シリコン ベンダーが Brillo 準拠のハードウェア開発と販売を行うための、ハードウェア プログラムを順次公開していきます。

Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook