デバイスを接続する

デバイスのインターフェース

デバイスや外部のITシステムなどのIoTデータソースを接続するために、Things Cloud はエージェントを提供しています。 エージェントは、IoTネットワークのあらゆる側面を一元的に把握し、一元的に運用できるようにするソフトウェアコンポーネントです。

概要

ここではIoTデバイスや他のIoT関連データと Things Cloud をインターフェースで繋げる概念(concept)について解説します。

これらのシステムと Things Cloud をインターフェースするにはエージェントと呼ばれるドライバーソフトウェアが必要となります。最初にエージェントの主な役割について説明し、エージェントの構築オプションについて検証します。次にエージェントのライフサイクルを詳細に解説し、最後にテナントのITシステムのような他のデータソースからデータを抽出する時のエージェントの使用法について説明します。

関連トピックは下記の章をご参照ください:

エージェントとは?

M2Mデバイスには多種多様なプロトコル、パラメータ、ネットワーク接続オプションがあります。これらは低レベルのシリアルリンクからウェブサービスなどの完全なITプロトコルまであります。昨今のIoT標準では特定のセンサー装置のデータのアクセス方法、または特定の制御操作などが定義されることはほとんどありません。さらに、デバイスはモバイルネットワークやゲートウェイに接続される場合があります。

このような多様性からM2Mアプリケーションを保護するために Things Cloud ではエージェントと呼ばれるものを使用します。エージェントとは所定ベンダーとデバイス・タイプに対して3つの責任を果たす機能のことです:

  • デバイスに特定したインターフェース・プロトコルを個別参照プロトコルへ変換。
  • どんなドメインモデルも参照ドメインモデルへ変換。
  • どんなネットワークでも安全な遠隔通信を確立。

Agent architecture

プロトコル変換 コンフィグのパラメータ、データ情報、イベントや他の情報は一方より特定デバイス・プロトコルを通じてエージェントへ送信("push") されるかエージェントにより照会("poll")されます。エージェントはこれらのデータを Things Cloud の理解するプロコルへ変換します。同時に Things Cloud よりデバイス制御コマンドを受け取り("switch off that relay") デバイスの理解するプロトコルへ変換します。

Things Cloud は、幅広いプログラム環境で使用可能なREST(例:HTTP)やJSONに基づいたシンプルで安全な参照プロトコルを使います。 ほぼリアルタイムのシナリオを実現するためにプロトコルは"push" モデル(データが得られ次第送信)で構築されています。

モデル変換 コンフィグのパラメータ、データ情報、イベントはデバイス固有の名称(場合によって固有の単位も)があります。特定デバイスのエージェントはこのデバイス固有モデルを Things Cloud 参照モデルへ変換します。例えば "Received Wh"というパラメータである電力メーターのデバイスがデータを抽出すると、エージェントは "Total active energy"というキロワット時の参照データへ変換します。

安全な遠隔通信 多くのデバイスは、とくにクラウド環境上での遠隔通信に適した安全なプロトコルを提供するわけではありません。プロトコルはローカルネットワークのみしか対応しないもの、ファイアウォールやプロキシを通過できないもの、そして重要な情報をテキスト形式で運んでいるものなどがあります。このような状況を克服するため、 Things Cloud はエージェントをデバイス内に配置し、安全でインターネット接続可能なリンクを遠隔デバイスに提供します。

エージェントの概念を一言で説明すると:エージェントはデバイス自身に必要条件を強要せず、IoTアプリケーションをどんな遠隔IoTデバイスへ安全にインターフェースさせることができます。IoTデバイスとプロトコルの多様性からアプリケーションを保護することにより大幅なIoT アプリケーション開発の単純化を実現しました。

どのようなエージェント構造に対応していますか?

下図のようにエージェントはさまざまな方法で展開が可能です。2つの主なエージェントのバリエーションは サーバーサイドエージェントデバイスサイドエージェントになります。サーバーサイドエージェントは今後サービス提供を予定しています。

Agent architectures

