(57)【要約】      （修正有）【課題】交換後のセンサが交換前のセンサの代替として使用できるか否かの判断を行うセンサ管理システムを提供する。【解決手段】センサを管理するセンサ管理システムにおいて、検知手段は、センサ管理システムに接続されたセンサの交換を検知する。取得部は、センサからセンシングデータを取得する。交換対処手段は、取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する。【選択図】図９
2018054360.tif 000002
【特許請求の範囲】
【請求項１】
センサを管理するセンサ管理システムであって、
前記センサ管理システムに接続されたセンサの交換を検知する検知手段と、
センサからセンシングデータを取得する取得部と、
前記取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する交換対処手段と、
を有するセンサ管理システム。
【請求項２】
前記交換対処手段は、交換後のセンサが複数のサブセンサを有する場合、前記複数のサブセンサのそれぞれからセンシングデータを取得し、前記取得したセンシングデータのそれぞれについて交換前のセンサの過去のセンシングデータに類似するか否かを判定する、
請求項１に記載のセンサ管理システム。
【請求項３】
前記交換対処手段は、交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する、
請求項１または２に記載のセンサ管理システム。
【請求項４】
前記交換対処手段は、交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する前に、交換前のデバイスのセンシングデータを正規化するための正規化定義を交換後のデバイスに合致するように書き換える、
請求項１乃至３の何れかに記載のセンサ管理システム。
【請求項５】
前記交換対処手段は、交換後のセンサを交換前のセンサの代替として運用する前に、書き換え後の前記正規化定義を使用して交換後のデバイスから取得したセンシングデータを用いたテストを実施する、
請求項４に記載のセンサ管理システム。
【請求項６】
前記交換対処手段は、前記テストに成功した交換後のセンサの情報と交換前のセンサの情報と前記正規化定義とを含むデバイス情報を記憶し、その後、前記センサ管理システムに接続されたセンサの交換が前記検知手段によって検知されると、検知された交換後のセンサの情報と交換前のセンサの情報とを含む前記デバイス情報の有無に基づいて、今回のセンサ交換に伴う前記正規化定義の書き換えと前記テストの実施の必要性の有無を決定する、
請求項５に記載のセンサ管理システム。
【請求項７】
前記交換対処手段は、交換前のセンサの１日のセンシングデータのうちデータの変化が激しい時間帯のセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと、前記時間帯と同じ時間帯における交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離が閾値以下か否かに基づいて、前記類似の判定を行う、
請求項１乃至５の何れかに記載のセンサ管理システム。
【請求項８】
前記検知手段は、前記センサ管理システムに新たに接続されたセンサを交換後のセンサとして検知し、交換後のセンサの接続前に前記センサ管理システムに接続されていたセンサのうち前記交換後のセンサの接続後に前記センサ管理システムとの間で通信が行えなくなったセンサを交換前のセンサとして検知する、
請求項１乃至７の何れかに記載のセンサ管理システム。
【請求項９】
センサ管理システムにおけるセンサを管理する方法であって、
前記センサ管理システムに接続されたセンサの交換を検知し、
交換後のセンサからセンシングデータを取得し、
取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、
前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する、
センサ管理方法。
【請求項１０】
コンピュータを、
前記センサ管理システムに接続されたセンサの交換を検知する検知手段と、
センサからセンシングデータを取得する取得部と、
前記取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する交換対処手段と、
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、センサ管理システム、センサ管理方法、およびプログラムに関する。
【背景技術】
【０００２】
インターネットの広帯域化、低価格化、および無線通信機器の小型化により、地理的に分散した多数のセンサからセンシングデータをリアルタイムに取得し、様々なサービスを提供するセンサ管理システムが提案ないし実用化されている。
【０００３】
例えば、特許文献１には、サーバと、インターネット等のネットワークを介してサーバに接続されたゲートウェイと、ＺｉｇＢｅｅ等のネットワークを介してゲートウェイに接続された多種多様なセンサと、サーバに接続されたコンソールとを有するセンサ管理システムが、記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−６８２８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、センサ管理システムでは、センサを交換するケースが多々発生する。例えば、故障あるいは劣化したセンサの代わりに最新のセンサを使用するようなケースである。そのような場合、ユーザはセンサを交換する作業を実施することになるが、交換後のセンサが交換前のセンサの代替として使用できるか否かの判断をユーザに委ねると不測の事態を招くおそれがある。その理由は、互換性が無いセンサのような代替として使用できないセンサに交換された場合、センサから取得されるデータが全く別のものに変わってしまい、後段のアプリケーション処理等が誤動作してしまうためである。
【０００６】
本発明の目的は、上述した課題、即ち、交換後のセンサが交換前のセンサの代替として使用できるか否かの判断をユーザに委ねると不測の事態を招いてしまう、という課題を解決するセンサ管理システムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明の一形態に係るセンサ管理システムは、
センサを管理するセンサ管理システムであって、
前記センサ管理システムに接続されたセンサの交換を検知する検知手段と、
センサからセンシングデータを取得する取得部と、
前記取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する交換対処手段と、
を有する。
【０００８】
また本発明の他の形態に係るセンサ管理方法は、
センサ管理システムにおけるセンサを管理する方法であって、
前記センサ管理システムに接続されたセンサの交換を検知し、
交換後のセンサからセンシングデータを取得し、
取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、
前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する。
【０００９】
また本発明の他の形態に係るプログラムは、
コンピュータを、
センサ管理システムに接続されたセンサの交換を検知する検知手段と、
センサからセンシングデータを取得する取得部と、
前記取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する交換対処手段と、
して機能させる。
【発明の効果】
【００１０】
本発明は上述した構成を有することにより、互換性の無いセンサのような誤ったセンサへの交換による不測の事態を回避することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明に関連するセンサ管理システムの構成を示す図である。
【図２】本発明に関連するセンサ管理システムで使用するデータフロー定義を示す図である。
【図３】本発明の第１の実施形態に係るセンサ管理システムの構成例を示す図である。
【図４】本発明の第１の実施形態に係るセンサ管理システムにおけるデバイスの交換例を示す図である。
【図５】本発明の第１の実施形態に係るセンサ管理システムで作成するエッジＧＷプロファイルの例を示す図である。
【図６】本発明の第１の実施形態に係るセンサ管理システムにおける影響判定および是正処置の流れを示すフローチャートである。
【図７】本発明の第２の実施形態に係るセンサ管理システムの要部構成例を示す図である。
【図８】本発明の第３の実施形態に係るセンサ管理システムの要部構成例を示す図である。
【図９】本発明の第４の実施形態に係るセンサ管理システムの構成例を示す図である。
【図１０】本発明の第４の実施形態に係るセンサ管理システムの動作の一例を示すフローチャートである。
【図１１】本発明の第４の実施形態に係るセンサ管理システムにおける検知部の一例を示す動作フローチャートである。
【図１２】本発明の第４の実施形態に係るセンサ管理システムにおける検知部の他の例を示す動作フローチャートである。
【図１３】本発明の第４の実施形態に係るセンサ管理システムにおける交換対処部部の構成例を示す図である。
【図１４】本発明の第４の実施形態に係るセンサ管理システムにおける交換対処部部の他の構成例を示す図である。
【図１５】本発明の第５の実施形態に係るセンサ管理システムの動作の一例を示すフローチャートである。
【図１６】本発明の第６の実施形態に係るセンサ管理システムの動作の一例を示す要部フローチャートである。
【発明を実施するための形態】
【００１２】
次に本発明の実施の形態について図面を参照して詳細に説明する。
［第１の実施形態］
以下、本発明の第１の実施形態について、解決しようとする課題、課題を解決するための手段、構成、動作、および効果の順に詳細に説明する。
【００１３】
＜本実施形態が解決しようとする課題＞
近年ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）技術への期待が高まっている。ＩｏＴシステムを構築する際、多くのマシンリソースが必要となる処理についてはクラウド環境などのバックエンドサーバで実行し、実際のセンサデバイス（以降、単にデバイスと称す）とのやり取りや即時性の求められる処理はできるだけデバイスの近くで処理するためエッジゲートウェイ装置（以降、エッジＧＷ装置と称す）を配置する構成をとることが多くなってきた。
【００１４】
エッジＧＷ装置で即時性が求められる処理の中には、実世界上の人に対して物理的な影響を与え、人の生命にかかわるような処理も含まれている。このような状況の中、デバイスの故障やセキュリティ上の問題からデバイスおよびデバイスドライバを安全、且つ、迅速に更新する要求が高まりつつある。
【００１５】
しかし、これまで、このような問題に対処するためには、デバイスとエッジＧＷ装置上のアプリケーションとの間のインタフェース仕様を厳密に定め、そのインタフェース仕様に従っている限りはいつでもデバイスおよびデバイスドライバを更新できるという前提にたっていたが、ＩｏＴ周辺の技術は多数の標準化団体が乱立し、全てが標準化される道は遠い。また、そのような状況のため、まずは固有の業界に閉じた形で標準を決めて実際の問題に取り組むケースも有り、そのような場合は、デバイス自体の再利用性や相互接続性、利便性が損なわれてしまう。そのため、以下のような課題がある。
【００１６】
エッジＧＷ装置上で、デバイスから発生するデータをデバイスドライバが読み取って、所定のフォーマット（例えばＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）フォーマット）に変換したデータ（以降、デバイスデータと称す）を返却し、さらに異種・複数のデバイスから発生したデバイスデータを組み合わせ、かつ、データを処理しやすいように正規化データへとフォーマットを整形し、その正規化データを使ってアプリケーションのロジックを実行し、その結果データをバックエンドサーバに送信し、また条件判定によってデバイスを操作する状況を想定する。このような状況において、デバイスの故障により別のデバイスに交換した場合や、デバイスドライバ自体がバージョンアップートした場合に、適用しているデバイスドライバを更新すると返却されるデバイスデータのスキーマが変わってしまい、後段の正規化処理やアプリケーションロジック、デバイスへの操作が誤作動してしまうことがある。以下、この点について図面を参照して説明する。
【００１７】
図１に本発明に関連するセンサ管理システムの構成を示す。図１において、エッジＧＷ装置は、デバイスが接続されたデバイスドライバと、正規化処理部とユーザロジック処理部とデータフロー制御部を含むデータ処理部とを複数有する。データ処理部で処理した結果はデータ送信部でバックエンドサーバに送信する。バックエンドサーバは、データ受信部でデータを受信して、データ処理部で処理した後、データ格納部に保存する。またエッジＧＷ装置は、デバイス検知・ドライバ更新部を持ち、デバイスの変更を検知するとバックエンドサーバのデバイスドライバリポジトリから該当するデバイスドライバをダウンロードして適用する。
【００１８】
ここで、図２に示すようなデータフロー定義ｆｌｏｗ１を想定する。このデータフロー定義ｆｌｏｗ１は、図２を参照すると、例えば温度センサｓ１と湿度センサｓ２が存在し、各デバイス用のデバイスドライバから図のようなデータが返却され、正規化定義ｒｕｌｅ１によって、図のような正規化データｓｔａｔｓが生成され、ユーザロジックＬ１によって不快指数を算出し、バックエンドへ送信する、という一連のデータフローを定義している。このとき、例えば温度センサｓ１の故障等によって、エッジＧＷ装置がある現場の担当者が、温度センサｓ１を別のセンサｓ１’に交換したとする。このとき、センサｓ１’が元のセンサｓ１と全く同じ仕様のセンサや互換性の有るセンサであれば、後段の正規化処理やユーザロジックへの影響は殆どない。しかし、担当者の判断ミス等により温度センサｓ１とは互換性の無いセンサｓ１’へ交換された場合、センサｓ１’からのデバイスデータが元のセンサｓ１からのデバイスデータと相違することになるため、後段の正規化処理やユーザロジックが正常に動作しなくなってしまう。
【００１９】
また、温度センサｓ１の代替として使用できるセンサｓ１’であっても、仕様が元のセンサｓ１と相違する場合、後段の正規化処理やユーザロジックの修正が必要になる。このような後段の正規化処理やユーザロジックの修正を人手で実施するならば、多くの手間と労力が必要になる。特にエッジＧＷ装置がある現場の担当者はＩＴの知識を持たないため、システム全体を管理するＩＴ担当者に元のデバイスの代替として使用する新たなデバイスの利用を要請しなければならない。そして、この要請を受けたＩＴ担当者が、新たなデバイスに対応できるようにデータ処理部（正規化定義やユーザロジック)を人手によって修正し、また問題ない事を新たなデバイスを使ってテストしたうえで利用を許可しなければならない。そのため、実世界において、便利で利用可能なデバイスがエッジＧＷ装置側にあり利用可能な状態であったとしても、承認されていないデバイスを速やかに利用することが出来ず、利用を許可するための時間がかかり過ぎる。
【００２０】
一方で、ある一定の標準仕様に従ったデバイスのみを接続可とする事で、統制のとれた更新をできるようにするケースもあるが、標準仕様が乱立し、全てのデバイスが統一された標準仕様に則ることが期待できない状況で特定の標準仕様に縛られると利用できるデバイスが限定されてしまい、これも利便性を損なう結果となる。
【００２１】
＜課題を解決するための手段の概要＞
本実施形態では、エッジＧＷ装置がデータのフローとテンプレート型の正規化定義、および、ユーザロジックによって構成されるアプリケーションにおいて、実際に発生するデバイスからのデータの特徴点をエッジＧＷ装置で抽出し、プロファイルデータとしてネットワークを介してバックエンドサーバ側で保持しておく。次に、デバイスを交換するタイミングで、データ処理を停止させた状態で、実際の現場から交換後のデバイスに係るデータの傾向を判断するための特徴点を採取し、上記プロファイルデータに基づいて特徴抽出方法に合わせた適合性判定処理を行う。そして、この適合性判定処理によって、交換後のデバイスから取得したデータと交換前のデバイスの過去データとの類似性を判定し、交換後のデバイスを交換前のデバイスの代替として使用できるか否かを決定する。そして、交換後のデバイスが交換前のデバイスの代替として使用できると決定すると、次に、交換後のデバイスを交換前のデバイスの代替として使用してシステムを運用するために、正規化定義を自動で修正し、問題ない事をテストで確かめたうえでデータ処理を再開させる。これにより、デバイス更新が実世界に与える悪影響を防ぐ影響判定と是正処置とを実現する。
【００２２】
このように本実施形態によれば、実際に動作しているエッジＧＷ装置上のプロファイル情報を採取し、バックエンドのサーバ側でそのプロファイル情報を保持しておき、デバイスを交換するタイミングで、データ処理を停止させた状態で、実際の現場から交換後のデバイスに係るデータの傾向を判断するための特徴点を採取し、上記プロファイルデータに基づいて、交換後のデバイスから取得したデータと交換前のデバイスの過去データとの類似性を判定し、交換後のデバイスが交換前のデバイスの代替として使用できるか否かを決定する。
【００２３】
また、デバイスの交換に伴って正規化処理・アプリケーションロジックを変更する場合に、その影響の有無や影響範囲の判定を行い、自動修正可能なものは修正し、自動修正不可能なものはユーザに通知して対処を促し、影響に対処したことを持って安全にエッジＧＷ装置側の更新を迅速に行うように構成してよい。
【００２４】
また、大量の異なるデバイスがつながったエッジＧＷ装置に対しても、記憶していたプロファイル情報を分類・グループ化し、且つグループ間の差分を抽出しながら影響範囲を特定する事で、効率的に影響範囲を特定したうえで、ユーザに影響範囲をわかりやすく示すように構成してよい。
【００２５】
＜本実施形態の構成＞
本実施形態の構成について説明する。図３を参照すると、本実施形態に係るセンサ管理システム１００は、クラウドなどのバックエンドサーバ１３０と、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を介してバックエンドサーバ１３０に接続されたエッジＧＷ装置１４０と、そのエッジＧＷ装置１４０に接続されたデバイス１１１と、バックエンドサーバ１３０とエッジＧＷ装置１４０にまたがる影響判定および是正処置部１０１から構成される。
【００２６】
バックエンドサーバ１３０は、データ受信部１２１と、データ格納部１２２と、データ処理部１２３と、正規化定義・データフロー定義・ユーザロジックリポジトリ１２５と、デバイスドライバリポジトリ１２４と、エッジＧＷデータ処理テスト部１２６と、バックエンド側の影響判定および是正処置部１０１とから構成される。
【００２７】
エッジＧＷ装置１４０は、接続された各デバイスに対応するデバイスドライバ１１２と、エッジＧＷデータ処理部１１７と、データ送信部１１６と、デバイス検知・ドライバ更新部１１３と、デバイスデータ採取部１１４と、データ処理結果採取部１１５と、エッジＧＷ装置側の影響判定および是正処置部１０１とから構成される。
【００２８】
影響判定および是正処置部１０１は、影響判定および自動是正処置手段１０２と、エッジＧＷプロファイル格納部１０８と、適合度判定器１０３と、デバイス更新処置手段１０４と、エッジＧＷプロファイル生成手段１０５と、特徴点抽出器１０６と、プロファイル一時格納部１０７とから構成される。影響判定および是正処置部１０１は、交換対処手段とも呼ばれる。
【００２９】
それぞれ下記の役割を持つ。
【００３０】
デバイス更新処置手段１０４は、デバイスの更新要求をデバイス検知・ドライバ更新部１１３から受ける。即ち、デバイス検知・ドライバ更新部１１３は、エッジＧＷ装置１４０に接続されている或るデバイス（例えばデバイスｓ１）を別のデバイス（例えばデバイスｚ１）に交換されたことを検出すると、交換前後のデバイスを特定する情報（例えばデバイス名）を添えてデバイスの更新要求をデバイス更新処置手段１０４へ通知する。デバイス更新処置手段１０４は、上記デバイスの更新要求を受けると、エッジＧＷデータ処理部１１７を停止させ、新しいデバイス向けのデバイスドライバに更新し、影響判定および自動是正処置手段１０２の処理を依頼し、処置された結果をエッジＧＷデータ処理部１１７に反映させたうえで処理を再開させる。
【００３１】
影響判定および自動是正処置手段１０２は、デバイス更新処置手段１０４から処理を依頼されると、適合度判定器１０３を使って、新しく接続されたデバイスが元のデバイスの代替として使用できるか否かを決定する。このとき、新しく接続されたデバイスが、複数のセンサ（以下、サブセンサと称す）を有するマルチセンサの場合、新しく接続されたデバイスのどのサブセンサが元のデバイスの代替として使用できるか否かを決定する。その後、影響判定および自動是正処置手段１０２は、必要に応じて、正規化処理定義を修正し、エッジＧＷプロファイル格納部１０８に格納されたプロファイル情報をもとにエッジＧＷデータ処理テスト部１２６を使って修正後の定義をテストした上で、エッジＧＷ上の更新を許可する。
【００３２】
エッジＧＷプロファイル生成手段１０５は、デバイスが更新される前に、事前の正常稼働時のデータ処理状況のデータを採取し、プロファイル一時格納部１０７に一時保存し、特徴点抽出器１０６を使って特徴点を抽出し、プロファイルに記録し、エッジＧＷプロファイル格納部１０８に格納する。
【００３３】
今、例えば、デバイスｓ１が温度センサ、デバイスｓ２が湿度センサで、それぞれｓ１．ａが温度、ｓ２．ｂが湿度のデータをあらわしており、エッジＧＷデータ処理部１１７−１によってデータを部屋の状態として正規化し、その部屋の不快指数を計算したうえでバックエンドサーバ１３０にデータを送信し、その他のデバイスのデータをエッジＧＷデータ処理部１１７−２が処理しているとする。
【００３４】
ここで図４を参照すると、例えば、温度センサｓ１が故障してしまい、代わりのデバイスとして温度、湿度、風速が測定できるマルチセンサｚ１を接続したとする。それぞれｚ１.ｃが温度、ｚ１.ｄが湿度、ｚ１.ｅが風速を示すデータとしても、センサｚ１から発生するデータだけを見てｃ、ｄ、ｅのどれがｓ１.ａの代替として利用できるか判断する事ができない。
【００３５】
＜本実施形態の動作＞
まず、デバイスの交換が行われる前の温度センサｓ１をはじめ全てのデバイスが正常に稼働している間に、エッジＧＷプロファイル生成手段１０５は、デバイスデータ採取部１１４とデータ処理結果採取部１１５を使って、デバイスドライバ１１２から発生するデータ、正規化処理後のデータ、ユーザロジック実行後のデータを採取し、エッジＧＷプロファイル（図５）を生成する。エッジＧＷプロファイル生成手段１０５は、発生するデータをプロファイル一時格納部１０７に格納しながら、特徴点抽出器１０６を使ってデータの特徴点を抽出しながらプロファイルデータ（図５)を作成する。
【００３６】
ここで、特徴点抽出器１０６は、バックエンド側の適合度判定器１０３に合わせた特徴点抽出を行う。例えば統計的手法を用いて適合度判定をする場合は、特徴点抽出器１０６で統計情報を特徴点として計算し、プロファイルに記録する。例えば、特徴点抽出器１０６は、一日の平均、分散、標準偏差、１時間単位での傾き（変化率）等を特徴点としてプロファイルに記録する。
【００３７】
生成したエッジＧＷプロファイルは、定期的にバックエンドサーバ側のエッジＧＷプロファイル格納部１０８に送信し保存しておく。
【００３８】
デバイスｓ１をデバイスｚ１に交換しエッジＧＷ装置１４０にデバイスｚ１を接続すると、デバイス検知・ドライバ更新部１１３がそれを検知し、影響判定および是正処置部１０１のデバイス更新処置手段１０４にデバイスｓ１をデバイスｚ１へ更新する旨の更新要求を通知する。
【００３９】
図６を参照すると、要求を受けた影響判定および是正処置部１０１は次のように動作する。
【００４０】
まず、デバイス更新処置手段１０４は、交換されたデバイスのデータを処理するエッジＧＷデータ処理部１１７を停止させる（Ｆ００１)。デバイスｓ１が交換された場合、デバイスｓ１のデータを入力しているエッジＧＷデータ処理部１１７−１だけを停止すればよい。次に、デバイス更新処置手段１０４は、デバイスドライバリポジトリ１２４からセンサｚ１用のデバイスドライバを取得し、エッジＧＷ装置１４０に適用させる（Ｆ００２）。
【００４１】
次に、デバイス更新処置手段１０４は、エッジＧＷプロファイル格納部１０８に問い合わせ、この要求が発生した時期と過去に同時期で最も特徴点の変化が顕著な時間帯を問い合わせる（Ｆ００３）。例えば、５月に温度センサｓ１を交換したとして、過去データから５月で温度の変化の差の違いが最も顕著な時間帯を求める。
【００４２】
その結果、８：００−９：００と１７：００−１８：３０といった結果が返却されたとすると、その時間帯にデバイスｚ１から発生するデバイスデータｚ１.ｃ、ｚ１.ｄ、ｚ１.ｅを採取し、それぞれについて特徴点抽出器１０６を使って、プロファイル生成時と同様の特徴点を抽出する。そして、採取したデバイスｚ１のデータとデバイスｚ１の特徴点とを交換後デバイスの情報として、また温度センサｓ１を交換前デバイスの情報として、影響判定および自動是正処置手段１０２に送信する（Ｆ００３−Ｆ００６）。
【００４３】
影響判定および自動是正処置手段１０２は、抽出されたデバイスｚ１の特徴点を受け、適合度判定器１０３を使ってデバイスデータｚ１.ｃ、ｚ１.ｄ、ｚ１.ｅのうちのどのデータが過去のデバイスデータｓ１.ａと最も類似する特徴を持つデータであるかを判定する（ｆ００７）。この類似判定は、例えば、交換前のセンサの１日のセンシングデータのうちデータの変化が激しい時間帯のセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと、上記時間帯と同じ時間帯における交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離を計算し、ベクトル間距離を閾値と比較することによって行うことができるが、以下のような方法によって実現することもできる。
【００４４】
例えば、影響判定および自動是正処置手段１０２は、デバイスデータｚ１.ｃ、ｚ１.ｄ、ｚ１.ｅのうちデバイスデータｚ１．ｃのみ、デバイスデータｓ１.ａの分布の範囲内に収まるデータで、且つ、特徴を抽出した時間帯で同様の傾きを持つデータであった場合、デバイスデータｚ１．ｃに係るセンサを温度センサｓ１の代替として決定する。デバイスデータｓ１の分布の範囲内に収まり、且つ、特徴を抽出した時間帯で同様の傾きを持つデバイスデータが複数存在した場合、影響判定および自動是正処置手段１０２は、例えば、その中から、分布の範囲内に収まる程度と傾きの程度とが最も良好なデータを代替として決定する。他方、影響判定および自動是正処置手段１０２は、デバイスデータｚ１.ｃ、ｚ１.ｄ、ｚ１.ｅの何れも、デバイスデータｓ１の分布の範囲内に収まらない場合、または、特徴を抽出した時間帯でデバイスデータｓ１と同様の傾きを持たない場合、デバイスデータｚ１.ｃ、ｚ１.ｄ、ｚ１.ｅは何れも温度センサｓ１の代替として使用できないと決定する。使用できないと決定した場合、影響判定および自動是正処置手段１０２は、図示しない表示装置にその旨のアラームを表示し、または図示しない端末へ警報メッセージを送信する。ここでは、デバイスデータｚ１．ｃが温度センサｓ１の代替として使用できると決定されたものとして説明を続ける。
【００４５】
デバイスデータｚ１．ｃが温度センサｓ１の代替として使用できると決定されると、次に、影響判定および自動是正処置手段１０２は、プロファイルに記載されている構成情報に従って、正規化定義・データフロー定義・ユーザロジックリポジトリ１２５から正規化定義、ユーザロジック、データフロー定義を取得する（Ｆ００８）。次に、取得した正規化定義ｒｕｌｅ１の＄｛ｓ１．ａ｝のプレースホルダを＄｛ｚ１．ｃ｝に変換し（Ｆ００９）、エッジＧＷデータ処理テスト部１２６を使って、更新した正規化定義による処理をテストし、問題がない事を確認する。このテストで利用するデータは、デバイス更新処置手段１０４から送られてきたデバイスデータｚ１とデバイスデータｓ１である。テストが問題なく完了すると、影響判定および自動是正処置手段１０２がデバイス更新処置手段１０４に処置の完了と正規化定義の更新を通知し、デバイス更新処置手段１０４が、更新した正規化定義ｒｕｌｅ１を取得し、エッジＧＷデータ処理部１１７−１に反映したうえで、エッジＧＷデータ処理部１１７−１の動作を再開させる（Ｆ０１０−Ｆ０１４）。
【００４６】
その結果、デバイスｓ１の代わりに、新しいデバイスｚ１を使って、今まで実施していたデータ処理を継続することが出来る。
【００４７】
＜本実施形態の効果＞
本実施形態によれば、互換性の無いデバイスのような誤ったデバイスへの交換による不測の事態を回避することができる。その理由は、デバイスｓ１からデバイスｚ１への交換を検知すると、影響判定および是正処置部１０１は、デバイスｚ１から取得したデータがデバイスｓ１の過去データに類似するか否かに基づいて、デバイスｚ１をデバイスｓ１の代替として使用するか否かを決定するためである。
【００４８】
また本実施形態によれば、交換後のデバイスｚ１がマルチセンサの場合であっても、互換性の無いデバイスのような誤ったデバイスへの交換による不測の事態を回避することができる。その理由は、デバイスｓ１からマルチセンサｚ１への交換を検知すると、影響判定および是正処置部１０１は、デバイスｚ１から取得した複数のデータのうちの何れのデータがデバイスｓ１の過去データに類似するか否かを決定して、デバイスｚ１の何れのセンサをデバイスｓ１の代替として使用するか否かを決定するためである。
【００４９】
また本実施形態によれば、新しく接続されたデバイスから発生するデータの意味が不明な状況にあっても、実際に発生するデータの特徴から既存の正規化定義に適用すべきデータを特定し、正規化定義を自動的に修正することで、新しいデバイスに対処できる。
【００５０】
また本実施形態によれば、過去の特徴点のデータから、デバイスデータ間の特徴の違いが最も顕著に表れる時間帯を特定し、新しく接続されたデバイスの同時間帯の実データを採取し、その特徴と比較する事で、元々利用していたデバイスデータの代替として適したデータがどれかを判定できる。そのために実データを採取・転送するデータ量を抑えることが出来、かつ、長時間実データを採取して判定するのに比べて、新しいデバイスの接続からデータ処理を再開するまでの時間を短縮できる。
【００５１】
［第２の実施形態］
本実施形態は、第１の実施形態と比較して、特徴点抽出器と適合度判定器の構成と動作が相違し、それ以外の構成と動作は第１の実施形態と同じである。本実施形態では、特徴点抽出器と適合度判定器に、機械学習技術を応用し、デバイスデータの発生状況を学習し、デバイスデータの種別を分類し、新しく接続されたデバイスのデータがどの種別に分類するかを特定する。
【００５２】
図７は本実施形態に係るセンサ管理システムの要部構成図である。図７に示すように本実施形態では、特徴点抽出器１０６は識別モデル生成装置として機能し、適合度判定器１０３は識別装置として機能する。特徴点抽出器１０６は、センサ交換前に各センサから取得された時系列信号であるセンシングデータに正しいクラスが対応付けられた学習データを入力し、識別モデルを生成して適合度判定器１０３へ送信する。適合度判定器１０３は、この識別モデルを受信して取り込む。そして、センサ交換後のセンサのセンシングデータが送られてくると、受信したセンシングデータが属するクラスを上記識別モデルに従って識別する。
【００５３】
例えば、温度センサｓ１と湿度センサｓ２と風速センサｓ３との３つのセンサがエッジＧＷ装置１４０に接続されているとする。エッジＧＷ装置１４０の特徴点抽出器１０６は、これらのセンサから取得された時系列信号であるセンシングデータに正しいクラス（例えば、それぞれ温度クラス、湿度クラス、風速クラス）が対応付けられた学習データを取り込み、識別モデルを生成する。特徴点抽出器１０６は、生成した識別モデルをバックエンドサーバ１３０の適合度判定器１０３へ送信する。また特徴点抽出器１０６は、識別対象データであるセンサｚ１のセンシングデータｚ１．ｃ、ｚ１．ｄ、ｚ１．ｅを、適合度判定器１０３へ送信する。適合度判定器１０３は、識別モデルを取り込み、識別対象データであるセンサｚ１のセンシングデータについてクラスの識別を行う。適合度判定器１０３は、例えば、センシングデータｚ１．ｃは温度クラス、センシングデータｚ１．ｄは湿度クラス、センシングデータｚ１．ｅは風速クラスとする識別結果を出力する。
【００５４】
本実施形態によれば、温度や湿度といった比較的特徴がわかりやすい特定のデバイスの種類や特性のデータだけでなく、特徴点抽出の方法が簡単には特定できない種別のデバイスであっても、そのデバイスから取得したデータに類似する過去データを決定することができる。また、特徴点抽出器と適合度判定器を入れ替えることで、さまざまなデバイスやデータに対応可能である。
【００５５】
［第３の実施形態］
本実施形態は、第１の実施形態と比較して、エッジＧＷ装置１４０が複数存在することと、影響判定および自動是正処置手段１０２とエッジＧＷプロファイル格納部１０８の構成と動作が相違することで第１の実施形態と相違し、それ以外の構成と動作は第１の実施形態と同じである。本実施形態では、エッジＧＷ装置１４０で処置・対応できたデバイスの情報をエッジＧＷプロファイル格納部１０８に記録しておき、同じエッジＧＷ装置１４０あるいは別のエッジＧＷ装置１４０におけるデバイスの交換時、当該デバイス交換と同一あるいは類似するデバイス交換に係る処置・対応できたデバイスの情報がエッジＧＷプロファイル格納部１０８に存在すれば、それを活用することにより、影響判定および自動是正措置を省略する。
【００５６】
図８は本実施形態に係るセンサ管理システムの要部構成図である。図８に示すように本実施形態では、エッジＧＷプロファイル格納部１０８に、過去に処置・対応できたデバイスの情報が記録されている。デバイスの情報は、交換前デバイスの情報、交換後デバイスの情報、自動処置された正規化定義などを含んでいる。影響判定および自動是正処置手段１０２は、図６のステップＦ００２の終了後、今回のデバイス交換と同一あるいは類似するデバイス交換に係る処置・対応できたデバイスの情報がエッジＧＷプロファイル格納部１０８に存在するか否かを調査する。次に、影響判定および自動是正処置手段１０２は、存在しなければ図６のステップＦ００３以降の処理へと進むが、存在していれば、ステップＦ００３〜Ｆ０１２の処理をスキップしてステップＦ０１３の処理を実行する。そして、このステップＦ０１３では、エッジＧＷプロファイル格納部１０８に記録されている自動処置された正規化定義をエッジＧＷ装置１４０のデータ処理部に反映させ、エッジＧＷデータ処理部１１７を再開させる。
【００５７】
本実施形態によれば次のような効果が得られる。すなわち、実世界では、類似する環境下で同種のデバイスを利用するケースがほとんどのため、第１の実施形態の影響判定と是正処置の処理を１度だけ実行するだけで、他のエッジＧＷ装置の対処も可能になり、最初に対処するエッジＧＷ装置以外は、新しいデバイスを接続してから、その新しいデータを使って処理を行うまでにかかる期間を短縮することができる。
【００５８】
[第４の実施形態]
図９を参照すると、本発明の第４の実施形態に係るセンサ管理システム４００は、複数のセンサ４１１〜４１３を管理するシステムであり、検知部４０１と取得部４０２と交換対処部４０３とを備えている。
【００５９】
センサ４１１〜４１３は、例えば温度センサ、湿度センサ、風力センサなどである。センサ４１１〜４１３は、有線または無線によってセンサ管理システム４００に対して通信可能に接続される。
【００６０】
検知部４０１は、センサ４１１〜４１３が交換されたことを検知する機能を有する。検知部４０１は、専用のハードウェアで実現することができる他、コンピュータとプログラムとで実現することができる。
【００６１】
取得部４０２は、センサ管理システム４００に接続されているセンサからセンシングデータを取得する機能を有する。取得部４０２は、専用のハードウェアで実現することができる他、コンピュータとプログラムとで実現することができる。
【００６２】
交換対処部４０３は、取得部４０２によって取得された交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定する機能を有する。また、交換対処部４０３は、判定結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する機能を有する。交換対処部４０３は、専用のハードウェアで実現することができる他、コンピュータとプログラムとで実現することができる。
【００６３】
次に図１０を参照して、本実施形態に係るセンサ管理システム４００が実行するセンサ管理方法について説明する。
【００６４】
検知部４０１は、センサ管理システム４００の稼働中、センサ４１１〜４１３が別のセンサに交換されたか否かを検知する（Ｆ４０１）。検知部４０１は、センサの交換を検知すると、交換前のセンサを一意に識別する情報と交換後のセンサを一意に識別する情報とを含むセンサ交換検知情報を取得部４０２に通知する。識別情報は、センサを一意に識別できる数字列や文字列等である。例えば、センサに割当てられたＵＳＢアドレスやＭＡＣアドレスを識別情報にして良いが、それに限定されるものではない。
【００６５】
取得部４０２は、検知部４０１からセンサ交換検知情報を受信すると、それに含まれる交換後のセンサの識別情報によって特定されるセンサとの間で通信を行い、交換後のセンサからセンシングデータを取得する（Ｆ４０２）。取得部４０２は、取得したセンシングデータと上記センサ交換検知情報とを交換対処部４０３に通知する。
【００６６】
交換対処部４０３は、取得部４０２から交換後のセンサのセンシングデータとセンサ交換検知情報とを受信すると、センサ交換検知情報に含まれる交換前のセンサの識別情報によって特定されるセンサの過去のセンシングデータを図示しない記憶装置から読み出し、交換前後のセンサのセンシングデータが互いに類似しているか否かを判定する（Ｆ４０３）。次に、交換対処部４０３は、判定結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する。具体的には、交換対処部４０３は、交換前後のセンサのセンシングデータが互いに類似するならば、交換後のセンサを交換前のセンサの代替として使用することを決定する（Ｆ４０４）。このとき、交換対処部４０３は、交換後のセンサを交換前のセンサの代替として使用する旨のメッセージを図示しない表示装置に表示し、また図示しない外部装置へ通信によって通知するようにしてよい。他方、交換対処部４０３は、交換前後のセンサのセンシングデータが互いに類似していなければ、交換後のセンサを交換前のセンサの代替として使用しないことを決定する（Ｆ４０４）。このとき、交換対処部４０３は、交換後のセンサを交換前のセンサの代替として使用しない旨のメッセージを図示しない表示装置に表示し、また図示しない外部装置へ通信によって通知するようにしてよい。交換対処部４０３による上述した動作の後、検知部４０１による上述した動作が再び実行される。
【００６７】
このように本実施形態によれば、互換性の無いセンサのような誤ったセンサへの交換による不測の事態を回避することができる。その理由は、センサの交換を検知すると、交換後のセンサからセンシングデータを取得し、交換前のセンサの過去データに類似するか否かを判定し、その判定結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定するため、互換性の無いセンサのような誤ったセンサへ交換された場合、交換前のセンサの代替として使用されないためである。
【００６８】
次に、本実施形態における検知部４０１、取得部４０２、および交換対処部４０３について、詳細に説明する。
【００６９】
＜検知部４０１＞
図１１は、検知部４０１の一例を示す動作フローチャートである。図１１を参照すると、検知部４０１は、センサ管理システム４００の初期化処理の一環として、接続されているセンサ４１１〜４１３の識別情報を検出し、図示しないセンサリストに登録する（Ｆ４１１）。例えば、センサ４１１〜４１３がセンサ管理システム４００を構成するコンピュータにＵＳＢインタフェースを通じて接続されている場合、ＵＳＢに接続されているセンサをサーチし、例えば、センサのＵＳＢ接続時に割当てられるアドレスをセンサの識別情報として検出し、センサリストに登録する。また、センサ４１１〜４１３が、センサ管理システム４００を構成するコンピュータにＷｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）等の無線インタフェースを通じて接続されている場合、周囲に存在するセンサをサーチし、或いは予め登録されている接続センサのリストを参照し、例えば、センサのＭＡＣアドレスをセンサの識別情報として検出し、センサリストに登録する。
【００７０】
その後、センサ管理システム４００が稼働すると、検知部４０１は、センサ管理システム４００にセンサが接続されたか否かを常時検出する（Ｆ４１２）。ここで、センサが接続されるとは、ＵＳＢ接続であれば、例えば、センサが接続されてその電源がオンされたことなどを意味する。また、センサが接続されるとは、無線接続であれば、例えば、センサから接続要求やデータを受信することなどを意味する。そして、検知部４０１は、センサの接続を検出すると、以下の処理を実行する。
【００７１】
まず検知部４０１は、接続したセンサの識別情報を検出し（Ｆ４１３）、同一の識別情報がセンサリストに存在するか否かを判定する（Ｆ４１４）。検知部４０１は、接続したセンサの識別情報と同一の識別情報がセンサリストに存在する場合、接続したセンサは再接続されたものであるため、交換後のセンサとして検出せず（Ｆ４１５）、ステップＦ４１２の処理へ戻る。
【００７２】
一方、検知部４０１は、接続したセンサの識別情報と同一の識別情報がセンサリストに存在しない場合、接続したセンサは追加されたセンサであるため、交換後のセンサとして検出する（Ｆ４１６）。次に、検知部４０１は、センサリストに識別情報が記載されている全てのセンサとの間で通信を試行し、通信を行えないセンサを検出する（Ｆ４１７）。
【００７３】
検知部４０１は、通信を行えなかったセンサが１台のみであった場合（Ｆ４１８）、この通信を行えなかったセンサを交換前のセンサとして検出する（Ｆ４１９）。次に、検知部４０１は、ステップＦ４１６で検出した交換後のセンサとステップＦ４１９で検出した交換前のセンサとの識別情報を含むセンサ交換検知情報を交換対処部４０３へ出力する（Ｆ４２０）。そして、検知部４０１はステップＦ４１２の処理へ戻る。
【００７４】
他方、検知部４０１は、通信を行えなかったセンサが１台でなかった場合、接続したセンサを交換後デバイスとして検出せず（Ｆ４１５）、ステップＦ４１２の処理へ戻る。その理由は、通信を行えなかったセンサが全く存在しなかった場合、今回接続したセンサは既存センサとの交換でなく増設と考えられるためである。また、通信を行えなかったセンサが２台以上存在した場合、その何れが交換前のセンサであるか不明であるため、安全を重視する観点から今回接続したセンサを交換後のセンサから除外するようにしている。ここで、センサの交換作業を１台のセンサずつ実施することにより、ステップＦ４１８からステップＦ４１５へ進むケースは実質的に皆無となる。
【００７５】
このように図１１に示す例の検知部４０１は、センサ管理システム４００に新たに接続されたセンサを交換後のセンサとして検知し、交換後のセンサの接続前にセンサ管理システム４００に接続されていたセンサのうち交換後のセンサの接続後にセンサ管理システム４００との間で通信が行えなくなったセンサを交換前のセンサとして検知する。
【００７６】
図１２は、検知部４０１の別の例を示す動作フローチャートである。図１２を参照すると、検知部４０１は、センサ管理システム４００の初期化処理の一環として、接続されているセンサ４１１〜４１３の識別情報を検出し、図示しないセンサリストに登録する（Ｆ４２１）。このステップＦ４２１は図１１のステップＦ４１１と同じである。
【００７７】
その後、センサ管理システム４００が稼働すると、検知部４０１は、図示しないキーボード等の入力装置からセンサ管理システム４００に対してセンサの交換開始の指示が入力されたか否かを常時検出する（Ｆ４２２）。そして、検知部４０１は、センサの交換開始の指示が入力されると、図示しない表示装置にセンサリストを表示し、交換前のセンサを選択するようユーザに催促する（Ｆ４２３）。
【００７８】
次に検知部４０１は、ユーザがセンサのリスト上で１つのセンサを選択すると（Ｆ４２４）、選択されたセンサを交換前センサとして検出する（Ｆ４２５）。次に検知部４０１は、一定時間内にセンサがセンサ管理システム４００に接続されたか否かを検出する（Ｆ４２６）。ここで、センサが接続されるとは、ＵＳＢ接続であれば、例えば、センサが接続されてその電源がオンされたことなどを意味する。また、センサが接続されるとは、無線接続であれば、例えば、センサから接続要求やデータを受信することなどを意味する。
【００７９】
検知部４０１は、一定時間内にセンサが接続された場合、接続されたセンサの識別情報を交換後センサの識別情報として検出する（Ｆ４２７）。次に検知部４０１は、ステップＦ４２７で検出した交換後のセンサとステップＦ４２５で検出した交換前のセンサとの識別情報を含むセンサ交換検知情報を交換対処部４０３へ出力する（Ｆ４２８）。そして、検知部４０１はステップＦ４２２の処理へ戻る。他方、検知部４０１は、一定時間内にセンサが接続されなかった場合、ステップＦ４２７、Ｆ４２８をスキップし、ステップＦ４２２の処理へ戻る。
【００８０】
このように図１２の例の検知部４０１は、センサ管理システム４００に接続されているセンサのリストから利用者が選択したセンサを交換前のセンサとして検出し、その後にセンサ管理システム４００に新たに接続されたセンサを交換後のセンサとして検出する。但し、交換前後のセンサの検出順序を上記と逆にしても良い。即ち、検知部４０１は、センサ管理システム４００に新たに接続されたセンサを交換後のセンサとして検出し、その後の一定時間内にセンサのリストから選択されたセンサを交換前センサとして検出するようにしてもよい。
【００８１】
＜取得部４０２＞
取得部４０２は、センサ管理システム４００に接続されているセンサからセンシングデータを取得するデバイスドライバを含んで構成される。取得部４０２は、自律的にセンサからセンシングデータを取得することができると共に、交換対処部４０３からの要求に従って要求されたセンサからセンシングデータを取得することができる。
【００８２】
＜交換対処部４０３＞
図１３は、交換対処部４０３の一例を示す構成図である。この例の交換対処部４０３は、特徴量抽出部４３１と過去データ記憶部４３２と交換後センサデータ記憶部４３３と照合部４３４とドライバ更新部４４０とを備えている。
【００８３】
ドライバ更新部４４０は、検知部４０１によって検出された交換後のセンサに対応するデバイスドライバを図示しないデバイスドライバリポジトリから取得し、取得部４０２のデバイスドライバを更新する機能を有する。
【００８４】
特徴量抽出部４３１は、取得部４０２を利用して取得されたセンサのセンシングデータからｍ種類（ｍは１以上の整数）の特徴量を抽出する機能を有する。例えば、特徴量抽出部４３１は、１日当たりのセンシングデータの平均値、分散、標準偏差、１時間単位での傾き（変化率）等を抽出する。１種類の特徴量を１つの次元としてｍ種類の特徴量を所定の順序で並べると、ｍ次元の特徴ベクトルが形成される。
【００８５】
過去データ記憶部４３２は、センサの交換前に取得部４０２によって取得され特徴量抽出部４３１によって抽出されて生成された特徴ベクトルをセンサの識別情報に関連付けて記憶する機能を有する。例えば、過去データ記憶部４３２は、センサ識別情報ｓ１に対応して、特徴ベクトル（Ｆ1.1，Ｆ1.2，…，Ｆ1.m）を記憶している。ここで、Ｆ1.iは、センサ識別情報ｓ１で識別されるセンサのセンシングデータから取得したｉ番目の次元の特徴量である。また、交換後センサデータ記憶部４３３は、交換後のセンサから取得部４０２によって取得され特徴量抽出部４３１によって抽出されて生成された特徴ベクトルを交換後センサの識別情報に関連付けて記憶する機能を有する。例えば、交換後センサデータ記憶部４３３は、センサ識別情報ｚ１に対応して、特徴ベクトル（ＦZ.1，ＦZ.2，…，ＦZ.m）を記憶している。
【００８６】
照合部４３４は、交換後センサデータ記憶部４３３から交換後のセンサの特徴ベクトルを読み出し、検知部４０１によって検出された交換前のセンサの特徴ベクトルを過去データ記憶部４３２から読み出す。そして、照合部４３４は、両者の特徴ベクトル間のベクトル間距離を計算し、そのベクトル間距離を閾値と比較して、両者が類似するか否かを判定する。ベクトル間距離は、例えば、同じ次元の特徴量が同一或いはその差の絶対値が所定値以下であれば、例えばビット値０を割当て、それ以外であればビット値１を割当て、ビット値１の数をベクトル間距離とする。このベクトル間距離によれば、両者の特徴量が同一或いはその差の絶対値が所定値以下であれば、ベクトル間距離は０になり、同一ないしその差の絶対値が所定値以下でない種類の特徴量が増えるに従って、１より次第に大きな値になる。そこで、ベクトル間距離を閾値（例えば値０）と比較し、ベクトル間距離が閾値以下であれば類似、そうでなければ非類似とする。照合部４３４は、類似であれば、交換後のセンサを交換前のセンサの代替として使用することを決定し、非類似であれば、交換後のセンサを交換前のセンサの代替として使用しないことを決定する。照合部４３４は、この決定結果を図示しない表示装置に表示しあるいは通信により外部装置へ送信する。
【００８７】
このように図１３の交換対処部４０３は、交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと交換前のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離が閾値以下か否かに基づいて、類似するか否かを判定し、さらに、その判定結果に基づいて交換後のセンサを交換前のセンサの代替として使用するか否かを決定する。
【００８８】
図１４は、交換対処部４０３の他の例を示す構成図である。この例の交換対処部４０３は、識別モデル生成部４３５とセンサ識別情報・クラス対応表４３６と識別モデル記憶部４３７と識別部４３８と比較部４３９とドライバ更新部４４０とを備えている。このうち、ドライバ更新部４４０は、図１３のドライバ更新部４４０と同様の機能を有する。
【００８９】
センサ識別情報・クラス対応表４３６は、センサ識別情報とクラスとの対応関係を記録する。例えば、センサ識別情報・クラス対応表４３６は、温度センサの識別情報に対応付けて温度クラスを記録し、湿度センサの識別情報に対応付けて湿度クラスを記録し、風力センサの識別情報に対応付けて風力クラスを記録している。
【００９０】
識別モデル生成部４３５は、センサ交換前に取得部４０２によって各センサから取得された時系列信号であるセンシングデータを入力し、当該センシングデータの取得元センサの識別情報に対応するクラスをセンサ識別情報・クラス対応表４３６から取得し、上記入力したセンシングデータに上記取得したクラスを対応付けた学習データを使用して、識別モデルを生成する。
【００９１】
識別部４３８は、取得部４０２によって取得された交換後のセンサのセンシングデータを入力し、識別モデル記憶部４３７に記憶された識別モデルを使用して、上記入力したセンシングデータが属するクラスを識別し、識別したクラスを比較部４３９に出力する。比較部４３９は、検知部４０１によって検出された交換前のセンサの識別情報に対応するクラスをセンサ識別情報・クラス対応表４３６から取得し、この取得したクラスと識別部４３８の識別結果のクラスとを比較する。そして、比較部４３９は、比較結果が一致であれば、交換前後のセンサのセンシングデータが互いに類似していると判定し、交換後のセンサを交換前のセンサの代替として使用することを決定する。また、比較部４３９は、比較結果が不一致であれば、交換前後のセンサのセンシングデータが互いに非類似であると判定し、交換後のセンサを交換前のセンサの代替として使用しないことを決定する。
【００９２】
このように図１４の交換対処部４０３は、センサの交換前に、センサから取得されたセンシングデータに正解クラスを対応付けた学習データを使用して識別モデルを生成し、センサの交換時、交換後のセンサから取得されたセンシングデータと上記識別モデルとを用いて交換後のセンサが属するクラスを識別し、この識別したクラスと交換前のセンサが属するクラスとの比較結果に基づいて、類似するか否かを判定し、さらに、その判定結果に基づいて交換後のセンサを交換前のセンサの代替として使用するか否かを決定する。
【００９３】
[第５の実施形態]
本発明の第５の実施形態に係るセンサ管理システム５００は、第４の実施形態に係るセンサ管理システム４００と比較して、交換対処部４０３の機能が相違し、それ以外は第４の実施形態と同一である。
【００９４】
本実施形態における交換対処部４０３は、交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換前のセンサの代わりに交換後のセンサを使用してシステムを運用する機能を有する。
【００９５】
次に図１５を参照して、本実施形態に係るセンサ管理システム５００が実行するセンサ管理方法について説明する。
【００９６】
図１５において、ステップＦ５０１〜Ｆ５０５は、図１０のステップＦ４０１〜Ｆ４０５と同じである。本実施形態では、交換対処部４０３は、交換後のセンサを交換前のセンサの代替として使用することを決定した後、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する（Ｆ５０６）。このステップＦ５０６では、運用開始前に、第１の実施形態において説明したような正規化定義の書き換えやテストが実施され、問題無いことを確認した後、運用が開始される。
【００９７】
[第６の実施形態]
本発明の第６の実施形態に係るセンサ管理システム６００は、第４または第５の実施形態に係るセンサ管理システム４００、５００と比較して、検知部４０１の機能が相違し、それ以外は第４または第５の実施形態と同一である。
【００９８】
図１６は本実施形態における検知部４０１の処理の一例を示す要部フローチャートである。本実施形態における検知部４０１は、図１１に示すフローチャートのステップＦ４１８において、通信を行えないセンサが１つでないと判定したとき、直ちにステップＦ４１５へ進まず、その代わりに図１６に示すステップＦ６０１〜Ｆ６０５を実行するように構成されている。
【００９９】
図１６を参照すると、検知部４０１は、通信を行えないセンサが１つでない場合、通信を行えないセンサが０か否かを判定する（Ｆ６０１）。次に、検知部４０１は、通信を行えないセンサが０であれば、図１１のステップＦ４１５へ進む。他方、検知部４０１は、通信を行えないセンサが２台以上であれば、それらのセンサの位置と交換後センサの位置とを検出する（Ｆ６０２）。検知部４０１は、例えば、センサの位置をそのセンサから取得したセンシングデータから抽出することにより検出することができる。即ち、一般にセンサのセンシングデータには、センサで検出した温度データ等のデータと区別して、センサに搭載されたＧＰＳで検出した当該センサの位置データが含まれている。検知部４０１は、その位置データを抽出することにより、センサの位置を検出する。
【０１００】
次に検知部４０１は、通信を行えない複数のセンサの中から、交換後のセンサと同一または近傍の位置に存在するセンサを選択する（Ｆ６０３）。次に検知部４０１は、選択したセンサが１台のみか否かを判定する（Ｆ６０４）。１台のみでなく複数台であれば、検知部４０１は図１１のステップＦ４１５へ進む。１台のみであれば、検知部４０１は、その１台を交換前のセンサとして検出する（Ｆ６０５）。そして、検知部４０１は、図１１のステップＦ４２０へ進む。
【０１０１】
このように本実施形態の検知部４０１は、センサ管理システムとの間で通信が行えなくなったセンサが複数存在する場合、センサ管理システムとの間で通信が行えなくなったセンサの位置情報と交換後のセンサの位置情報とを比較した結果に基づいて交換前のセンサを検知する。
【０１０２】
以上、本発明を幾つかの実施形態を挙げて説明したが、本発明は以上に実施形態にのみ限定されず、その他、本発明の範囲内で各種の付加変更が可能である。
【産業上の利用可能性】
【０１０３】
本発明は、業界を問わない、汎用的なＩｏＴデータ処理の基盤として利用でき、特にセンサを管理する基盤として利用できる。
【０１０４】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
センサを管理するセンサ管理システムであって、
前記センサ管理システムに接続されたセンサの交換を検知する検知手段と、
センサからセンシングデータを取得する取得部と、
前記取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する交換対処手段と、
を有するセンサ管理システム。
［付記２］
前記交換対処手段は、交換後のセンサが複数のサブセンサを有する場合、前記複数のサブセンサのそれぞれからセンシングデータを取得し、前記取得したセンシングデータのそれぞれについて交換前のセンサの過去のセンシングデータに類似するか否かを判定する、
付記１に記載のセンサ管理システム。
［付記３］
前記交換対処手段は、交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する、
付記１または２に記載のセンサ管理システム。
［付記４］
前記交換対処手段は、交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する前に、交換前のデバイスのセンシングデータを正規化するための正規化定義を交換後のデバイスに合致するように書き換える、
付記１乃至３の何れかに記載のセンサ管理システム。
［付記５］
前記交換対処手段は、交換後のセンサを交換前のセンサの代替として運用する前に、書き換え後の前記正規化定義を使用して交換後のデバイスから取得したセンシングデータを用いたテストを実施する、
付記４に記載のセンサ管理システム。
［付記６］
前記交換対処手段は、前記テストに成功した交換後のセンサの情報と交換前のセンサの情報と前記正規化定義とを含むデバイス情報を記憶し、その後、前記センサ管理システムに接続されたセンサの交換が前記検知手段によって検知されると、検知された交換後のセンサの情報と交換前のセンサの情報とを含む前記デバイス情報の有無に基づいて、今回のセンサ交換に伴う前記正規化定義の書き換えと前記テストの実施の必要性の有無を決定する、
付記５に記載のセンサ管理システム。
［付記７］
前記交換対処手段は、前記類似するか否かの判定では、交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと交換前のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離が閾値以下か否かに基づいて、前記類似の判定を行う、
付記１乃至６の何れかに記載のセンサ管理システム。
［付記８］
前記交換対処手段は、交換前のセンサの１日のセンシングデータのうちデータの変化が激しい時間帯のセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと、前記時間帯と同じ時間帯における交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離が閾値以下か否かに基づいて、前記類似の判定を行う、
付記１乃至６の何れかに記載のセンサ管理システム。
［付記９］
前記交換対処手段は、前記類似するか否かの判定では、センサの交換前に、センサから取得されたセンシングデータに正解クラスを対応付けた学習データを使用して識別モデルを生成し、センサの交換時、交換後のセンサから取得されたセンシングデータと前記識別モデルとを用いて交換後のセンサが属するクラスを識別し、前記識別したクラスと交換前のセンサが属するクラスとの比較結果に基づいて、前記類似の判定を行う、
付記１乃至６の何れかに記載のセンサ管理システム。
［付記１０］
前記検知手段は、前記センサ管理システムに新たに接続されたセンサを交換後のセンサとして検知し、交換後のセンサの接続前に前記センサ管理システムに接続されていたセンサのうち前記交換後のセンサの接続後に前記センサ管理システムとの間で通信が行えなくなったセンサを交換前のセンサとして検知する、
付記１乃至９の何れかに記載のセンサ管理システム。
［付記１１］
前記検知手段は、前記センサ管理システムとの間で通信が行えなくなったセンサが複数存在する場合、前記センサ管理システムとの間で通信が行えなくなったセンサの位置情報と交換後のセンサの位置情報とを比較した結果に基づいて交換前のセンサを検知する、
付記１０に記載のセンサ管理システム。
［付記１２］
前記検知手段は、前記センサ管理システムに新たに接続されたセンサを交換後のセンサとして検知し、前記センサ管理システムに接続されているセンサのリストから利用者が選択したセンサを交換前のセンサとして検知する、
付記１乃至９の何れかに記載のセンサ管理システム。
［付記１３］
センサ管理システムにおけるセンサを管理する方法であって、
前記センサ管理システムに接続されたセンサの交換を検知し、
交換後のセンサからセンシングデータを取得し、
取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、
前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する、
センサ管理方法。
［付記１４］
前記類似するか否かの判定では、交換後のセンサが複数のサブセンサを有する場合、前記複数のサブセンサのそれぞれからセンシングデータを取得し、前記取得したセンシングデータのそれぞれについて交換前のセンサの過去のセンシングデータに類似するか否かを判定する、
付記１３に記載のセンサ管理方法。
［付記１５］
交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する、
付記１３または１４に記載のセンサ管理方法。
［付記１６］
交換後のセンサを交換前のセンサの代替として使用することを決定すると、交換後のセンサを交換前のセンサの代替として使用してシステムを運用する前に、交換前のデバイスのセンシングデータを正規化するための正規化定義を交換後のデバイスに合致するように書き換える、
付記１３乃至１５の何れかに記載のセンサ管理方法。
［付記１７］
交換後のセンサを交換前のセンサの代替として運用する前に、書き換え後の前記正規化定義を使用して交換後のデバイスから取得したセンシングデータを用いたテストを実施する、
付記１６に記載のセンサ管理方法。
［付記１８］
前記テストに成功した交換後のセンサの情報と交換前のセンサの情報と前記正規化定義とを含むデバイス情報を記憶し、その後、前記センサ管理システムに接続されたセンサの交換を検知すると、検知した交換後のセンサの情報と交換前のセンサの情報とを含む前記デバイス情報の有無に基づいて、今回のセンサ交換に伴う前記正規化定義の書き換えと前記テストの実施の必要性の有無を決定する、
付記１７に記載のセンサ管理方法。
［付記１９］
前記類似するか否かの判定では、交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと交換前のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離が閾値以下か否かに基づいて、前記類似の判定を行う、
付記１３乃至１８の何れかに記載のセンサ管理方法。
［付記２０］
前記類似するか否かの判定では、交換前のセンサの１日のセンシングデータのうちデータの変化が激しい時間帯のセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルと、前記時間帯と同じ時間帯における交換後のセンサのセンシングデータから抽出した所定種別数の特徴量から成る特徴ベクトルとの間のベクトル間距離が閾値以下か否かに基づいて、前記類似の判定を行う、
付記１３乃至１８の何れかに記載のセンサ管理方法。
［付記２１］
前記類似するか否かの判定では、センサの交換前に、センサから取得されたセンシングデータに正解クラスを対応付けた学習データを使用して識別モデルを生成し、センサの交換時、交換後のセンサから取得されたセンシングデータと前記識別モデルとを用いて交換後のセンサが属するクラスを識別し、前記識別したクラスと交換前のセンサが属するクラスとの比較結果に基づいて、前記類似の判定を行う、
付記１３乃至１８の何れかに記載のセンサ管理方法。
［付記２２］
前記センサの交換の検知では、前記センサ管理システムに新たに接続されたセンサを交換後のセンサとして検知し、交換後のセンサの接続前に前記センサ管理システムに接続されていたセンサのうち前記交換後のセンサの接続後に前記センサ管理システムとの間で通信が行えなくなったセンサを交換前のセンサとして検知する、
付記１３乃至２１の何れかに記載のセンサ管理方法。
［付記２３］
前記センサ管理システムとの間で通信が行えなくなったセンサが複数存在する場合、前記センサ管理システムとの間で通信が行えなくなったセンサの位置情報と交換後のセンサの位置情報とを比較した結果に基づいて交換前のセンサを検知する、
付記２２に記載のセンサ管理方法。
［付記２４］
前記センサの交換の検知では、前記センサ管理システムに新たに接続されたセンサを交換後のセンサとして検知し、前記センサ管理システムに接続されているセンサのリストから利用者が選択したセンサを交換前のセンサとして検知する、
付記１３乃至２１の何れかに記載のセンサ管理方法。
［付記２５］
コンピュータを、
前記センサ管理システムに接続されたセンサの交換を検知する検知手段と、
センサからセンシングデータを取得する取得部と、
前記取得部により取得した交換後のセンサのセンシングデータが交換前のセンサの過去のセンシングデータに類似するか否かを判定し、前記判定の結果に基づいて、交換後のセンサを交換前のセンサの代替として使用するか否かを決定する交換対処手段と、
して機能させるためのプログラム。
【符号の説明】
【０１０５】
１００…センサ管理システム
１０１…影響判定および是正処置部
１０２…影響判定および自動是正処理手段
１０３…適合度判定器
１０４…デバイス更新処置手段
１０５…エッジＧＷプロファイル生成手段
１０６…特徴点抽出器
１０７…プロファイル一時格納部
１０８…エッジＧＷプロファイル格納部
１１１−１…デバイスｓ１
１１１−２…デバイスｓ２
１１１−Ｎ…デバイスＮ
１１２−１…デバイスドライバ１
１１２−２…デバイスドライバ２
１１２−Ｎ…デバイスドライバＮ
１１３…デバイス検知・ドライバ更新部
１１４…デバイスデータ採取部
１１５…データ処理結果採取部
１１６…データ送信部
１１７−１…エッジＧＷデータ処理部１
１１７−２…エッジＧＷデータ処理部２
１２１…データ受信部
１２２…データ処理部
１２３…データ格納部
１２４…デバイスドライバリポジトリ
１２５…正規化定義・データフロー定義・ユーザロジックリポジトリ
１２６…エッジＧＷデータ処理テスト部
４００…センサ管理システム
４０１…検知部
４０２…取得部
４０３…交換対処部
４１１…センサ
４１２…センサ
４１３…センサ
４３１…特徴量抽出部
４３２…過去データ記憶部
４３３…交換後センサデータ記憶部
４３４…照合部
４３５…識別モデル生成部
４３６…センサ識別情報・クラス対応表
４３７…識別モデル記憶部
４３８…識別部
４３９…比較部
４４０…ドライバ更新部
【図１】
2018054360.tif 000003
【図２】
2018054360.tif 000004
【図３】
2018054360.tif 000005
【図４】
2018054360.tif 000006
【図５】
2018054360.tif 000007
【図６】
2018054360.tif 000008
【図７】
2018054360.tif 000009
【図８】
2018054360.tif 000010
【図９】
2018054360.tif 000011
【図１０】
2018054360.tif 000012
【図１１】
2018054360.tif 000013
【図１２】
2018054360.tif 000014
【図１３】
2018054360.tif 000015
【図１４】
2018054360.tif 000016
【図１５】
2018054360.tif 000017
【図１６】
2018054360.tif 000018