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

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

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

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

エージェントとは?

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

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

  • デバイスの特定インターフェース プロトコルを個別の参照プロトコルへ変換
  • デバイスの特定ドメインモデルを参照ドメインモデルへ変換
  • さまざまなネットワーク アーキテクチャで安全なリモート通信を確立

エージェントアーキテクチャ

プロトコル変換

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

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

モデル変換

構成のパラメータ、データ情報、イベントはデバイス固有の名称(場合によって固有の単位)があります。特定デバイスのエージェントは、このデバイス固有モデルを Things Cloud 参照モデルへ変換します。例えば、電力メーターは「Received Wh」パラメータとして主要な読み取り値を提供するため、エージェントはこの読み取り値を kWh の参照データ「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 ネットワークにインストールされたエージェントはローカルネットワーク上で検索手順を実行することができます。Multispeak エージェントとは異なり、接続されたスマートメーターを検出するために Multispeak サーバーの URL と資格情報が必要です。

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

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

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

重要なのは、デバイスエージェントがデバイストポロジー、構成プロパティの所有権を保持し、インベントリ上の情報を変更または上書きしてもよいことを前提にしています。

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

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

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

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

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

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

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

エージェント構成の更新

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

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

システム統合

IoTサービスを提供する企業の多くは、IoT 機器やデバイスに重要な情報を提供する他のITシステムを運用しています。これらのシステムの例は、次の通りです。

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

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

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

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