サーバーサイド エージェント はクラウド上で走り、 Things Cloud がホストするか作成者で管理されます。デバイスは独自の特定デバイスプロトコルでサーバーサイドエージェントと接続します。この形態は以下の事項が一つ以上あてはまる場合主に選択されます:

  • デバイスは "closed"である。(つまり、デバイスはプログラム不可で、あらかじめ定義された特定のプロトコルでのみ外部と通信可能な場合)
  • デバイスのプロトコルはセキュアでインターネットと接続不可になっている。例えば、デバイスはクラウド接続するが、その逆はない。
  • デバイスと Things Cloud の間にVPNインフラが存在する。

デバイスサイド エージェントはデバイスのセンサーネットワークで動作します。このようなデバイスの一例として、ルーター、モバイル電話機、モデムなどがあります。エージェントはデバイス自身の実行環境で実施されます。バッテリーとメモリーが限定されたマイクロ・コントローラからLinuxで動作するミニ・コンピュータまで多様な環境のなかで動作可能です。 エージェントは直接接続したセンサーへ照会し、接続制御を操作します。ほとんどのケースでサーバーサイド エージェントよりも単純な構造となります。

エージェントのライフサイクル

エージェントの起動

サーバーサイド エージェント(今後提供予定) は持続的にクラウドで稼動し、対応するデバイス・タイプへの接続を許可します。デバイスサイド エージェント はデバイス上で稼動し、デバイスの電源がついてデバイス内蔵のソフトが起動する時と同時に稼動を開始します。

両種のエージェントは予め準備されたプラットフォーム・エンドポイントURLが設定されています。このプラットフォーム・エンドポイントURLよりそれぞれの接続デバイスの証明書を取得します。 この証明書により、デバイスは Things Cloud のテナントへ接続が許可され、テナントへデータを送信することができ、そしてテナントからの管理されることを許可します。

起動後、エージェントは任されたセンサーのサブ・ネットワークのインベントリと同期します。

インベントリの同期

インベントリの同期については Things Cloud のドメインモデルで記述された通信階層を再度ご覧ください. インベントリ内ではエージェントは通信階層のルートに配置されています。エージェントの下にはエージェント管理下のサブ・ネットワークのトポロジーが表されます。このトポロジーは実際のネットワークにも存在し、インベントリのスナップショットにも存在します。実際のネットワークで変更があれば、インベントリ内にもその変更が反映されなくてはなりません。

Communication hierarchy

インベントリ同期は二つの手順を踏みます。一つ目はエージェントのエントリをインベントリに照会し、もし存在しない場合は新しく作成します。二つ目はサブ・ネットワークの存在を認識し、照会されたエージェントエントリを元にインベントリと同期させます。

最初の手順ではエージェントエントリの一部としてエージェントにコンフィグ情報を渡す可能性の提供します。このコンフィグ情報はエージェントの種類と接続されたデバイスに依存します。 測定のためのポーリング間隔の情報が含まれていたり、エージェントが自動的に関連ネットワークを認識できなかった場合にサブ・ネットワークの責任を割り当てが可能です。

例えば、携帯電話にインストールされたエージェントはこれ以上のコンフィグ無しでbluetoothで接続された心拍モニターを見つけることができます。また、ローカルのIPネットワークにインストールされたエージェントはローカル・ネットワーク上で検索手順を実行することができます。

インベントリ情報を最新のものに維持し、デバイスの一元可視化を保全するために二つのメカニズムが使われています:

  • 定期的にトリガーされたインベントリアップロード。エージェント起動時に始まり、その後も定期的に作動。
  • エージェントが作動中に起こる個々の変更を伝達。

定期的なインベントリ同期は接続された特定のデバイス・プロトコール(変更通知へ対応しない場合もあるので)に依存します。例えば、あるデバイスがローカルでコントロールボタンを押すか、ローカルにあるデバイス・マネージャーのみで作動するとします。この場合、デバイス・プロトコルが変更を伝達しないかぎり、その変更はデバイスを定期的に照会しなければ見つかりません。もう一つの例えとして、新デバイスの追加が定期的なネットワークのアドレスの範囲をスキャンしないと気づかれない環境にあるとします。この場合エージェントがこの役割を担うことになります。

