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

概要

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

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

関連トピックは次のセクションをご覧ください。

• Things Cloud のドメインモデル ：エージェントと Things Cloud のコアとの間で交換されるデータ構造について
• デバイス統合ガイド：REST または MQTTプロトコルを使用してエージェントソフトウェアを開発する方法の詳細
• REST の実装：エージェントと Things Cloud のコア間のインターフェースの仕様の詳細

エージェントとは?

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

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

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

プロトコル変換

コンフィグのパラメータ、データ情報、イベントや他の情報は一方より特定デバイスプロトコルを通じてエージェントへ送信(push) されるかエージェントにより照会(pull)されます。エージェントはこれらのデータを 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種類あります。サーバーサイド エージェント とデバイスサイド エージェントです。

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

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

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

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

エージェントの起動

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

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

起動後、エージェントは担当するセンサーのサブネットワークのインベントリと同期します。

インベントリの同期

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

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

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

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

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

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

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

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

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

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

エージェントのデバイスへオペレーションが送信された場合、エージェントはこのオペレーションをデバイス特有の表現に変換します。たとえば、Multispeakエージェントは、スイッチの状態を設定するオペレーションを電力メーター用のSOAP “initiateConnectDisconnect(初期接続切断)” リクエストに変換します。そして、変換されたオペレーションがデバイスに送信されます。

最後にエージェントはこのオペレーションを解釈し、実行します。同時にインベントリ上でスイッチの状態をアップデートをします。

センサー読取情報、イベント、アラームと監視ログの送信

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

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

エージェント構成の更新

エージェントの構成は実行中に変更が必要になる場合があります。例えば、センサーに新しいゲートウェイがインストールされたとすると、そのときエージェントにゲートウェイ接続用の新しいアドレスと認証を送る必要があります。この変更はデバイスコントロールへエージェント自体を対象にリクエストを送ることで可能になります。構成を処理した後、エージェントはデバイス・ネットワーク内で変更を公開します。

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

システム統合

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

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

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

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

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

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