(57)【要約】【課題】機器の接続作業の負荷を軽減する。【解決手段】機器から受信されるデータをデータの収集装置へ送信する通信装置において、接続が要求された機器のプロファイル情報を取得する取得部と、プロファイル情報と通信装置に収容する機器の設計情報とに基づいて接続が要求された機器の接続可否を判定する判定部とを含む。【選択図】図１
2018107684.tif 000002
【特許請求の範囲】
【請求項１】
機器から受信されるデータを前記データの収集装置へ送信する通信装置において、
接続が要求された機器のプロファイル情報を取得する取得部と、
前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する判定部と、
を含む通信装置。
【請求項２】
前記取得部は、前記接続が要求された機器と前記通信装置との通信に使用される通信メディアに基づいて前記接続が要求された機器から前記プロファイル情報を取得する請求項１に記載の通信装置。
【請求項３】
前記判定結果において接続許可と判定された機器と同種の機器が既に前記通信装置に収容されている場合に、前記接続許可と判定された機器を通信不可の状態にする制御部
をさらに含む請求項１に記載の通信装置。
【請求項４】
前記通信装置に接続されている機器の設置場所に係る情報を受信し、前記通信装置と接続されている機器の情報を含む構成情報に含める管理部
をさらに含む請求項１に記載の通信装置。
【請求項５】
前記設計情報が更新された場合に、更新された設計情報に整合しないプロファイル情報を有する機器を通信不可の状態にする制御部
をさらに含む請求項１に記載の通信装置。
【請求項６】
前記判定結果において接続許可と判定された機器のうち所定内容のプロファイル情報を有する機器を監視対象に設定し、異常が検出された監視対象の機器を通信不可の状態にする監視部
をさらに含む請求項１に記載の通信装置。
【請求項７】
前記監視部は前記監視対象に設定されてから所定時間異常が検出されない機器を監視対象から除外する
請求項６に記載の通信装置。
【請求項８】
前記収集装置から受信されるメッセージによって特定される機器のプロファイル情報の内容と前記収集装置で実行されるアプリケーションとの関係に基づいて定められたポリシに係る処理を実行するポリシ管理部をさらに含む
請求項１に記載の通信装置。
【請求項９】
データを出力する機器と、
前記データを受信して前記データの収集装置に送信する通信装置とを含み、
前記通信装置は、接続が要求された機器のプロファイル情報を取得する取得部と、前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する判定部と、を含む通信システム。
【請求項１０】
データを出力する機器において、
前記データを受信して前記データの収集装置へ送信する通信装置へ接続要求を送る処理と、前記通信装置からの要求に応じて前記機器のプロファイル情報を前記通信装置へ送信する処理とを行う制御部
を含む機器。
【請求項１１】
機器からのデータを受信して前記データの収集装置へ送信する通信装置のコンピュータに、
接続が要求された機器のプロファイル情報を取得し、
前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する
処理を実行させるプログラム。
【請求項１２】
機器からのデータを受信して前記データの収集装置へ送信する通信装置が、
接続が要求された機器のプロファイル情報を取得し、
前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する
ことを含む通信装置の通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置，通信システム，機器，プログラム及び通信制御方法に関する。
【背景技術】
【０００２】
近年、Internet of Things（ＩｏＴ）サービスが普及しつつある。ＩｏＴサービスは、インターネットに接続された多数の機器（デバイスともいう）を用いて大量のデータを収集し、サービス提供に用いたり、機器などにフィードバックしたりする。
【０００３】
ＩｏＴサービスを利用するためには、データの収集場所にデバイスを設置し、さらに、デバイスとクラウドサービスとの通信を中継するゲートウェイ（ＧＷ）が設置される。デバイスが備える通信メディアがBluetooth（登録商標）やシリアル通信などの非ＩＰ（Internet Protocol）系通信であり、インターネットと直接通信できない場合にＧＷは設置される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−３０２２９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
データの収集場所に設置されたデバイスを適正に制御するために、デバイスとＧＷとが事前のシステム設計に基づいて接続される。接続作業を行う作業員は、設置対象の各デバイスのプロファイル情報を確認し、プロファイル情報が設計内容と合致するかを逐一確認する。
【０００６】
プロファイル情報は、例えば、デバイスのベンダが提供するデータシートに記載されている。或いはプロファイル情報は、デバイスに刻印されたり貼付されたりしている。或いは、デバイスに作業用端末を接続し、コマンド実行により画面上にプロファイル情報を呼び出す場合もある。このように、プロファイル情報の保存箇所や入手方法は様々であるため、プロファイル情報の確認作業は作業員にとって煩雑で手間のかかる作業であった。設置されるデバイスの数が多くなるほど、作業員への負荷が大きくなる。
【０００７】
本発明は、機器の接続作業の負荷を軽減可能な通信装置，通信システム，機器，プログラム及び通信制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一つの態様は、機器から受信されるデータをデータの収集装置へ送信する通信装置である。この通信装置は、接続が要求された機器のプロファイル情報を取得する取得部と、プロファイル情報と通信装置に収容する機器の設計情報とに基づいて接続が要求された機器の接続可否を判定する判定部とを含む。
【発明の効果】
【０００９】
一側面では、機器の接続作業の負荷を軽減することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は実施形態１に係るデータ収集システムの構成例を示す図である。
【図２】図２はデバイス１及びＧＷ２のハードウェア構成例を示す図である。
【図３】図３は設計情報管理テーブルのデータ構造例を示す。
【図４】図４はデバイスプロファイルの一例を示す。
【図５】図５は構成情報管理テーブル２４ｂ（テーブル２４ｂ）のデータ構造例を示す図である。
【図６】図６は実施形態１の動作例を説明するシーケンス図である。
【図７】図７は構成情報管理テーブル２４ｂに情報が追加された様子を示す。
【図８】図８は設計情報管理テーブル２４ａの変形例を示す。
【図９】図９は実施形態１におけるＧＷ２のデバイス接続処理の例を示すフローチャートである。
【図１０】図１０はクラウドサービス（サーバ４）がデバイス１とデータ通信を行う場合におけるＧＷ２の処理を示すフローチャートである。
【図１１】図１１はクラウドサービス（サーバ４）へデバイス１がデータを送信する場合におけるＧＷ２の処理を示すフローチャートである。
【図１２】図１２はシステムが複数のＧＷ２を有する場合の構成例を示す。
【図１３】図１３は管理サーバ４ａで管理される情報とＧＷ２で管理される情報との関係を示す。
【図１４】図１４は実施形態２の構成例を示す。
【図１５】図１５は実施形態２における構成情報管理テーブル２４ｂのデータ構造例を示す。
【図１６】図１６は実施形態２における作業者端末のハードウェア構成例を示す。
【図１７】図１７は実施形態３における設計情報更新時における処理例を示すフローチャートである。
【図１８】図１８は実施形態４の構成例を示す図である。
【図１９】図１９は監視対象基準情報管理テーブル２８ａのデータ構造例を示す。
【図２０】図２０は記憶領域２８Ａに記憶される通信履歴管理テーブル２８ｂのデータ構造例を示す。
【図２１】図２１は実施形態４におけるデバイス接続処理の例を示すフローチャートである。
【図２２】図２２は実施形態４のＧＷ２で行われる監視処理の一例を示すフローチャートである。
【図２３】図２３は実施形態５の構成例を示す。
【図２４】図２４はポリシ管理テーブル２９ａのデータ構造例を示す。
【図２５】図２５は実施形態５におけるデバイス１とサーバ４との通信時におけるＧＷ２の処理例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、通信装置，機器接続可否判定方法，及びプログラムの実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１２】
実施形態では、一例として、データを機器（デバイス）から収集するためのシステム（データ収集システム）について説明する。データはＩｏＴサービスを提供するために使用される。ＩｏＴサービスはクラウドサービスとして提供され得る。
【００１３】
機器（デバイス）から出力されるデータはゲートウェイ装置（ＧＷ）に受信される。ＧＷは、データをデータの収集装置（例えば、データを処理する情報処理装置）へ送信される。データの収集装置は、例えばＩｏＴサービスを提供するサーバである。ＩｏＴサービスはクラウドサービスとして提供され得る。
【００１４】
ＧＷは、機器（デバイス）が備える通信メディアとデバイスプロファイル（プロファイ
ル情報の一例）の取得方法との対応関係を管理する。デバイスとゲートウェイ装置（ＧＷ）とのリンク接続を契機に、ＧＷが通信メディアに応じたプロファイル取得処理を実行し、デバイスからプロファイルを自動的に取得する。
【００１５】
例えば、デバイスがＧＷとBluetooth Low Energy（ＢＬＥ）に従って通信する場合は、ＧＷはＢＬＥの仕様上規定されているDevice Information Service（ＤＩＳ）を用いてプロファイルを取得する。デバイスがＧＷとＩＰ通信を行う場合は、ＧＷはUniversal Plug
and Play（ＵＰｎＰ）やHome-network Topology Identifying Protocol（ＨＴＩＰ：ホ
ームネットワーク接続構成特定プロトコル）などの処理を自動的に実行し、プロファイルをデバイスから取得する。ＵＰｎＰは、機器を通信ネットワークに接続すると複雑な設定作業なく即座に他の機器との通信や他の機器の機能を利用可能とするプロトコルである。
【００１６】
ＧＷはプロファイルと設計情報との照合を行い、プロファイルと設計情報とが整合する場合に接続を許可する。これに対し、プロファイルと設計情報とが整合しない場合は、デバイスを通信不可の状体にする。例えば、リンクの切断や通信不可の設定を行う。
【００１７】
設計情報はデバイスのベンダ名、製品名、温度センサなどデバイスがデータ収集のために有する機器または機能や、デバイスがＧＷとの通信に用いる通信メディアなどの情報である。設計情報はデバイスのシリアル番号のような個々のデバイスを特定する情報は含まない。通信遮断を実現する方法として、通信メディアやデータの収集場所（デバイス１の設置場所、現場ともいう）のネットワーク構成に応じた方法が選択される。
【００１８】
例えば、ＢＬＥのように、デバイスがＧＷに直接に収容される場合にはＧＷは明示的に切断を指示する。また、ＧＷ２は通信メディアが切断用インタフェース（ＩＦ）を提供する無線ＬＡＮのアクセスポイントである場合にも明示的な切断指示を行う。これに対し、シリアル通信のように切断に物理的な操作を要する場合にはＧＷ２はアプリケーション層（レイヤ７）での通信を禁止する。このようにして、デバイスを通信不可の状態にする。
【００１９】
＜構成＞
図１は、実施形態１に係るデータ収集システムの構成例を示す図である。システムは、ＩｏＴサービスのためのデータ収集用のデバイスをＧＷが事前設計に合致する状態で収容するために使用される。システム設計者５が設計情報を事前にＧＷに登録しておく。データ収集場所（現場）で作業員が接続作業を行うデバイスのプロファイルが設計情報に合致する場合にＧＷへの収容を許可される。
【００２０】
図１において、データ収集システムは、データを収集する単数または複数のデバイス１を収容するゲートウェイ装置（ＧＷ）２と、ＧＷ２とネットワーク（例えばインターネット）３ｂを介して通信するサーバ４とを含む。サーバ４は、デバイス１から収集されるデータを用いてＩｏＴサービスを提供する。サーバ４は例えばＩｏＴサービスをクラウドサービスとして提供するサーバとしてネットワーク３ｂに接続される。ＧＷ２は「通信装置」の一例であり、デバイス１は「データを出力する機器」の一例であり、サーバ４は「データの収集装置」の一例である。
【００２１】
ＧＷ２は、デバイス接続の制御部２１と、接続可否の判定部２２と、デバイスプロファイルの取得部２３と、情報の管理部２４と、記憶領域２４Ａと、データ通信の中継部２５とを含む。制御部２１は、通信メディアに固有なロジックに従って様々なデバイス１との接続を制御する。判定部２２は、デバイス接続検出を契機に、設計情報とデバイスプロファイルとを照合し、接続可否判定を行う。通信メディアは、ＢＬＥ，Bluetooth（ＢＬＥ
以外），ＩＰ，Universal Serial Bus（ＵＳＢ），有線ＬＡＮ（Local Area Network），無線ＬＡＮ（WiFi含む），ZigBee，シリアル通信などである。但し、これら以外の通信メ
ディアが適用されても良い。デバイスプロファイルは、「プロファイル情報」の一例である。
【００２２】
取得部２３は、制御部２１を利用し、デバイス１の通信メディアに応じた方法（ロジック）に従って、デバイスプロファイルをデバイス１から取得する。上述したように、デバイス１とＧＷ２とがＢＬＥに基づく通信を行う場合には、取得部２３はＤＩＳを用いてプロファイルをデバイス１から取得する。デバイス１とＧＷ２とがＩＰ通信を行う場合には、取得部２３はＵＰｎＰやＨＴＩＰを用いてプロファイルをデバイス１から取得する。
【００２３】
管理部２４は、記憶領域２４Ａに記憶されるシステムの設計情報と実際に構築されたシステム情報（構成情報ともいう）を管理する。管理部２４は、判定部２２のデバイス情報の検索要求を処理したり、システム情報を更新したりする。中継部２５は、デバイス１のＧＷ２への収容後に、デバイス１とサーバ４（クラウドサービス）間のデータ通信を中継する。すなわち、中継部２５は、デバイス１からサーバ４宛のデータを受信してサーバ４へ向けて転送したり、サーバ４から受信されるデバイス１宛のデータをデバイスへ転送したりする。
【００２４】
図２はデバイス１及びＧＷ２のハードウェア構成例を示す図である。デバイス１は、一例として、バスを介して相互に接続されたCentral Processing Unit（ＣＰＵ）１１と、
一次記憶１２と、二次記憶１３と、通信インタフェース（通信ＩＦ）１４と、入力装置１５と、出力装置１６と、センサ１７とを含む。
【００２５】
ＧＷ２は、一例として、バスを介して相互に接続されたＣＰＵ３１と、一次記憶３２と、二次記憶３３と、通信インタフェース（通信ＩＦ）３４ａと、通信ＩＦ３４ｂと、入力装置３５と、出力装置３６とを含む。
【００２６】
一次記憶１２、一次記憶３２は、主記憶装置である。主記憶装置はプログラムの展開領域、ＣＰＵの作業領域、データやプログラムの記憶領域、通信データのバッファ領域などとして使用される。主記憶装置は、例えばRandom Access Memory（ＲＡＭ）、ＲＡＭとRead Only Memory（ＲＯＭ）との組み合わせで形成される。
【００２７】
二次記憶１３、二次記憶３３は、補助記憶装置である。補助記憶装置はデータやプログラムの記憶領域として使用される。補助記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ）、Solid State Drive（ＳＳＤ）、フラッシュメモリ、Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲＯＭ）などの不揮発性記憶媒体で形成される。補助記憶装置は、ディスク型記憶媒体を含むことができる。主記憶装置と補助記憶装置とのそれぞれは、「記憶装置」、「記憶媒体」、「メモリ」、「記憶部」の一例である。
【００２８】
図２に示す例では、二次記憶１３は、プロファイル管理プログラムと、デバイスプロファイルと、デバイス制御プログラムとを記憶する。但し、一次記憶１２がこれらの一部を記憶しても良い。プロファイル処理プログラムとデバイス制御プログラムはＣＰＵ１１により実行されることで、ＧＷ２からのデバイスプロファイル要求に対する応答、センシングおよびセンシング結果の送信、デバイス１の制御を行う。また、二次記憶３３は、接続制御プログラムと、設計情報と、構成情報とを記憶する。但し、一次記憶３２がこれらの一部を記憶しても良い。
【００２９】
通信ＩＦ１４、通信ＩＦ３４ａ、通信ＩＦ３４ｂは通信処理を司る。通信ＩＦ１４及び通信ＩＦ３４ａは、ネットワーク３ａを用いた通信に係る処理を行う。ネットワーク３ａは、ＢＬＥ，有線ＬＡＮ，無線ＬＡＮなどである。通信ＩＦ３４ｂは、ネットワーク３ｂを介したサーバ４との通信に係る処理を行う。ネットワーク３ｂは、たとえば、有線ＬＡ
Ｎ，無線ＬＡＮ，３Ｇや４Ｇの無線網，シリアル通信網などである。通信ＩＦ３４ｂには例えばNetwork Interface Card（ＮＩＣ）が使用される。
【００３０】
入力装置１５及び入力装置３５のそれぞれは、例えば、キー、ボタン、ポインティングデバイス（マウスなど）、タッチパネル、音声入力装置（マイクロフォン）などである。出力装置１６及び出力装置３６のそれぞれは、例えばディスプレイ、プリンタ、スピーカ、ランプなどである。
【００３１】
ＣＰＵ１１及びＣＰＵ３１のそれぞれは、二次記憶１３（二次記憶３３）に記憶されたプログラムを一次記憶１２（一次記憶３２）にロードして実行する。プログラムの実行によって、デバイス１及びＧＷ２としての動作が行われる。ＣＰＵ１１はＧＷ２からの要求に応じてデバイスプロファイルを供給する処理や、センサ１７によって取得されたデータをＧＷ２に送信する処理などを行う。ＣＰＵ１１は、「データを受信してデータの収集装置へ送信する通信装置へ接続要求を送る処理と、前記通信装置からの要求に応じて前記機器のプロファイル情報を前記通信装置へ送信する処理とを行う制御部」の一例である。
【００３２】
ＣＰＵ３１は、プログラムの実行によって、図１に示した制御部２１，判定部２２，取得部２３，管理部２４，中継部２５として動作する。一次記憶３２及び二次記憶３３の少なくとも一方は記憶領域２４Ａとして使用される。ＣＰＵ３１は、「取得部」，「判定部」，「管理部」，「制御部」の一例である。
【００３３】
ＣＰＵ（ＣＰＵ１１及びＣＰＵ３１のそれぞれ）は、「制御装置」、「制御部」、「コントローラ」、「プロセッサ」の一例である。ＣＰＵは、ＭＰＵ（Microprocessor）、プロセッサとも呼ばれる。ＣＰＵは、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。ＣＰＵ１１で行われる処理の少なくとも一部は、マルチコア又は複数のＣＰＵで実行されても良い。ＣＰＵで行われる処理の少なくとも一部は、ＣＰＵ以外のプロセッサ、例えば、Digital Signal Processor(ＤＳＰ)、Graphics Processing Unit（ＧＰＵ）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われても良い。
【００３４】
また、ＣＰＵ（ＣＰＵ１１及びＣＰＵ３１のそれぞれ）によって行われる処理の少なくとも一部は、集積回路（ＩＣ）、その他のディジタル回路で行われても良い。また、集積回路やディジタル回路はアナログ回路を含んでいても良い。集積回路は、ＬＳＩ、Application Specific Integrated Circuit（ＡＳＩＣ）、プログラマブルロジックデバイス（
ＰＬＤ）を含む。ＰＬＤは、例えば、Field-Programmable Gate Array(ＦＰＧＡ)を含む
。ＣＰＵで行われる処理の少なくとも一部は、プロセッサと集積回路との組み合わせにより実行されても良い。組み合わせは、例えば、マイクロコントローラ（ＭＣＵ）、ＳｏＣ（System-on-a-chip）、システムＬＳＩ、チップセットなどと呼ばれる。
【００３５】
ＧＷ２のデバイス１の接続時における動作は以下の通りである。前提として、システム設計者５は、システムの設計情報を記憶領域２４Ａに事前に（予め）登録しておく。図３は、設計情報管理テーブル２４ａ（テーブル２４ａ）のデータ構造例を示す。
【００３６】
テーブル２４ａは各デバイスに対応するエントリを有する。エントリは機器の識別子と、属性を示す情報と、通信メディアを示す情報とを含む。機器識別子は、システムを構成するデバイスの識別子である。属性情報は、デバイス１が有する特性などの、システムを構成する機器を特定する情報を含む。一例として、図３では、ベンダ名，製品名及び機能が属性情報の要素に含まれている。但し、個々のデバイスを特定する情報までは含まれない。通信メディアはデバイス１がＧＷ２への接続に用いる通信メディアを示す。
【００３７】
図３に示す例では、”device#1”の識別子で識別されるデバイス＃１は、ベンダ名”vvvv”であり製品名”aaaa”であり、機能“温度センサ”を備える。また、”device#1”はＢＬＥにしたがってＧＷ２に接続される。”device#2”の識別子で識別されるデバイス＃２は、ベンダ名”uuuu”、製品名”bbbb”、及び機能“照度センサ”を備える。また、”device#2”はＩＰにしたがってＧＷ２に接続される。
【００３８】
図４は、デバイスプロファイルの一例を示す。デバイスプロファイルは、ベンダ名、製品名、機能を示す情報、シリアル番号や型番などの個体識別情報を含む。
【００３９】
図５は、構成情報管理テーブル２４ｂ（テーブル２４ｂ）のデータ構造例を示す図である。テーブル２４ｂは、各デバイスに対応するエントリを有する。エントリは機器識別子と、属性を示す情報と、通信メディアを示す情報と、ローカル識別子とを含む。
【００４０】
機器識別子は機器（デバイス１）の識別子である。属性を示す情報はシステムを形成する個々の機器を特定する属性を示す情報である。属性を示す情報は、ベンダ名，製品名，機能のそれぞれを示す情報に加えて、シリアル番号や型番のよう個々のデバイス１を識別又は特定する情報を含む。通信メディアはデバイス１がＧＷ２への接続に用いる通信メディアを示す。ローカル識別子は、クラウドサービス（サーバ４）からのデバイスアクセス要求に応じて、ＧＷ２が所定の通信メディアで機器（デバイス１）にアクセスする場合に使用される識別子（アドレス）である。
【００４１】
＜動作例＞
以下、実施形態１における動作例について説明する。図６は実施形態１の動作例を説明するシーケンス図である。制御部２１は、ＧＷ２が備えている各通信メディアに応じた通信を待ち受ける。例えば、ＧＷ２がＢＬＥ用の通信ＩＦ３４ａを備えている場合は、デバイス１であるＢＬＥデバイスのスキャンを定期的に実施し、ＢＬＥデバイスがＧＷ２の近傍でリンク接続要求を送信（アドバタイズ：図６＜１＞参照）するのを待つ。
【００４２】
制御部２１はアドバタイズ（リンク接続要求）を検出すると、自動的に接続要求をデバイス１に送信し、接続処理を行う（図６＜２＞）。この接続はデバイスプロファイルの取得するために行われる仮の接続である。この一連の動作は、現場作業者がＧＷ２と通信可能な現場作業用の端末から指示を与えることで実施されても良い。
【００４３】
制御部２１は、デバイス１とＧＷ２との接続を検出すると、デバイス通信メディアとデバイス通信メディアにおけるデバイスの識別子とを判定部２２に通知する（図６＜３＞）。例えば、通信メディアがＢＬＥである場合では、デバイスの識別子はデバイス１のＢＤ（Bluetooth Device）アドレスである。デバイス１がＩＰ通信デバイスである場合は、デバイスの識別子はＭＡＣアドレスなどである。
【００４４】
取得部２３は、判定部２２からデバイスファイル取得の指示を受けて（図６＜４＞）、デバイス１の通信メディアに応じたデバイスプロファイルの取得方法を決定する。決定した方法を用いてプロファイルを取得する（図６＜５＞〜＜８＞）。すなわち、ＧＷ２からプロファイルの提供要求が送信され（図６＜５＞、図６＜６＞）、デバイス１がプロファイル（図４）をＧＷ２へ送信する（図６＜７＞、図６＜８＞）。
【００４５】
例えば、通信メディアがＢＬＥの場合、制御部２１のＢＬＥ接続を経由して、ＤＩＳによりベンダ名，製品名，シリアル番号などの情報をプロファイルとして取得する。デバイス１がＩＰ通信デバイスである場合は、ＵＰｎＰによりプロファイル取得を行う。ＵＰｎＰによるデバイス探索は、マルチキャスト通信を行うので、複数のデバイスからの応答が
受信される可能性がある。この場合、通信メディアにおけるデバイス識別子（ＩＰの場合、ＭＡＣ（Media Access Control）アドレス）を利用し、目的のデバイスを特定する。
【００４６】
なお、すべてのＩＰ通信デバイスがＵＰｎＰに対応しているとは限らない。この場合、例えば、デバイス１のＭＡＣアドレス（接続要求に含まれる）とデバイス１の属性情報を記憶するデータベース（ＤＢ）を予め用意し、ＤＢを参照しても良い。また、デバイス１がデバイス１自身のプロファイルを送信する機能を有していても良い。
【００４７】
判定部２２は、取得部２３からデバイス１のプロファイルを取得すると（図６＜９＞）、管理部２４に通信メディア名及びプロファイルを渡す（図６＜１０＞）。管理部２４はプロファイルにマッチする設計情報を検索する。具体的には、管理部２４は設計情報管理テーブル２４ａ（図３）を参照し、デバイス１から得られた情報と「通信メディア」が一致し、「属性」に示す情報がプロファイルに含まれているエントリを検索する。管理部２４は検索されたエントリに含まれる機器識別子をデバイス１の識別子として決定する。検索された設計情報は判定部２２に渡される（図６＜１１＞）。
【００４８】
例えば、デバイス１であるＢＬＥデバイスから図４に示す内容のプロファイルが取得された場合を仮定する。このプロファイルは、図３に示す内容の設計情報管理テーブル２４ａにおける“device#1”にマッチする。この場合、デバイス１に識別子“device#1”が割り当てられる。
【００４９】
「属性」中の「機能」に関しては、設計情報に指定されている機能がプロファイルに含まれていれば良い。また、場合によっては、設計情報が複数のベンダ名や製品名を指定する場合がある。或いは、所定機能を有するデバイスであればベンダ名及び製品名を問わない運用が考えらえる。これらの場合、設計情報（テーブル２４ａ）の「属性」に複数のベンダ名、製品名、機能に関する候補や正規表現を記述しても良い。
【００５０】
管理部２４は接続済みの機器（デバイス１）の情報を管理する構成情報管理テーブル２４ｂ（図５）を検索し（図６＜１２＞）、判定部２２に渡す（図６＜１３＞）。この処理はまだ該当する機器（デバイス１）が接続されていないことを確認するために行われる。複数の同種のデバイス１が重複してＧＷ２に収容されるのを回避するためである。
【００５１】
判定部２２は、設計情報及び構成情報に基づき、接続可否の判定を行う。例えば、設計情報として識別子“device#1”又は識別子“device#1”を含むテーブル２４ａエントリを受け取り、構成情報として識別子“device#1”に合致するテーブル２４ｂのエントリを受け取った場合を仮定する。
【００５２】
テーブル２４ｂのエントリが図５に示す内容である場合、識別子“device#1”が割り当てられたデバイス１は、テーブル２４ｂの登録内容からまだＧＷ２に収容されていないことが分かる。従って、判定部２２は、接続を許可する。このとき、例えば現場作業員の端末を通じて、最終的に接続してよいかどうかの確認を作業員に求めても良い。
【００５３】
判定部２２は制御部２１に、判定結果（許可又は拒否）を返却する（図６＜１４＞）。判定結果が「許可」の場合は、仮の接続を正式な接続として扱うための処理を行う。処理が不要な場合もある。拒否の場合、明示的な切断可能な通信メディアであれば切断処理が行われ、そうでなければリンク接続はそのままで、クラウドサービス（サーバ４）とデバイス１との間のデータ中継が禁止される。
【００５４】
接続が完了すると、制御部２１は接続処理の結果を判定部２２に通知し（図６＜１５＞）、判定部２２は実際に接続されたデバイスのプロファイルの登録を管理部２４に指示す
る（図６＜１６＞）。管理部はプロファイルを構成情報（テーブル２４ｂ）に登録する。登録によって、テーブル２４ｂの内容が図７に示す内容となる。
【００５５】
なお、設計情報管理テーブル２４ａの変形例として、図８に示すように、各エントリがデバイス１に対する設定情報を含み、デバイス１とＧＷ２との接続完了時に、管理部２４がデバイス１に設定情報に基づく設定を自動的に行う構成を採用し得る。
【００５６】
＜ＧＷにおけるデバイス接続処理＞
図９は、実施形態１におけるＧＷ２のデバイス接続処理の例を示すフローチャートである。図９に示す処理は例えばＧＷ２のＣＰＵ３１によって実行される。００１の処理では、ＧＷ２はデバイスの通信メディアに応じた手順に従い、デバイスとのリンク接続を確立する。
【００５７】
００２の処理では、ＧＷ２はリンク接続が確立した通信メディアと、この通信メディアにおけるデバイス識別子とを取得する。００３の処理では、ＧＷ２は通信メディアに対応した、デバイスプロファイル（単にプロファイルともいう）の取得処理（取得方法）を決定する。
【００５８】
００４の処理では、ＧＷ２はすべてのデバイスに係るプロファイルの取得処理の実行を開始する。００３で決定された取得方法に基づき、デバイス１にプロファイルの送信指示が送られる。デバイス１のＣＰＵ１１は、プログラムの実行により、通信ＩＦ１４で受信されるＧＷ２からのプロファイルの送信指示に応じて一次記憶１２及び二次記憶１３の少なくとも一方に記憶されたプロファイルを読み出し、通信ＩＦ１４から送信する処理を行う。
【００５９】
００５の処理では、ＧＷ２はデバイス１から送信されたプロファイルを取得できたか否かを判定する。プロファイルが取得できたと判定される場合には処理が００９に進み、そうでない場合には処理が００６に進む。
【００６０】
００６の処理では、ＧＷ２は取得処理がタイムアウトしたか否かを判定する。取得処理がタイムアウトしていないと判定される場合には処理が００５に戻る。これに対し、取得処理がタイムアウトしたと判定される場合には処理が００７に進む。
【００６１】
００７の処理では、ＧＷ２は事前に作成されたデータベースからプロファイルを取得する。００８の処理では、ＧＷ２はプロファイルを取得できたか否かを判定する。プロファイルが取得できたと判定される場合には処理が０１０に進み、そうでない場合には処理が０１７に進む。
【００６２】
００９の処理では、ＧＷ２は他の実行中の取得処理をすべて中断し、処理を０１０に進める。０１０の処理では、ＧＷ２は設計情報（テーブル２４ａ）から、取得したプロファイルとマッチ（合致）するデータを取得する。設計情報とプロファイルとのマッチは、例えば、ベンダ名，製品名，機能が一致することで行う。但し、ベンダ名，製品名，及び機能の少なくとも一つがマッチする場合でも、マッチするデータがあると判定することもできる。このようにマッチ条件に用いる要素を属性に含まれる複数の要素から適宜選択可能である。
【００６３】
０１１の処理では、ＧＷ２はプロファイルとマッチするデータがあるか否かを判定する。プロファイルとマッチするデータがあると判定される場合には処理が０１２へ進み、そうでない場合には処理が０１７に進む。
【００６４】
０１２の処理では、ＧＷ２は構成情報（テーブル２４ｂ）を検索し、既に接続済みのデバイスを検索する。０１３の処理では、ＧＷ２はデバイスが既に接続済みか否かを判定する。デバイスが既に接続済みと判定される場合には処理が０１７に進み、そうでない場合には処理が０１４へ進む。
【００６５】
０１４の処理では、ＧＷ２は仮の接続を正式な接続として扱うための接続作業を必要に応じて行う（不要な場合は何もしない）。０１５の処理では、ＧＷ２は接続作業が成功したか否かを判定する。接続作業が成功したと判定される場合には処理が０１６に進み、そうでない場合には処理が０１７に進む。
【００６６】
０１６の処理では、ＧＷ２は構成情報の更新処理を行い、図９の処理を終了する。０１７の処理では、ＧＷ２のＣＰＵ３１は制御部２１として動作し、ＧＷ２からデバイス１とのリンク切断が可能か否かを判定する。リンク切断が可能と判定される場合には、制御部２１として動作するＣＰＵ３１はリンク切断処理を実行する（０１８）。これに対し、リンク切断が不可能と判定される場合には、図９の処理が終了し、リンク接続が継続される。但し、デバイス１とサーバ４とが通信不可（通信禁止）の状態とされる。例えば、ＧＷ２にて、デバイス１からのデータがサーバ４への送信対象から除外される。
【００６７】
このように、プロファイルとマッチするデータが設計情報中にない場合、構成情報において既に同種の機器が収容されている場合、接続作業が失敗した場合には、デバイス１とデバイス１からのデータの宛先であるサーバ４との通信を禁止する処理が行われる。禁止する処理は、例えば制御部２１として動作するＣＰＵ３１によって行われる。禁止する処理は既に説明したように、デバイス１とＧＷ２とのリンクの切断やデバイス１とサーバ４とを通信不可とする処理を含む。
【００６８】
＜サーバ４とデバイス１との通信（サーバ４→デバイス１：ダウンリンク通信）＞
図１０は、クラウドサービス（サーバ４）がデバイス１とデータ通信を行う場合におけるＧＷ２の処理を示すフローチャートである。図１０に示す処理はＧＷ２のＣＰＵ３１によって実行される。
【００６９】
１０１の処理では、ＧＷ２（中継部２５）はクラウドサービス（サーバ４）からデータ取得やデバイス制御用のメッセージを受信する。１０２の処理では、ＧＷ２はメッセージに含まれたデバイスを指定する識別子（デバイス識別子）を抽出する。１０３の処理では、ＧＷ２（管理部２４）は構成情報（テーブル２４ｂ）を検索して、デバイス識別子と一致するデバイスプロファイルを取得する。
【００７０】
１０４の処理では、ＧＷ２はデバイスプロファイルが取得できたか否かを判定する。プロファイルが取得できたと判定される場合には処理が１０５に進み、そうでない場合には処理が１１０に進む。
【００７１】
１０５の処理では、ＧＷ２（制御部２１）はデバイスプロファイルに含まれる通信メディアとローカル識別子とを用いて、デバイス１にメッセージを送信する。１０６の処理では、ＧＷ２はメッセージを送信できたか否かを判定する。メッセージを送信できたと判定される場合には処理が１０７に進み、そうでない場合には処理が１１０に進む。
【００７２】
１０７の処理では、ＧＷ２はデバイス１から応答を受信する。１０８の処理では、ＧＷ２はデバイス１から応答を受信できたか否かを判定する。デバイス１から応答を受信できたと判定される場合には処理が１０９に進み、そうでない場合には処理が１１０に進む。
【００７３】
１０９の処理では、ＧＷ２は応答をクラウドサービス（サーバ４）へ送信し、図１０の
処理を終了する。１１０の処理では、ＧＷ２はエラーをクラウドサービス（サーバ４）へ送信し、図１０の処理を終了する。デバイス１がＧＷには収容されていないからである。
【００７４】
＜サーバ４とデバイス１との通信（デバイス１→サーバ４：アップリンク通信）＞
図１１は、クラウドサービス（サーバ４）とデバイス１とがデータ通信を行う場合におけるＧＷ２の処理を示すフローチャートである。図１１に示す処理は、デバイス１がサーバ４にデータを送信する場合に行われ、ＧＷ２のＣＰＵ３１によって実行される。
【００７５】
２０１の処理では、ＧＷ２はデバイス１からデータ通知メッセージを受信する。データ通知メッセージはサーバ４を宛先とするデータを含む。２０２の処理では、ＧＷ２はデータ通知メッセージに含まれるローカル識別子を抽出する。２０３の処理では、ＧＷ２は構成情報（テーブル２４ｂ）を検索して、通信メディアとローカル識別子とが一致（合致）するデバイスプロファイルを取得する。
【００７６】
２０４の処理では、ＧＷ２はデバイスプロファイルを取得できたか否かを判定する。デバイスプロファイルを取得できたと判定される場合には２０５へ処理が進み、そうでなければ図１１の処理が終了する。２０５の処理では、ＧＷ２はクラウドサービス（サーバ４）へデバイス１から受信したデータを送信し、図１１の処理を終了する。
【００７７】
＜システムに複数のＧＷ２を設ける場合＞
次に、システムに複数のＧＷ２を設ける場合の構成例について説明する。ここまで、ＧＷ２の数が１つの場合を例示した。現場によっては、デバイス１の数が１つのＧＷ２で収容可能な数を超過する場合がある。この場合は、図１２に示すように、複数のＧＷ２を管理する管理サーバ４ａを設置する。管理サーバ４ａは、ネットワーク３ｂ上に設置されても、ネットワーク３ｂに接続されるアクセスネットワーク（ローカルネットワーク）に接続されても良い。
【００７８】
管理サーバ４ａは、ＧＷ２のＩＰアドレスや各ＧＷ２が収容するデバイス１などの情報を管理し、クラウドサービス（サーバ４）との通信を仲介し、各ＧＷ２に対する管理の窓口となる機能を有する。管理サーバ４ａは、例えば、図２に示したＧＷ２が備えるハードウェア構成と同じ構成を有することができ、管理サーバ４ａのＣＰＵは、各ＧＷ２の設計情報（テーブル２４ａ）及び構成情報（テーブル２４ｂ）を管理する。
【００７９】
図１３は、管理サーバ４ａで管理される情報とＧＷ２で管理される情報との関係を示す。管理サーバ４ａの記憶領域（一次記憶、二次記憶の少なくとも一方）には、設計情報を管理するためのテーブル４１ａと、構成情報を管理するためのテーブル４１ｂと、ＧＷ管理情報を管理するテーブル４１ｃとが記憶され、ＣＰＵによって管理される。
【００８０】
テーブル４１ａで管理される設計情報及びテーブル４１ｂで管理される構成情報は各デバイス１を収容するＧＷ２の識別子を含む。各ＧＷ２は自身が収容するデバイス１に係る設計情報と構成情報とを管理サーバ４ａから受けて管理し、構成情報が更新された場合に管理サーバ４ａへ更新情報を送信し、管理サーバ４ａのテーブル４１ｂが更新される。
【００８１】
＜実施形態１の効果＞
実施形態１によれば、接続が要求されたデバイス１とＧＷ２とが接続された場合に、ＧＷ２がデバイス１からプロファイルを自動的に取得する。ＧＷ２は取得したプロファイルが予め記憶した設計情報に適合（合致）するかを判定する。ＧＷ２はプロファイルが設計情報に適合する場合にデバイス１の接続を許可する判定結果を出力し、そうでない場合にデバイス１の接続を不可とする判定結果を出力する。接続許可の判定結果に基づき、デバイス１とＧＷ２との接続が維持され、デバイス１で収集されたサーバ４宛のデータを中継
する処理をＧＷ２は行う。一方、接続不可の判定結果に基づき、デバイス１がＧＷ２から切断されたり、サーバ４との通信が不可の状態とされたりする。
【００８２】
このように、デバイス１とＧＷ２に接続させることで、通信メディアに応じた方法でデバイス１のプロファイルが自動的にＧＷ２に取得される。そして、プロファイルが設計情報に適合するデバイス１がＧＷ２に収容され、そうでないデバイス１はＧＷ２に収容されない。これによって、プロファイルを作業員が入手して情報処理装置や機器に入力する作業は不要となるため、デバイス１をＧＷ２に接続する作業の負荷を軽減することができる。
【００８３】
また、設計情報に適合しないデバイス１はＧＷ２から切断されたりサーバ４との通信を禁止されたりする。このため、設計情報に則ったシステム構成でデータ収集システムを運用することが可能となる。
【００８４】
また、実施形態１では、プロファイルが設計情報に適合する場合には、構成情報とプロファイル情報とが照合される。このとき、同種のデバイス１が既に構成情報に登録されている場合（ＧＷ２に接続されている場合）には、該当のデバイス１の切断処理や通信禁止処理が行われることで、重複した機器の接続を回避することができる。ＧＷ２における構成情報の記憶や構成情報とプロファイルとの照合はオプションとすることができる。
【００８５】
〔実施形態２〕
以下、実施形態２について説明する。実施形態２の構成は実施形態１との共通点を含むので、主として相違点について説明し、共通点については説明を省略する。実施形態１では、デバイス１の接続を許可する場合に、構成情報としてデバイスプロファイルをテーブル２４ｂに登録する。但し、デバイス１の資産管理の観点から、デバイス１の設置場所に係る情報を管理することが有用な場合がある。
【００８６】
設置場所に係る情報は、例えば、デバイス１の設置場所名や設置場所周辺の画像（写真、描画など）、設置場所に設置されたデバイス１の画像（デバイス１の設置状態を示す画像）などである。設置場所に係る情報は、例えば、デバイス１の設備棚卸や故障時に作業員が現場で作業する際に有用である。実施形態２では、デバイス１のＧＷ２への接続時に、設置場所に係る情報を構成情報に含める（登録する）。これによって、データ収集システムの運用が容易となる。
【００８７】
図１４は、実施形態２の構成例を示す図である。図１４に示すように、実施形態では、作業者が使用する作業用端末６（端末６とも表記）が追加されている。端末６は、ネットワーク３ｂを介してＧＷ２と通信可能に接続される。
【００８８】
端末６は、画像入力部６１Ａと、現場情報入力部６２Ａとを含む。現場情報入力部６２Ａは、デバイス１の設置場所の情報の入力を受け付ける。画像入力部６１Ａは、デバイス１の設置場所や設置されたデバイスの１の画像（写真）を撮影により取得する。設置場所の情報及び画像は、設置場所に係る情報（設置場所関連情報）としてネットワーク３ｂを介してＧＷ２へ送信される。ＧＷ２では、管理部２４が記憶領域２４Ａに設置場所関連情報を登録する。
【００８９】
図１５は、実施形態２における構成情報管理テーブル２４ｂのデータ構造例を示す。図１４に示すように、テーブル２４ｂの「属性」には、設置場所関連情報として、設置場所の情報と、画像（写真）とが記憶される。
【００９０】
図１６は端末６のハードウェア構成例を示す図である。端末６は、一例として、バスを
介して相互に接続されたＣＰＵ６１と、一次記憶６２と、二次記憶６３と、通信ＩＦ６４と、入力装置６５と、出力装置６６と、カメラ６７とを含む。
【００９１】
ＣＰＵ６１、一次記憶６２、二次記憶６３、通信ＩＦ６４、入力装置６５、出力装置６６として、図２に示したＣＰＵ３１、一次記憶３２、二次記憶３３、通信ＩＦ３４ｂ、入力装置３５、出力装置３６と同様のものを適用できる。
【００９２】
二次記憶６３（一次記憶６２でも良い）には、補助情報入力プログラムが記憶され、ＣＰＵ６１が補助情報プログラムを実行することで、端末６は画像入力部６１Ａと現場情報入力部６２Ａとを含む装置として動作する。カメラ６７によって撮影された画像（写真）と、入力装置６５を用いて入力された情報とを、ＣＰＵ６１は設置場所に係る情報として扱い、通信ＩＦ６４を制御し、ネットワーク３ｂを介してＧＷ２へ設置場所に係る情報を送る。
【００９３】
実施形態２の動作例は以下の通りである。例えば、実施形態１で説明したデバイス接続処理（図９）における０１６の処理（構成情報を更新）の実行の際に、管理部２４は現場情報入力部６２Ａにデバイスプロファイルを送信し、補足情報を要求する。
【００９４】
作業員は、デバイス１の接続作業を開始する前に、端末６をネットワーク３ｂを介してＧＷ２と通信可能に接続する。また、作業員は、作業対象のＧＷ２にログインし、作業中は他の作業員はログインできないようにする。
【００９５】
現場情報入力部６２Ａは、現在接続しようとしているデバイス１のプロファイルの一部（ベンダ名、製品名など）を出力装置６６（ディスプレイ）の画面に表示し、設置場所に係る情報（設置場所と写真）の入力を作業員に促す。
【００９６】
作業員は、端末６に含まれるカメラ６７を用いて設置場所の写真を撮影する。これによって、画像入力部６１Ａが画像データを取得する。現場情報入力部６２Aは、画像データ
と入力装置６５を用いて入力される設置場所名（設置場所に係る情報）を受け付け、管理部２４に送信する。管理部２４は記憶領域２４Ａの構成情報に設置場所に係る情報を登録する。設置場所名の入力は、現場作業員が文字列で入力しても、事前に選択肢をＧＷ２に登録しておき、作業員が選択肢の選択によって設置場所名が入力されても良い。また、端末６側で、ＧＰＳ（Global Positioning System）システムなどを利用して設置場所を自
動的に決定しても良い。
【００９７】
管理部２４のテーブル２４ｂ（図１５）では、各デバイス１の「属性」に、「設置場所」と「写真」情報が追加される。画像データは、例えばファイルシステム上に保存され、画像データのファイル名が「写真」属性で管理される。
【００９８】
実施形態２によれば、実施形態１の作用効果が得られるとともに、設置場所に係る情報が構成情報に含められることで、作業員がＧＷ２に登録された設置場所に係る情報を参照することで、作業の効率化・簡易化を図ることができる。
【００９９】
〔実施形態３〕
以下、実施形態３について説明する。実施形態３の構成は実施形態１との共通点を含むので、主として相違点について説明し、共通点については説明を省略する。データ収集システム（ＩｏＴシステム）の運用中に設計情報を変更（更新）する場合があり得る。例えば、提供するサービスの内容を変更することによって、設計情報が更新され、現在使用しているデバイスが不要となったり、他のデバイス１への交換を行うことになったりする。
【０１００】
設計情報の更新により、交換や削除の対象となったデバイス１について、速やかにＧＷ２との接続を切断したりサーバ４との通信を禁止したりして通信不可の状態にしないと、サーバ４が期待するデータを受信できず、不正な動作をする可能性がある。実施形態３ではこのような問題を解決する。
【０１０１】
実施形態３の構成は、実施形態１と同様の構成を適用可能であるので図示は省略する。但し、以下の点で実施形態１と異なる。すなわち、管理部２４が、個々のデバイス単位でなく構成情報の全体が設計情報と整合するか否かを検証し、不整合がある場合に、不整合を示す情報を制御部２１に通知する。
【０１０２】
図１７は、実施形態３における設計情報更新時における処理例を示すフローチャートである。図１７の処理は例えば管理部２４として動作するＣＰＵ３１によって実行される。３０１の処理において、ＧＷ２（ＣＰＵ３１）は、システム設計者５から更新後の設計情報を受信する。３０２の処理において、ＧＷ２は構成情報に含まれる各デバイス１のレコードに対して、以下の処理を行う。
【０１０３】
３０３の処理では、ＧＷ２はすべてのデバイスプロファイルに関する処理が終了したか否かを判定する。すべてのデバイスプロファイルに関する処理が終了したと判定される場合には処理が３１３に進み、そうでなければ処理が３０４に進む。
【０１０４】
３０４の処理では、ＧＷ２は構成情報のエントリから機器識別子を抽出し、更新された設計情報から機器識別子が一致（合致）するエントリを取得する。３０５の処理では、ＧＷ２はエントリが取得できたか否かを判定する。エントリが取得できたと判定される場合には処理が３０６へ進み、そうでない場合には処理が３１０に進む。
【０１０５】
３０６の処理では、ＧＷ２はエントリ中の通信メディアが更新された設計情報における通信メディアと一致するか否かを判定する。３０７の処理では、ＧＷ２は３０６にて一致するとの判定結果が得られたか否かを判定し、一致するとの判定結果が得られたと判定する場合には処理を３０８に進め、そうでない場合には処理を３１０に進める。
【０１０６】
３０８の処理では、ＧＷ２はエントリ中の属性が更新された設計情報における属性とマッチするかを判定する。３０９の処理では、ＧＷ２は３０８にてマッチするとの判定結果が得られたか否かを判定し、マッチするとの判定結果が得られたと判定する場合には処理を３０３に進め、そうでない場合には処理を３１０に進める。
【０１０７】
３１０の処理では、ＧＷ２はＧＷ２からデバイスとのリンク切断が可能か否かを判定する。リンク切断が可能と判定される場合には、ＧＷ２はリンク切断処理を実行する（３１１）。これに対し、リンク切断が不可能と判定される場合には、ＧＷ２は構成情報から該当するデバイスの情報を削除し、処理を３０３に戻す。
【０１０８】
上述した処理によれば、ＧＷ２は、機器識別子を抽出し、更新後の設計情報から機器識別子が合致するエントリを取得する。もし、該当するエントリが存在しなければ、更新後の設計情報において該当のデバイスは接続対象外となっている。このため、該当のデバイスの通信メディアが切断処理が可能な通信メディアであれば、ＧＷ２は切断処理を実施し、該当のデバイスの情報を構成情報から削除する。
【０１０９】
エントリが存在する場合、ＧＷ２はエントリ中の通信メディアが、更新後の設計情報における通信メディアと一致するかを判定する。通信メディアが一致しない場合は該当デバイスに対する切断処理及び構成情報からの削除処理を行う。通信メディアが一致する場合は、ＧＷ２はエントリ中の「属性」に関して「通信メディア」と同様の処理を行う。最後
に、ＧＷ２は更新後の設計情報を記憶（保存）する。
【０１１０】
実施形態３では、運用中に設計情報が更新された場合に、更新された設計情報に適合しないデバイス１のＧＷ２への接続を無効（ＧＷ２から切断、サーバ４との通信を禁止など）とする。これによって、システムの安定的な運用が可能となる。
【０１１１】
なお、構成情報（テーブル２４ｂ）から削除したデバイスに係る情報（エントリ）は、一次記憶３２や二次記憶３３に一旦保存しても良い。この場合、作業員が、現場で不要になったデバイス１の撤去作業を行う場合や、他のデバイス１への交換作業を行う際に、端末６のディスプレイに表示することで、作業の容易化を図ることができる。
【０１１２】
〔実施形態４〕
以下、実施形態４について説明する。実施形態４の構成は実施形態１との共通点を含むので、主として相違点について説明し、共通点については説明を省略する。実施形態１から３では、ＧＷ２に対するデバイス１の接続の可否判定に使用されるプロファイル（属性）のすべては何等かの手段で取得可能であることを想定している。このため、実施形態では、設計情報におけるベンダ名，製品名及び機能と、プロファイルにおけるベンダ名、製品名及び機能とが一致するときに設計情報にマッチするデータがあると判定していた。
【０１１３】
しかし、すべてのデバイス１が完全なプロファイルを提供可能に実装されているとは限らない。例えば、上記したベンダ名，製品名，機能のうちの１つか２つが取得できない場合があり得る。
【０１１４】
このような、属性に含まれる全ての要素を提供できないデバイス１のＧＷ２への接続が禁止されると、適正なデータ収集ができず、結果として適正なサービス提供ができなくなる可能性がある。逆に、無条件に接続を許可すると、設計情報と適合しないデバイス１が利用されることになり、やはり適正なサービス提供ができなくなる可能性がある。実施形態４はこのような問題を解決する。
【０１１５】
図１８は、実施形態４におけるＧＷ２の構成例を示す図である。実施形態１（図３）との相違点は、ＧＷ２がデバイス通信の監視部２８を含む点である。監視部２８は、記憶領域２８Ａに記憶された監視対象基準情報を管理する。監視対象基準情報は、監視対象のデバイス１の判断基準情報（デバイス監視ポリシ）である。記憶領域２８Ａは、例えば一次記憶３２と二次記憶３３との少なくとも一方に設けられる。ＣＰＵ１１はプログラム実行によって監視部２８として動作する。ＣＰＵ３１は「監視部」の一例である。
【０１１６】
図１９は、監視対象基準情報管理テーブル２８ａ（テーブル２８ａ）のデータ構造例を示す。テーブル２８ａは、プロファイルの要素となる情報項目「ベンダ」、「製品名」、「その他の条件」に係る情報の組み合わせで、監視対象となるデバイスを定義する。その他の条件は、ベンダ名及び製品名以外の属性に関する条件を示す。
【０１１７】
例えば、図１９の一番上の行（エントリ）は、ベンダ“空文字列”，製品名“＊（ワイルドカード）”，その他の条件“＊（ワイルドカード）”である。このエントリは、ベンダ名が得られない全てのデバイスが監視対象であることを意味する。
【０１１８】
図１９の上から２番目の行（エントリ）は、ベンダ“＊（ワイルドカード）”，製品名“空文字列”，その他の条件“＊（ワイルドカード）”である。このエントリは、ベンダ名が得られたが製品名が得られない全てのデバイスが監視対象であることを意味する。
【０１１９】
図１９の上から３番目の行（エントリ）は、ベンダ“VecdorX”，製品名“DeviceA, De
viceB”，その他の条件“＊（ワイルドカード）”である。このエントリは、ベンダ名“VecdorX”の製品名“DeviceA”及び“DeviceB”が監視対象であることを意味する。
【０１２０】
図１９の上から４番目の行（エントリ）は、ベンダ“VecdorY”，製品名“DeviceC”，その他の条件“ハードウェアバージョン=1.0 &&、ファームバージョン<2.0”である。こ
のエントリは、ベンダ名“VecdorY”、製品名“DeviceC”であり、ハードウェアバージョンが１．０であり、且つファームウェアバージョンが２．０以前であるデバイス１が監視対象であることを意味する。上記は例示であり、上記以外の条件を満たすデバイス１を監視対象とすることができる。
【０１２１】
図２０は、記憶領域２８Ａに記憶される通信履歴管理テーブル２８ｂ（テーブル２８ｂ）のデータ構造例を示す。テーブル２８ｂはデバイス１によるデータのセンシング時刻と、デバイス識別子と、センシングデータとを含むエントリの集合で形成される。センシングデータは、例えばセンサ１７を用いて取得（収集）される。
【０１２２】
センシング時刻はデータを取得した時刻を示し、デバイス識別子はデータを取得したデバイス１の識別子である。センシングデータは取得されたデータの内容を示す。
【０１２３】
図２１は、実施形態４におけるデバイス接続処理の例を示すフローチャートである。実施形態４では、実施形態１と同様に、図９に示した０１１〜０１６の処理が例えばＣＰＵ３１によって実行される。但し、０１６の処理後に図２１に示す０２１，０２２，０２３の処理が実行される。なお、実施形態４では、一例として、設計情報とプロファイルとの間で、ベンダ名及び製品名の少なくとも一方がマッチする場合に、デバイス１のＧＷ２への接続が許可されると仮定する。
【０１２４】
０２１の処理では、ＧＷ２は取得したプロファイルが監視対象基準情報管理テーブル２８ａのエントリにマッチするかを判定する。０２２の処理では、ＧＷ２は０２１の判定結果としてマッチするエントリがあるか否かを判定し、マッチするエントリがあると判定する場合には処理を０２３に進め、そうでない場合には処理を終了する。０２３の処理では、ＧＷ２は図示しない監視対象デバイスリストにデバイスの識別子を追加し、処理を終了する。監視対象デバイスリストは一次記憶３２と二次記憶３３との少なくとも一方に記憶される。テーブル２８ａが図１９に示す内容を有する場合、ベンダ名が不明のデバイスやベンダ名があるが製品名が不明のデバイス１などが監視対象としてテーブル２８ｂに登録される。
【０１２５】
図２２は、実施形態４のＧＷ２で行われる監視処理の一例を示すフローチャートである。実施形態４でも、実施形態１と同様に、サーバ４とデバイス１とが通信する場合には、図１０に示した１０１〜１１０の処理が例えばＣＰＵ３１によって行われる。但し、１０８の処理と１０９の処理との間に、図２２に示す１１１から１１７の処理が追加される。
【０１２６】
１１１の処理は、１０８の処理でデバイス１からの応答が受信された場合に開始される。１１１の処理では、ＧＷ２は監視対象デバイスリストを参照して指定された（応答を受信した）デバイス１が監視対象か否かを判定する。ＧＷ２はデバイス１が監視対象であると判定する場合に処理を１１２に進め、そうでない場合には処理を１０９（図１０）に進める。
【０１２７】
１１２の処理では、ＧＷ２はデバイス通信履歴（テーブル２８ｂ）にエントリ（センシング時刻，デバイス識別子，センシングデータ）を追加する。エントリ中の情報はデバイス１からの応答に含まれている。
【０１２８】
１１３では、ＧＷ２はテーブル２８ｂのエントリ数が閾値以上か否かを判定し、閾値以上と判定する場合には処理を１１４に進め、そうでない場合には処理を１１５に進める。１１４の処理では、テーブル２８ｂからセンシング時刻が一番古いエントリを削除し、処理を１１５に進める。
【０１２９】
１１５の処理では、ＧＷ２は指定された（応答を受信した）デバイス１の通信履歴を取得し、異常の有無を確認する。１１６では、ＧＷ２は異常ありか否かを判定し、異常ありと判定する場合には、処理を１１７に進め、そうでない場合には処理を１０９（図１０）に進める。１１７では、ＧＷ２はクラウドサービス（サーバ４）にエラーを送信し、処理を終了する。
【０１３０】
上述したように、実施形態４におけるＧＷ２では、デバイス１の接続許可時に、監視部２８（ＣＰＵ３１）が判定部２２からプロファイルを取得し、プロファイルと監視対象基準情報（テーブル２８ａ）とを用いてデバイス１の通信監視の要否を判定する。
【０１３１】
監視部２８は、デバイス１と監視対象と判定した場合に、テーブル２８ｂに監視対象のデバイス１のデバイス識別子を記憶するともに、該当のデバイス１とクラウドサービス（サーバ４）間の通信履歴を蓄積する（図２０参照）。
【０１３２】
監視部２８は、通信履歴に基づき通信の異常の有無を判定し、異常と判定する場合は、デバイス１とサーバ４との通信を禁止し、サーバ４にエラーを送る。異常の判断基準は、デバイスからのデータ送信間隔が、設定したものと異なっている、一定間隔でない、あるいはデータの取得に失敗する頻度が高いなどである。このような統計的な判断基準の代わりに、ＡＩ（Artificial Intelligence：人工知能）手法を利用しても良い。
【０１３３】
なお、図２２の処理が図１０の処理と同期して実行される例を示しているが、デバイス１の通信の異常判定処理は、クラウドサービス（サーバ４）からのメッセージ処理と非同期に実行して良い。
【０１３４】
実施形態４によれば、ＧＷ２への接続は許可されるが、取得されるプロファイルの内容が所定の監視対象条件を満たすデバイス１についてサーバ４との通信が監視される。通信の異常が検知された場合には、デバイス１とサーバ４とのＧＷ２を介した通信が禁止される。これによって、デバイス１の接続の許可範囲に柔軟性を持たせる一方で、通信が異常の場合に通信を禁止して、サーバ４の不正動作が行われるのを回避することができる。
【０１３５】
なお、監視・分析は、ＧＷ２の負荷を増大させるので、例えば、タイマなどを用いてある一定時間だけ監視し、問題がないことが確認できた場合には、監視対象から外すことも考えられる。すなわち、監視部２８が、監視対象に設定されてから所定時間異常が検出されない機器を監視対象から除外することができる。具体的には、通信履歴管理テーブル（テーブル２８ａ）内の、あるデバイスのエントリが一定数以上あり、或るデバイスに関して所定時間通信に異常がないと判断した場合、そのデバイスのエントリを監視対象デバイスリストから削除する。そうすることで、１１１の判定がＮＯとなり、監視対象でなくなる。
【０１３６】
また、接続作業時に作業員が最終の接続確認を行う場合において、確認を行う作業員がエキスパートか否かに応じて、監視対象にするか否かを管理することも考えられる。このように、デバイスの素性や作業者のスキルなどの、接続作業時状況に応じて、デバイスのクラウドサービスとの通信方法を制御することで、クラウドサービスの実行に関する安定性を向上させる効果が期待できる。
【０１３７】
〔実施形態５〕
以下、実施形態５について説明する。実施形態５の構成は実施形態１との共通点を含むので、主として相違点について説明し、共通点については説明を省略する。実施形態１〜４では、デバイス１を利用する個々のサービス側のデバイス利用に関する都合を考慮していない。
【０１３８】
しかし、サービスを実現するアプリケーション（アプリ：サーバ４上で実行される）が、特定のデバイス１を想定した設計になっている場合がある。サービスの運用を開始した後、アプリの内容を当初想定したデバイスとは別のデバイスに対応させ、開発環境でのテストを経た後に実環境でのテストを行う場合もあり得る。
【０１３９】
アプリが想定しないデバイス１との通信を禁止したり、データにフラグを付けてアプリが想定外のデバイス１からのデータであることを容易に把握可能としたりする。そして、アプリが行う処理を変え、フラグ付きデータによる実地テストで問題がなければ、本格的な運用に移行することが考えられる。
【０１４０】
実施形態５では、サービス（サーバ４）側の要件を、接続許可時に取得される情報と照合した結果に基づきデバイス１の通信を制御する。これによって、サービスの運用性を向上させる。
【０１４１】
図２３は、実施形態５の構成例を示す図である。実施形態５におけるＧＷ２はデバイス通信ポリシ管理部２９（管理部２９）を含む。ＣＰＵ３１はプログラムの実行によって管理部２９として動作する。管理部２９は、記憶領域２９Ａに記憶されたポリシ情報（ポリシ管理テーブル２９ａ）を管理する。記憶領域２９Ａは一次記憶３２及び二次記憶３３の少なくとも一方に設けられる。管理部２９は、サーバ４から受信されるメッセージによって特定されるデバイス１のプロファイルの内容とサーバ４で実行されるアプリケーションとの関係に基づいて定められたポリシに係る処理を実行する。
【０１４２】
図２４は、ポリシ管理テーブル２９ａ（テーブル２９ａ）のデータ構造例を示す。テーブル２９ａのエントリは、サービスを実行するアプリ毎に、デバイスプロファイルが満たす条件に対して、どのような動作をするかを定義するポリシを表している。動作としては、通信を禁止したり（通信不可の状態にしたり）、アプリに送信するデータに属性を追加したりすることが想定される。
【０１４３】
テーブル２９ａのエントリは、アプリ識別子と、ベンダ名と、製品名と、その他の条件と、動作とを含む。アプリ識別子はアプリケーションの識別子である。ベンダ名，製品名及びその他の条件は、テーブル２８ａと同様の情報である。動作は、ベンダ名，製品名及びその他の条件にマッチするデバイス１に対する動作（通信禁止や属性追加など）が定義される。
【０１４４】
ＧＷ２は、デバイス１とサーバ４との通信時に、デバイス１に応じた処理を実行する。図２５は、実施形態５における、デバイス１とサーバ４との通信時におけるＧＷ２の処理例を示すフローチャートである。図２５に示す処理は例えば管理部２９として動作するＣＰＵ３１によって行われる。
【０１４５】
５０１の処理では、ＧＷ２はクラウドサービス（サーバ４）からメッセージ（リクエスト）を受信する。５０２の処理では、ＧＷ２はメッセージからデバイス識別子とアプリケーション識別子（アプリ識別子）とを抽出する。
【０１４６】
５０３の処理では、ＧＷ２は構成情報を検索して、デバイス識別子が一致するデバイス
プロファイルを取得する。５０４の処理では、ＧＷ２はデバイスプロファイルが取得できたか否かを判定する。プロファイルが取得できたと判定される場合には処理が５０５に進み、そうでない場合には処理が５１５に進む。
【０１４７】
５０５の処理では、ＧＷ２はポリシ管理テーブル２９ａを検索して、アプリ識別子とデバイスプロファイルにマッチするエントリを探索する。５０６の処理では、ＧＷ２はマッチするエントリがあるか否かを判定し、エントリがあると判定する場合には処理を５０７に進め、そうでない場合には処理を５０８に進める。
【０１４８】
５０７の処理では、ＧＷ２はエントリ中の「動作」が通信禁止か否かを判定し、通信禁止であると判定する場合には処理を５１５に進め、そうでない場合には処理を５０８に進める。
【０１４９】
５０８の処理では、ＧＷ２はデバイスプロファイルに含まれる通信メディアの情報とローカル識別子とを利用して、デバイス１にメッセージを送信する。５０９の処理では、ＧＷ２はメッセージを送信できたか否かを判定する。メッセージを送信できたと判定される場合には処理が５１０に進み、そうでない場合には処理が５１５に進む。
【０１５０】
５１０の処理では、ＧＷ２はデバイス１から応答を受信する。５１１の処理では、ＧＷ２はデバイスから応答を受信できたか否かを判定し、受信できたと判定する場合には処理を５１２に進め、そうでない場合には処理を５１５に進める。
【０１５１】
５１２の処理では、ＧＷ２はポリシ（属性（ベンダ名、製品名、その他の条件））がマッチしており、ポリシに対応する動作が「属性追加」か否かを判定する。属性追加と判定される場合には処理が５１３に進み、そうでない場合には処理が５１４に進む。
【０１５２】
５１３の処理では、ＧＷ２はデータに所定の属性を追加し、クラウドサービス（サーバ４）に送信し、処理を終了する。５１４の処理では、ＧＷ２は応答をクラウドサービスに送信し、処理を終了する。５１５の処理では、ＧＷ２はクラウドサービス（サーバ４）にエラーを送信し、処理を終了する。
【０１５３】
実施形態５によれば、サーバ４で実行される各アプリに関して、検出の対象となるプロファイル情報の内容と、検出時における動作が定義されたポリシ管理テーブル２９ａが用意される。
【０１５４】
ＧＷ２は、例えば、アプリ識別子で識別されるアプリと適合しないプロファイル情報を有するデバイス１についてアプリとの通信を禁止するポリシをテーブル２９ａに設定することで、アプリに適合しないデバイス１がアプリと通信するのを回避することができる。
【０１５５】
或いは、アプリ識別子で識別されるアプリへ所定のプロファイル情報を有するデバイス１からのデータが送信される場合に、ＧＷ２はプロファイル情報中の特定の属性情報をアプリへ送信されるデータに追加する。アプリ（サーバ４）では、追加された属性情報の存在によって、デバイス１が例えばアプリに適合しないデバイス１であることを認識することができる。実施形態１〜５で説明した構成は適宜組み合わせることができる。
【０１５６】
以上説明した実施形態は、以下の付記を開示する。付記は適宜組み合わせることができる。
（付記１）  機器から受信されるデータを前記データの収集装置へ送信する通信装置において、
接続が要求された機器のプロファイル情報を取得する取得部と、
前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する判定部と、
を含む通信装置。（１）
【０１５７】
（付記２）  前記取得部は、前記接続が要求された機器と前記通信装置との通信に使用される通信メディアに基づいて前記接続が要求された機器から前記プロファイル情報を取得する付記１に記載の通信装置。（２）
【０１５８】
（付記３）  前記取得部は、前記接続が要求された機器と前記通信装置とがBluetooth Low Energy（ＢＬＥ）に基づく通信を行う場合に、Device Information Service（ＤＩＳ）を用いて前記接続が要求された機器からプロファイル情報を取得する付記２に記載の通信装置。
【０１５９】
（付記４）  前記取得部は、前記接続が要求された機器と前記通信装置とがInternet Protocol（ＩＰ）通信を行う場合に、Universal Plug and Play（ＵＰｎＰ）を用いて前記接続が要求された機器からプロファイル情報を取得する付記２に記載の通信装置。
【０１６０】
（付記５）  前記取得部は、前記接続が要求された機器と前記通信装置とがInternet Protocol（ＩＰ）通信を行う場合に、Home-network Topology Identifying Protocol（Ｈ
ＴＩＰ）を用いて前記接続が要求された機器からプロファイル情報を取得する付記２に記載の通信装置。
【０１６１】
（付記６）  前記判定結果において接続許可と判定された機器と同種の機器が既に前記通信装置に収容されている場合に、前記接続許可と判定された機器を通信不可の状態にする制御部をさらに含む付記１に記載の通信装置。（３）
【０１６２】
（付記７）  前記通信装置に接続されている機器の設置場所に係る情報を受信し、前記通信装置と接続されている機器の情報を含む構成情報に含める管理部をさらに含む付記１に記載の通信装置。（４）
【０１６３】
（付記８）  前記設計情報が更新された場合に、更新された設計情報に整合しないプロファイル情報を有する機器を通信不可の状態にする制御部をさらに含む付記１に記載の通信装置。（５）
【０１６４】
（付記９）  前記判定結果において接続許可と判定された機器のうち所定内容のプロファイル情報を有する機器を監視対象に設定し、異常が検出された監視対象の機器を通信不可の状態にする監視部をさらに含む付記１に記載の通信装置。（６）
【０１６５】
（付記１０）  前記監視部は前記監視対象に設定されてから所定時間異常が検出されない機器を監視対象から除外する付記９に記載の通信装置。（７）
【０１６６】
（付記１１）  前記収集装置から受信されるメッセージによって特定される機器のプロファイル情報の内容と前記収集装置で実行されるアプリケーションとの関係に基づいて定められたポリシに係る処理を実行するポリシ管理部をさらに含む付記１に記載の通信装置。（８）
【０１６７】
（付記１２）  データを出力する機器と、前記データを受信して前記データの収集装置に送信する通信装置とを含み、前記通信装置は、接続が要求された機器のプロファイル情報を取得する取得部と、前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する判定部と、を含む通信シス
テム。（９）
【０１６８】
（付記１３）  データを出力する機器において、前記データを受信して前記データの収集装置へ送信する通信装置へ接続要求を送る処理と、前記通信装置からの要求に応じて前記機器のプロファイル情報を前記通信装置へ送信する処理とを行う制御部を含む機器。（１０）
【０１６９】
（付記１４）機器からのデータを受信して前記データの収集装置へ送信する通信装置のコンピュータに、接続が要求された機器のプロファイル情報を取得し、前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定する処理を実行させるプログラム。（１１）
【０１７０】
（付記１５）機器からのデータを受信して前記データの収集装置へ送信する通信装置が、接続が要求された機器のプロファイル情報を取得し、前記プロファイル情報と前記通信装置に収容する機器の設計情報とに基づいて前記接続が要求された機器の接続可否を判定することを含む通信装置の通信制御方法。（１２）
【符号の説明】
【０１７１】
１・・・デバイス（機器）
２・・・ゲートウェイ装置
４・・・サーバ
２１・・・デバイス接続の制御部
２２・・・接続可否の判定部
２３・・・デバイスプロファイルの取得部
２４・・・管理部
２５・・・データ通信の中継部
１１，３１・・・ＣＰＵ
１２，３２・・・一次記憶
１３，３３・・・二次記憶
【図１】
2018107684.tif 000003
【図２】
2018107684.tif 000004
【図３】
2018107684.tif 000005
【図４】
2018107684.tif 000006
【図５】
2018107684.tif 000007
【図６】
2018107684.tif 000008
【図７】
2018107684.tif 000009
【図８】
2018107684.tif 000010
【図９】
2018107684.tif 000011
【図１０】
2018107684.tif 000012
【図１１】
2018107684.tif 000013
【図１２】
2018107684.tif 000014
【図１３】
2018107684.tif 000015
【図１４】
2018107684.tif 000016
【図１５】
2018107684.tif 000017
【図１６】
2018107684.tif 000018
【図１７】
2018107684.tif 000019
【図１８】
2018107684.tif 000020
【図１９】
2018107684.tif 000021
【図２０】
2018107684.tif 000022
【図２１】
2018107684.tif 000023
【図２２】
2018107684.tif 000024
【図２３】
2018107684.tif 000025
【図２４】
2018107684.tif 000026
【図２５】
2018107684.tif 000027