ここではdevice エージェントがデバイス・トポロジー、コンフィグ・プロパティの所有権を保持し、インベントリ上の情報を上書きしてもよいことを前提にしています。

アプリケーションよりデータとコマンドを受け取る

インベントリ内でのトポロジーが成立したところで、デバイスはIoTアプリケーション上で可視化され、運用できるようになりました。 Things Cloud のドメインモデルのデバイス制御の章で記述されているように、IoTアプリケーションはオペレーションをデバイスへ送信し、これがコアでキューされます。そして、エージェントはデバイスの対象オペレーションをコアに照会することになります。

もしエージェントのデバイスへオペレーションが送信されたら、エージェントはこのオペレーションをデバイス特有の表現に変換します。

最後にエージェントはこのオペレーションを解釈し、実行します。同時にインベントリのアップデートも必要になるでしょう。上記の例ではインベントリ上でスイッチの状態をアップデートしています。

感知情報、イベント、アラームと監視ログの送信

デバイス遠隔操作の他にエージェントのもう一つの主な役割はセンサーからデータを送ることです。ドメインモデルでも概説されましたが、このデータは以下のような多種多様なものになります:

  • センサーの値を読み込むこどで出された測定値。センサーからのデータが定期的な間隔で読み込まれ、プラットフォームへ送信されることもあります。(気温センサーや電力メーターなど)データがオンデマンドで読み込まれたり、不定期に読み込まれる場合もあります。(健康器具や体重計など)デバイスがどのようなプロトコルに対応していても、エージェントはこれらを Things Cloud へアップロードすることで"push" プロトコルに変換する役割があります。
  • IoTアプリケーションにより、ほぼリアルタイムでプロセスする必要があるイベント。例えば、動作探知機からの通知や自動販売機の使用状況など。
  • アラーム=人の介入が必要なイベントのことです。例えば、電力メーターから送られた改ざん形跡など。
  • 監視ログはリスクマネジメント用に記録されたイベントです。例えばログオン失敗など。

エージェントのコンフィグのアップデート

エージェントコンフィグはランタイム中に変更が必要になるかもしれません。例えば、センサーに新しいゲートウェイがインストールされたとすると、その時エージェントにゲートウェイ接続用の新しいアドレスと認証を送る必要があります。この変更はデバイスコントロールへエージェント自身を対象にリクエストを送ることで可能になります。コンフィグをプロセスした後エージェントはデバイス・ネットワークの変更に必要なものをアップロードします。

他のデータ・ソースとの統合

システム統合

IoTサービスを提供する企業の多くはIoT機器やデバイスに重要な情報を提供する他のITシステムを作動させます。例えば:

  • 機器管理システム上で利用可能なデバイスとその位置などを提供。
  • お客さま管理システム上でデバイスを所持しているお客さまの情報などを提供。
  • 稼動管理システム上でデバイスの保守状況の情報を提供。

技術的にシステム統合のためのエージェントを開発し走らせる方法はデバイス統合のエージェントとそう変わりません。しかし、システムの所有するサブセットのデータは異なります。デバイス統合のエージェントはデバイス階層とデバイスのコンフィグ情報を所有します。システム統合のエージェントはデバイスに追加情報を提供し、資産階層の一部を所有することがあります。両エージェントの情報はインベントリ内に保存され、これらの情報でIoTサービスに関連した機器やデバイス情報の一元可視化を提供します。

エージェント開発に対しどのようなサポートを提供していますか?

Things Cloud は3つの異なるレベルでのエージェント開発をサポートしています:

  • Things Cloud の bitbucket.org と mbed.org リポジトリには,フル機能のオープンソースエージェントとドライバが多数公開されていいます。詳細については、このドキュメントの「デバイス」セクションをご参照ください。
  • C/C++、JavaME/SE、Luaなどの主要なランタイム環境用のクライアントライブラリは、同じくbitbucket.org上にオープンソースとして公開されています。
  • 他の実行環境用に技術的に中立なREST APIを提供しています。