【文献】
KABADAYI Sanem, et al.,"Virtual Sensors: Abstracting Data from Physical Sensors",2006 International Symposium on a World of Wireless, Mobile and Multimedia Networks,米国,IEEE,2006年,pp. 1-6
【文献】
小澤 みゆき 外1名,“物理/仮想統合センサメッセージングシステム”,電子情報通信学会技術研究報告 IEICE Technical Report,日本,一般社団法人電子情報通信学会,2013年12月11日,第113巻,pp. 243-248
(58)【調査した分野】(Int.Cl.,DB名)
前記抽出されたデバイスが実デバイスである場合、前記データフロー指示部は、前記実デバイスまたは前記実デバイスを管理する装置に対して、前記実デバイスから前記アプリケーションへのデータの送信を指令する第3のデータフロー制御指令を送信する
ことを特徴とする請求項1に記載のデータフロー制御装置。
コンピュータが、複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部から、デバイス側メタデータを取得するステップと、
コンピュータが、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部から、アプリ側メタデータを取得するステップと、
コンピュータが、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションが要求する仕様を満たすデータを提供可能なデバイスを抽出するステップと、
コンピュータが、前記マッチングの結果に基づき、データの送信を指令するデータフロー制御指令を生成し送信するステップと、を有し、
前記抽出されたデバイスが、1以上の元デバイスから得られるデータをもとに新たなデータを生成し仮想データとして出力する仮想デバイスである場合、前記データフロー制御指令を送信するステップでは、
前記元デバイスまたは前記元デバイスを管理する装置に対して、前記元デバイスから前記仮想デバイスへのデータの送信を指令する第1のデータフロー制御指令が送信されるとともに、
前記仮想デバイスまたは前記仮想デバイスを管理する装置に対して、前記仮想デバイスから前記アプリケーションへの仮想データの送信を指令する第2のデータフロー制御指令が送信される
ことを特徴とするデータフロー制御方法。
【背景技術】
【0002】
現在、M2Mクラウドと呼ばれるIT環境が注目を集めている。M2M(Machine to Machine)とは、様々な用途、大きさや性能を持つ機械同士がネットワーク上で情報をやり取りするシステムを指す。この情報を利用することで、それぞれの機械の適切な制御や、実社会の状況解析が可能になる。M2Mを支える無線通信技術の向上や機械の小型化、低廉化などにより、実用化への期待が高まっている。
【0003】
このようなM2Mの技術をクラウドコンピューティング環境上で実現したものはM2Mクラウドと呼ばれる。これは、M2Mに必要な基本機能、例えばデータの収集蓄積から加工、分析のようなサービスをクラウド上のアプリケーションとして提供し、どこからでも利用可能にしたものである。データの一括管理によって信頼性や網羅性を高めることができる。また利用者にとっては、収集されたデータやコンピュータ資源を必要な分だけ利用できるメリットがある。そのため、個別にシステムを構築することなくビッグデータを解析して付加価値を得ることが可能であり、幅広い分野での応用が期待されている。
【0004】
また、特許文献1に示すように、センサネットワークと呼ばれる技術が検討されている。これは、センシング機能と通信機能をもつセンサデバイス(以下、単に「センサ」とも呼ぶ)を様々な場所、移動体、産業設備などに設置し、それらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能とするものである。
【0005】
通常、センサは、その所有者自身が必要とするデータを収集するために設置される。そのため所有者がデータ収集を行うとき以外は利用されていない(センサ自体が稼働していない、またはセンサが稼働していてもセンシングデータが利用されない)ことが多い。そのためセンシングデータの流通性は低く、第三者にとっていかに有意義なデータであっても、センサの所有者自身による分析、利用に留まっていた。その結果、設備の重複投資や、各自が設置したセンサとの通信によるネットワークの輻湊を招いていた。
【0006】
また、IoT(Internet of Things)という技術が検討されている。これは、世界に存在する多くの物に関する情報をネット上で組み合わせることで新しい価値を生むもので、社会インフラを始めとする様々なサービスのシームレスな展開が期待されている。IoTから価値を生み出すためには、ネットに繋がる物の状態を知る必要があり、センシングと通信が重要な要素技術となる。
【発明の概要】
【発明が解決しようとする課題】
【0008】
本出願人は、IoTにおいてセンシングデータなどの情報資源を適切に流通させる仕組みを実現するため、センサに関する情報が記述された「センサ側メタデータ」とセンシングデータを利用するアプリケーションに関する情報が記述された「アプリ側メタデータ」
とのマッチングを行うことで、アプリケーションの要求を満たすセンシングデータを取得可能なセンサを特定し、センサからアプリケーションへのデータフローを制御するシステムを検討している(特許文献2参照)。
【0009】
さらに本出願人は、センサネットワークを発展・拡大させる要素技術の一つとして「仮想センサ」と呼ばれる技術に注目している(特許文献2参照)。例えば、元センサから得られるセンシングデータを加工して新たなデータとして出力するプログラムモジュールを仮想センサとして用意し、センサネットワークの利用者に提供すれば、利用者は実センサとの区別なく仮想センサを利用できる。このような仮想センサの導入により、センシングデータの利活用の促進、新たな付加価値をもつセンシングデータの提供など、様々な効果が期待できる。また、実センサを保有していない者も仮想センサ事業者として流通市場に参入でき、市場の発展につながると期待できる。
【0010】
ところで、センサからアプリケーションへのデータフロー制御を実現するにあたっては、実センサの場合と仮想センサの場合とで異なる仕組みが必要とされる。実センサの場合は、データ提供側の「実センサ」(または実センサをネットワークに接続する機器であるセンサネットワークアダプタ)とデータ利用側の「アプリケーション」の間の一対一のデータ交換でよいのに対し、仮想センサの場合は、仮想センサとアプリケーションの二者間だけでなく、仮想センシングデータの生成に必要な元データの提供元となる「元センサ」と「仮想センサ」と「アプリケーション」の三者間のデータ交換が必要だからである。
【0011】
例えば、仮想センサが能動的に必要な元データを実センサから収集し蓄積するという仕組みを採用することも考えられる。しかしそのような仕組みの場合は、仮想センサにデータ収集のための機能が必要になるとともに、収集したデータを蓄積するための大容量のデータベースが必要となる。また、仮想センサにおいてデータ収集・管理のための余計な負荷が発生し、仮想センサからアプリケーションへのデータ提供に支障を生じる可能性がある。それゆえ、実センサから仮想センサへのデータフローを簡易かつ効率的に実現する仕組みが望まれる。
【0012】
なお、ここまでセンサネットワークを例に挙げて説明をしたが、センサ以外の装置が出力(提供)するデータを流通させるネットワークにおいても、全く同様の課題が発生し得る。センサ以外の装置としては、例えば、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ATMなど、何らかのデータを出力する装置であればどのような物も該当し得る。本明細書では、これらの装置(センサも含む)を包含する概念として「デバイス」という用語を用い、このようなデバイスが出力(提供)するデータを流通させるネットワークを「デバイスネットワーク」と呼ぶ。デバイスネットワークには、上に例示した様々な種類のデバイスが混在して接続されることもあり得る。
【0013】
本発明は上記実情に鑑みなされたものであり、デバイスネットワークにおける仮想デバイスのデータの効率的なデータフローを実現するための技術を提供することを目的とする。
【課題を解決するための手段】
【0014】
請求項1に係る発明は、複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部と、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部と、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションの
要求する仕様を満たすデータを提供可能なデバイスを抽出するマッチング部と、前記マッチング部のマッチング結果に基づき、データの送信を指令するデータフロー制御指令を生成し送信するデータフロー指示部と、を有し、前記抽出されたデバイスが、1以上の元デバイスから得られるデータをもとに新たなデータを生成し仮想データとして出力する仮想デバイスである場合、前記データフロー指示部は、前記元デバイスまたは前記元デバイスを管理する装置に対して、前記元デバイスから前記仮想デバイスへのデータの送信を指令する第1のデータフロー制御指令を送信するとともに、前記仮想デバイスまたは前記仮想デバイスを管理する装置に対して、前記仮想デバイスから前記アプリケーションへの仮想データの送信を指令する第2のデータフロー制御指令を送信することを特徴とするデータフロー制御装置である。
【0015】
請求項1に係る発明によれば、仮想デバイスの場合に、第1のデータフロー制御指令と第2のデータフロー制御指令の2つが生成され、第1のデータフロー制御指令が元デバイス(仮想データの生成に必要な元データの提供元のデバイス)または元デバイスを管理する装置に対し送信され、第2のデータフロー制御指令が仮想デバイスまたは仮想デバイスを管理する装置に対し送信される。そして、第1のデータフロー制御指令に基づいて元デバイスから仮想デバイスへの元データの送信が実行され、第2のデータフロー制御指令に基づいて仮想デバイスからアプリケーションへの仮想データの送信が実行されることで、「元デバイス」と「仮想デバイス」と「アプリケーション」の三者間のデータ交換が行われる。この仕組みによれば、仮想データの生成に必要な元データが自動的に仮想デバイスへと送られるため、仮想デバイスが自ら(能動的に)必要な元データを収集したり蓄積したりする必要がなく、データ収集・管理のための余計な負荷も発生しない。よって、仮想データの効率的なデータフローを実現することができる。
【0016】
請求項2に係る発明は、前記抽出されたデバイスが実デバイスである場合、前記データフロー指示部は、前記実デバイスまたは前記実デバイスを管理する装置に対して、前記実デバイスから前記アプリケーションへのデータの送信を指令する第3のデータフロー制御指令を送信することを特徴とする請求項1に記載のデータフロー制御装置である。
【0017】
請求項2に係る発明によれば、実デバイスの場合には、第3のデータフロー制御指令が実デバイスまたは実デバイスを管理する装置に送信され、この第3のデータフロー制御指令に基づいて実デバイスからアプリケーションへのデータの送信が実行される。このように、マッチングにより抽出されたデバイスが実デバイスか仮想デバイスかによって、データフロー制御指令の内容および送信先を適宜変更することにより、実デバイスと仮想デバイスの両方のデータフローを簡単に実現できる。
【0018】
請求項3に係る発明は、前記データフロー制御指令は、送信するデータをセンシングもしくは生成すべき時刻、または、データを送信すべき時刻を指定する時間情報を含んでおり、前記データフロー指示部は、前記第1のデータフロー制御指令に基づくデータのセンシング、生成、もしくは送信が前記第2のデータフロー制御指令に基づく仮想データの生成もしくは送信よりも先に実行されるように、前記第1のデータフロー制御指令および前記第2のデータフロー制御指令それぞれの時間情報を設定することを特徴とする請求項1または2に記載のデータフロー制御装置である。
【0019】
請求項3に係る発明によれば、第1のデータフロー制御指令にしたがって元デバイスまたは元デバイスを管理する装置が動作し、第2のデータフロー制御指令にしたがって仮想デバイスまたは仮想デバイスを管理する装置が動作することで、元デバイスによるセンシング、データ生成、もしくはデータ送信が仮想デバイスによる仮想データの生成もしくは送信よりも先に実行されることが保証される。すなわち、仮想データの生成に必要な元データが、元デバイスにおいて適時にセンシングもしくは生成され、仮想データの生成ない
し送信に間に合うように仮想デバイスに送られてくる。よって、仮想データの効率的なデータフローを実現することができる。
【0020】
請求項5に係る発明は、コンピュータが、複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す情報を少なくとも含むデバイス側メタデータを記憶するデバイス側メタデータ記憶部から、デバイス側メタデータを取得するステップと、コンピュータが、データを利用してサービスを提供するアプリケーションについて、アプリケーションが要求するデータの仕様を示す情報を少なくとも含むアプリ側メタデータを記憶するアプリ側メタデータ記憶部から、アプリ側メタデータを取得するステップと、コンピュータが、前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記複数のデバイスのなかから前記アプリケーションが要求する仕様を満たすデータを提供可能なデバイスを抽出するステップと、コンピュータが、前記マッチングの結果に基づき、データの送信を指令するデータフロー制御指令を生成し送信するステップと、を有し、前記抽出されたデバイスが、1以上の元デバイスから得られるデータをもとに新たなデータを生成し仮想データとして出力する仮想デバイスである場合、前記データフロー制御指令を送信するステップでは、前記元デバイスまたは前記元デバイスを管理する装置に対して、前記元デバイスから前記仮想デバイスへのデータの送信を指令する第1のデータフロー制御指令が送信されるとともに、前記仮想デバイスまたは前記仮想デバイスを管理する装置に対して、前記仮想デバイスから前記アプリケーションへの仮想データの送信を指令する第2のデータフロー制御指令が送信されることを特徴とするデータフロー制御方法である。
【0021】
請求項5に係る発明によれば、仮想デバイスの場合に、第1のデータフロー制御指令と第2のデータフロー制御指令の2つが生成され、第1のデータフロー制御指令が元デバイス(仮想データの生成に必要な元データの提供元のデバイス)または元デバイスを管理する装置に対し送信され、第2のデータフロー制御指令が仮想デバイスまたは仮想デバイスを管理する装置に対し送信される。そして、第1のデータフロー制御指令に基づいて元デバイスから仮想デバイスへの元データの送信が実行され、第2のデータフロー制御指令に基づいて仮想デバイスからアプリケーションへの仮想データの送信が実行されることで、「元デバイス」と「仮想デバイス」と「アプリケーション」の三者間のデータ交換が行われる。この仕組みによれば、仮想データの生成に必要な元データが自動的に仮想デバイスへと送られるため、仮想デバイスが自ら(能動的に)必要な元データを収集したり蓄積したりする必要がなく、データ収集・管理のための余計な負荷も発生しない。よって、仮想データの効率的なデータフローを実現することができる。
【0022】
請求項6に係る発明は、請求項5に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラムである。
【0023】
請求項6に係る発明によれば、仮想デバイスの場合に、第1のデータフロー制御指令と第2のデータフロー制御指令の2つが生成され、第1のデータフロー制御指令が元デバイス(仮想データの生成に必要な元データの提供元のデバイス)または元デバイスを管理する装置に対し送信され、第2のデータフロー制御指令が仮想デバイスまたは仮想デバイスを管理する装置に対し送信される。そして、第1のデータフロー制御指令に基づいて元デバイスから仮想デバイスへの元データの送信が実行され、第2のデータフロー制御指令に基づいて仮想デバイスからアプリケーションへの仮想データの送信が実行されることで、「元デバイス」と「仮想デバイス」と「アプリケーション」の三者間のデータ交換が行われる。この仕組みによれば、仮想データの生成に必要な元データが自動的に仮想デバイスへと送られるため、仮想デバイスが自ら(能動的に)必要な元データを収集したり蓄積したりする必要がなく、データ収集・管理のための余計な負荷も発生しない。よって、仮想データの効率的なデータフローを実現することができる。
【0024】
本発明における「デバイス」は、何らかのデータを出力(提供)するあらゆる装置を意味し、センサ、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ATMなどが例示できる。中でも本発明は、センサから出力されるセンシングデータの流通を行うセンサネットワークに好適である。
【0025】
なお、本発明は、上記構成ないし機能の少なくとも一部を有するデータフロー制御装置として捉えることができる。また、本発明は、データフロー制御装置を有するデバイスネットワークシステムとして捉えることもできる。また、本発明は、上記処理の少なくとも一部を含むデータフロー制御方法、又は、かかる方法をコンピュータに実行させるためのプログラム、又は、そのようなプログラムを非一時的に記録したコンピュータ読取可能な記録媒体として捉えることもできる。また、本発明は、上記データフローを制御するための制御指令データストリームとして捉えることもできる。上記構成及び処理の各々は技術的な矛盾が生じない限り互いに組み合わせて本発明を構成することができる。
【発明の効果】
【0026】
本発明によれば、デバイスネットワークにおける仮想デバイスのデータの効率的なデータフローを実現することができる。
【発明を実施するための形態】
【0028】
以下に図面を参照しつつ、本発明の好適な実施の形態を説明する。ただし、以下に記載されている各構成の説明は、発明が適用されるシステムの構成や各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。
【0029】
以下に述べる実施形態では、本発明をM2Mクラウドを用いたセンサネットワークシステムに適用した例について説明する。かかる仕組みが実現すれば、センサネットワーク上に存在する多数のセンサ(実センサ、仮想センサの両方が混在し得る)から得られる多種多様な情報のなかから、所望の情報を誰もがどこからでも容易に取得することができるようになり、センサ(リソース)の有効利用、並びに、データ提供者からデータ利用者へのセンシングデータの流通が促進されると期待される。このシステムは、例えば、交通状況のセンシングデータに基づく交通制御システム、環境のセンシングデータに基づく気象予測システム、ビッグデータを利用した各種分析システムなど、様々な用途への応用展開が可能である。
【0030】
<システムの全体構成>
図1を参照して、本発明の実施形態に係るセンサネットワークシステムの全体的な構成を説明する。このセンサネットワークシステムは、データ提供者からデータ利用者へのセンシングデータの流通を制御するためのシステムであり、概略、複数の実センサ10と、実センサ10を管理する装置であるセンサネットワークアダプタ11と、センシングデー
タを利用してサービスを提供するアプリケーションを有する複数のアプリケーションサーバ12と、仮想センサを管理する装置である仮想センササーバ13と、センシングデータの提供者と利用者の仲介を担うデータフロー制御装置としてのセンサネットワークサーバ14とを有している。
【0031】
各装置のあいだはインターネット等の広域ネットワーク又はLANにより通信可能に接続されている。なお、ネットワークは単一のネットワークとは限らず、様々な通信方式やトポロジーをもつ複数のネットワークを相互に接続した概念的なものと考えてもよい。要するに、センシングデータの送受信や、センシングデータの流通に関わるメタデータ及びデータフロー制御指令等のデータの送受信が実現できれば、どのような形態のネットワークを利用してもよい。
【0032】
(実センサ)
実センサ10は、センシング対象の物理量やその変化を検出し、センシングデータとして出力するデバイスである。本明細書では、仮想センサとの区別のため、物理的な実体をもつセンサを「実センサ」と呼ぶ(仮想センサと実センサを区別する必要がないときは単に「センサ」と記す場合もある)。実センサ10には、例えば、画像センサ(監視カメラなど)、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、RFIDセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射能センサ、ガスセンサ、加速度センサ、ジャイロスコープ、GPSセンサなどが該当する。また、携帯電話、スマートフォン、タブレット端末、モバイルPC、ドローンなどの機器は様々な種類のセンサを搭載しているため、これらの機器を実センサとして取り扱うこともできる。本実施形態のセンサネットワークシステムには、ここで例示したセンサをはじめとして、いかなる種類のセンサを接続することができる。また、工場のFAや生産管理、都市交通制御、気象等の環境計測、ヘルスケア、防犯など、世の中のあらゆる場所に様々な用途・目的で多数のセンサが既に設置されているが、これらのセンサを本システムに接続することも可能である。なお、センサネットワークシステムは、一種類のセンサのみで構成してもよいし、複数の種類のセンサを混在させてもよい。
【0033】
(センサネットワークアダプタ)
センサネットワークアダプタ11は、1つ又は複数の実センサ10と有線又は無線により通信可能に接続され、実センサ10の管理、実センサ10からのセンシングデータの取得、センサネットワークシステムやアプリケーションへのセンシングデータの送信などを行う装置である。センサネットワークアダプタ11は、センシングデータに所定の処理(例えばノイズ除去などの信号処理、平均処理などの演算、サンプリング、データ圧縮、タイムスタンプなど)を施す機能を有していてもよい。センサネットワークアダプタ11は、外部装置との通信機能を有しており、仮想センササーバ13、アプリケーションサーバ12、センサネットワークサーバ14等とネットワークを介して通信が可能である。
【0034】
スマートフォン、タブレット端末、モバイルPC、ドローン、ウェアラブル端末などの機器は、画像センサ、GPSセンサ、加速度センサ、マイクなどのセンサを内蔵し、各センサで得られたデータを加工し出力する機能やネットワーク通信機能を有している。したがって、これらの機器は、実センサ10とセンサネットワークアダプタ11とが物理的に一体となったデバイスの例である。なお、
図1では、実センサ10がセンサネットワークアダプタ11を介してセンサネットワークシステムに接続されている構成のみ示されているが、通信機能を内蔵する実センサ10の場合には単体で(つまりセンサネットワークアダプタ11を介さずに)センサネットワークシステムに接続可能である。
【0035】
(仮想センササーバ)
仮想センササーバ13は、実行中の仮想センサの管理を行う装置であり、M2Mクラウ
ドサーバにより構成される。仮想センササーバ13は、ハードウエア的には、CPU(プロセッサ)、メモリ、補助記憶装置(HDD等)、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。仮想センササーバ13は、主な機能として、データ入出力部130、仮想センサDB131、仮想センシングデータ生成部132などを有する。これらの機能は、CPUが必要なプログラムを実行することにより実現されるものである。
【0036】
データ入出力部130は、外部装置との間でデータの送受信を行う機能である。データ入出力部130により、例えば、インターネットを通じて、実センサ10またはセンサネットワークアダプタ11からのセンシングデータの受信、後述するセンサネットワークサーバ14からのデータフロー制御指令の受信、仮想センシングデータのアプリケーションへの送信などが可能である。仮想センサDB131は、実行中の仮想センサの情報が登録されているデータベースである。仮想センシングデータ生成部132は、実センサ10から得た入力センシングデータをもとに新たなデータ(仮想センシングデータと呼ぶ)を生成する機能である。
【0037】
(仮想センサ)
仮想センサは、1以上の元センサから得られる入力センシングデータを加工、分析等して新たなデータを生成し仮想センシングデータとして出力する機能モジュールである。概念的には、仮想センサは、1以上のセンサ(入力センシングデータの取得先のセンサ)と、入力センシングデータを加工、分析等するプログラムである仮想センサ関数との組み合わせで構成され、物理的なデバイスではない点で実センサ10とは区別される。本実施形態のセンサネットワークシステムは、実センサ10だけでなく、仮想センサの利用や仮想センサにより生成・出力されるセンシングデータの流通を可能としたところに特徴を有している。
【0038】
例えば、あるアプリケーションサーバ12が必要としている情報が「道路ABを通過する車両の速度」であったとする。センサネットワークに接続された実センサ10のなかに道路ABに設置された速度センサが存在していれば、この速度センサで得られたセンシングデータをアプリケーションサーバ12に提供すればよい。しかし、アプリケーションサーバ12の要求に完全に合致する実センサが存在しない場合もあり得る。そのような場合に、もし道路ABの入口側の交差点Aと出口側の交差点Bにそれぞれカメラが設置されていたならば、入口側カメラと出口側カメラのそれぞれから得られた画像データと時刻情報、および各カメラの位置情報をもとに、車が交差点Aから交差点Bまで移動するのに要した時間と交差点AとBの間の距離を計算し、その結果から車の速度を推定することができる。すなわち、交差点A、Bそれぞれに設置されたカメラと仮想センサ関数により、車速センサと同等の機能を実現する仮想センサを作り出すことができるのである。なお、ここで例示したもの以外にも様々な種類の仮想センサを作ることが可能である。すなわち、1つ又は複数の入力センシングデータから、元の入力センシングデータとは異なる価値(新たな価値)をもつデータを生成し出力する機能を提供するモジュールであれば仮想センサと呼ぶことができ、アイデア次第で様々な仮想センサを創出できる。
【0039】
上記例より分かるように、本システムにおいて仮想センサの利用を可能にすることで、センサネットワークのリソース(実センサ)の利用率の向上や、新たな価値をもつセンシングデータの提供など、様々な効果が期待できる。
【0040】
(アプリケーションサーバ)
アプリケーションサーバ12は、センシングデータを利用してサービスを提供する各種アプリケーションプログラムがインストールされたサーバ装置である。アプリケーションサーバ12も、CPU(プロセッサ)、メモリ、補助記憶装置(HDD等)、通信装置、
入力装置、表示装置などを備える汎用のコンピュータにより構成できる。アプリケーションサーバ12は、センシングデータの利用者が設置するものであり、その用途・目的に応じて様々なアプリケーションが想定される。
【0041】
アプリケーションの例としては、例えば、道路に設置されたセンサや、道路上を走行する車両に搭載された車載端末又は運転者のスマートフォンなどから、各地点の交通状況を収集して渋滞マップを生成し、渋滞情報を利用する事業者等に提供するアプリケーションが考えられる。他にも、スマートフォンや車載カメラなどで走行中に撮影された画像データを収集し、各地点の状況を知りたい利用者に提供する映像配信アプリケーション、渋滞情報等を元に車両の走行ルートを検索する経路探索アプリケーション、特定の場所に設置されたカメラの映像から通行者の属性(性別、年齢層など)の統計データを推定し、各種調査用のデータとして提供するアプリケーションなど、様々なものが考えられる。
【0042】
(センサネットワークサーバ)
センサネットワークサーバ14は、センシングデータの提供者と利用者のあいだのマッチング、提供者から利用者へのセンシングデータのデータフロー制御などを担うサーバ装置であり、本発明に係るデータフロー制御装置の一具体例である。センサネットワークサーバ14も、CPU(プロセッサ)、メモリ、補助記憶装置(HDD等)、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。後述するセンサネットワークサーバ14の各種機能は、CPUが必要なプログラムを実行することにより実現される。
【0043】
センサネットワークシステムは、多数の(又は多種多様な)センサをネットワーク化し、センシングデータの収集や利用を可能とするものであるが、本実施形態では、データ提供者(実センサ、仮想センサ)がデータ利用者(アプリケーションサーバ)に対してセンシングデータを提供して対価を得る仕組みを想定している。これにより、データ提供者にとっては収益の機会、利用者にとっては安価なデータ取得というメリットが得られる。センサネットワークサーバ14は、このようなセンシングデータの取引の仲介を行うサーバ装置であり、データ提供者とデータ利用者のあいだのマッチングを行い、センシングデータの適切な流通を実現する。
【0044】
ところで、データ提供者とデータ利用者のあいだのマッチングを行う際に、データ利用者の希望条件に合致するデータを膨大なセンシングデータのなかから抽出するのは現実的ではない。そこで本システムでは、センサネットワークに登録されているすべてのセンサ(実センサ、仮想センサ含む)について、センシングデータの仕様や提供条件などを記述したセンサ側メタデータを準備するとともに、データ利用者であるアプリケーションについても、センシングデータの要求仕様や利用条件などを記述したアプリ側メタデータを用いる。そして、メタデータ同士の比較により、データ提供者(センサ)と利用者(アプリケーション)の適切なマッチングを行う。
【0045】
図1のシステム構成例では、センサネットワークサーバ14は、アプリ側メタデータDB140、センサ側メタデータDB141、マッチング142、データフロー指示部143を有する。アプリ側メタデータDB140は、各アプリケーションサーバ12から受信したアプリ側メタデータを記憶する記憶部である。センサ側メタデータDB141は、センサネットワークに登録されているすべてのセンサについてのセンサ側メタデータを記憶する記憶部である。マッチング部142は、アプリ側メタデータとセンサ側メタデータのマッチングを行い、アプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出する機能である。データフロー指示部143は、マッチング部142のマッチング結果に基づき、センシングデータの送信を指令するデータフロー制御指令を生成し送信する機能である。これらの機能の詳細は後述する。
【0046】
(センサ側メタデータ)
センサ側メタデータは、センサの属性情報、センサが提供可能なセンシングデータの仕様を示す情報、センシングデータの提供条件を示す情報などを記述したメタデータである。センサの属性情報は、例えば、センサを特定するID、実センサか仮想センサかを示す情報(センサクラスと呼ぶ)、センサの種別、センサのネットワークアドレス、センサの動作履歴などを含むとよい。ネットワークアドレスには、例えばIPアドレス、MACアドレス、URI(Uniform Resource Identifier)などを利用できる。センサがセンサネ
ットワークアダプタ11を介してネットワークに接続している場合は、センサネットワークアダプタ11のネットワークアドレスを設定すればよく、仮想センサの場合は、仮想センササーバ13のネットワークアドレスを設定すればよい。センシングデータの仕様を示す情報は、例えば、センシング対象(つまり何をセンシングするか)、センシングする領域(例:位置、範囲など)、センシング時間(センシングデータを取得可能な時刻や時間帯)、センシングデータのデータ種別(例:画像、動画、温度など)、データフォーマット(例:JPEG、テキストなど)、センシング条件(例:シャッタスピード、解像度、サンプリング周期など)、データ信頼度などを含むとよい。センシングデータの提供条件を示す情報は、データ提供者が希望する取引条件を示す情報であり、例えば、データ提供者を特定するID、対価(データの提供価格)、利用範囲・利用目的(例:商用利用不可、二次利用可など)などを含むとよい。
【0047】
図2Aに、センサ側メタデータDB141に格納されているセンサ側メタデータ管理テーブルの一例を示す。
図2Aの例では、実センサR001〜R007と仮想センサV001〜V002のセンサ側メタデータが示されている。
【0048】
(アプリ側メタデータ)
アプリ側メタデータは、アプリケーションの属性情報、アプリケーションが要求するセンシングデータの仕様(要求仕様)を示す情報、センシングデータの利用条件を示す情報などを記述したメタデータである。アプリケーションの属性情報は、例えば、アプリケーションを特定するID、アプリケーションの種別、アプリケーションのネットワークアドレスなどを含むとよい。ネットワークアドレスには、例えばIPアドレス、ポート番号などを利用できる。センシングデータの要求仕様を示す情報は、例えば、センシング対象、センシングする領域、センシング時間、センシングデータのデータ種別、データフォーマット、センシング条件、データ信頼度などを含むとよい。利用条件を示す情報は、データ利用者が希望する取引条件を示す情報であり、例えば、データ利用者を特定するID、対価(データの利用価格の上限)、利用範囲・利用目的などを含むとよい。なお、特に条件の指定が無い項目については空欄(指定しない)にすればよい。
【0049】
図2Bに、アプリ側メタデータDB140に格納されているアプリ側メタデータ管理テーブル(キューテーブルとも呼ぶ)の一例を示す。
図2Bの例では、2つのアプリケーションA001、A002からそれぞれ受信したアプリ側メタデータが示されている。
【0050】
(仮想センサの例)
図3Aは、仮想センサクラスの定義が登録される仮想センサクラス管理テーブルの一例を示す。仮想センサクラスは、仮想センサのテンプレート(ひな形)であり、入力センシングデータを取得する実センサが特定されていない抽象化された仮想センサを表す。仮想センサクラスは、例えば、仮想センサクラス番号、仮想センサの種別、入力センシングデータの個数、入力センシングデータの取得先の各センサの種別、各センサの寄与率、仮想センサクラスの定義者を特定する情報、仮想センサ関数などを含むとよい。仮想センサ関数は、入力センシングデータから仮想センシングデータを求める手順の定義であり、関数、演算式、ルックアップテーブル、プログラムモジュールなどどのような形式で与えても
よい。
【0051】
図3Aに示す仮想センサクラスVC001は、2つの位置センサと2つの画像センサから得られる4つの入力センシングデータに基づき、下記式により車両の速度を求める速度センサを定義するテンプレートである。
【0052】
速度v=(p2−p1)/(t2−t1)
ただし、p1、p2はそれぞれ位置センサのセンシングデータに基づき求められる各画像センサのセンシング領域の位置座標であり、t1、t2はそれぞれ各画像センサにおいて同一の車両が検知された時刻である。
【0053】
また、
図3Aに示す仮想センサクラスVC002は、3つの温度センサから得られる3つの入力センシングデータに基づき、下記式により平均気温を求める平均気温センサを定義するテンプレートである。
【0054】
平均気温ta=(t1+t2+t3)/3
ただし、t1〜t3はそれぞれ3つの温度センサでセンシングされた温度である。
【0055】
図3Bは、仮想センサクラスから生成された仮想センサ(インスタンス)が登録される仮想センサインスタンス管理テーブルの一例を示す。
図3Bに示す仮想センサV001は、仮想センサクラスVC001を基に生成された仮想センサであり、4つの実センサR001、R002、R003、R004から得られる入力センシングデータに基づき、交差点A、B間の道路の車両の速度を計算し仮想センシングデータとして出力する、仮想的な速度センサの例である。また、
図3Bに示す仮想センサV002は、仮想センサクラスVC002を基に生成された仮想センサであり、3つの実センサR005、R006、R007から得られる入力センシングデータに基づき、京都駅周辺の平均気温を計算し仮想センシングデータとして出力する、仮想的な平均気温センサの例である。
【0056】
図3Aと
図3Bに示したテーブルは、センサネットワークサーバ14のセンサ側メタデータDB141に格納され、データフロー指示部143がデータフロー制御指令を生成するときに参照される。また、これらのテーブルは、仮想センササーバ13の仮想センサDB131にも格納され、仮想センシングデータ生成部132が入力センシングデータから仮想センシングデータを生成するときに参照される。
【0057】
(マッチングおよびデータフロー制御)
次に、
図1と
図4を用いて、マッチングおよびデータフロー制御の処理について説明する。ここでは、アプリケーションサーバ12から送信されたアプリ側メタデータをセンサネットワークサーバ14が受信したことをトリガとして、センサネットワークサーバ14がアプリ側メタデータとセンサ側メタデータのマッチングを行い、適切なセンサからアプリへのセンシングデータのデータフロー制御指令を発行する処理例について説明する。
【0058】
アプリケーションサーバ12が、センサネットワークサーバ14の所定のAPI(Application Programming Interface)を利用して、アプリ側メタデータと共にセンシングデ
ータ要求を送信する。センサネットワークサーバ14は、センシングデータ要求を受信すると、その要求に含まれているアプリ側メタデータをアプリ側メタデータDB140のアプリ側メタデータ管理テーブル(
図2B参照)に記録する。そして、マッチング部142がアプリ側メタデータ管理テーブルから処理待ちのアプリ側メタデータを一つずつ取得する(ステップS40)。
【0059】
マッチング部142は、取得したアプリ側メタデータと、センサ側メタデータDB14
1内のセンサ側メタデータ管理テーブル(
図2A参照)に登録されている各センサのセンサ側メタデータとを比較し、センサ側メタデータで規定されたセンシングデータの仕様および提供条件がアプリ側メタデータで規定されたセンシングデータの要求仕様および利用条件を満足するか否かを判定する(ステップS41)。要求仕様および利用条件を満足するセンシングデータを提供するセンサが抽出できたら、マッチング部142は、当該センサの情報をデータフロー指示部143へ通知する。なお、要求仕様および利用条件を満足するセンシングデータを提供するセンサが見つからなかった場合には、処理を終了をしてもよいし、要求仕様や利用条件に最も近いセンシングデータをデータ利用者にレコメンドしてもよい。
【0060】
データフロー指示部143は、ステップS41で抽出されたセンサが仮想センサであるか実センサであるかを判断する(ステップS42)。この判断は、例えば、センサ側メタデータのセンサクラスを確認すればよい(
図2A参照)。
【0061】
(1)抽出されたセンサが実センサである場合
データフロー指示部143は、当該実センサからアプリケーションへのセンシングデータの送信を指令するデータフロー制御指令3を生成し、このデータフロー制御指令3を当該実センサ10または当該実センサ10を管理するセンサネットワークアダプタ11に対し送信する(ステップS43)。すると、
図1において一点鎖線矢印で示すように、データフロー制御指令3に基づき、センサネットワークアダプタ11が実センサ10から必要なセンシングデータを取得し、そのセンシングデータをアプリケーションサーバ12へと送信する。
【0062】
図5Cに、この場合のデータフロー制御指令の一例を示す。データフロー制御指令は、データフロー制御指令ID、実センサを特定する情報(センサID、実センサのネットワークアドレス)、アプリを特定する情報(アプリID、アプリのネットワークアドレス)、時間情報などを含むとよい。例えば、アプリA001よりアプリ側メタデータ(
図2B参照)を受信した場合、マッチングにより、実センサR002(
図2A参照)が抽出される。したがって、
図5Cに示すように、実センサを特定する情報として、センサID(R002)とそのネットワークアドレスが、アプリを特定する情報として、アプリID(A001)とそのネットワークアドレスが、時間情報として、アプリから要求されたセンシング時間が、それぞれ設定される。この例では、9:00、12:00、15:00、18:00の4回、センサR002からアプリA001へと、東京のA交差点の画像データが送信されることとなる。
【0063】
(2)抽出されたセンサが仮想センサである場合
仮想センサの場合、元センサから仮想センサへのセンシングデータの送信と、仮想センサからアプリへの仮想センシングデータの送信の2つのデータフローが必要となる。そこで、本実施形態では、データフロー指示部143が2つのデータフロー制御指令を生成し、それぞれ必要な装置へデータフロー制御指令を送信する。
【0064】
具体的には、データフロー指示部143は、センサ側メタデータ管理テーブル(
図2A)、アプリ側メタデータ管理テーブル(
図2B)、および仮想センサインスタンス管理テーブル(
図3B)を参照し、元センサから仮想センサへのセンシングデータの送信を指令するデータフロー制御指令1を生成し、このデータフロー制御指令を元センサまたは当該元センサを管理するセンサネットワークアダプタ11に対し送信する(ステップS44)。さらに、データフロー指示部143は、仮想センサからアプリへの仮想センシングデータの送信を指令するデータフロー制御指令2を生成し、このデータフロー制御指令を仮想センササーバ13に対し送信する(ステップS45)。
【0065】
すると、
図1において破線矢印で示すように、データフロー制御指令1に基づき、センサネットワークアダプタ11が実センサ10から必要なセンシングデータを取得し、そのセンシングデータを仮想センササーバ13へと送信する。仮想センササーバ13では、データ入出力部130がセンシングデータを受信し、仮想センシングデータ生成部132が、受信したセンシングデータと、仮想センサDB131から取得した仮想センサ関数とを用いて、仮想センシングデータを生成する。そして、データ入出力部130が、データフロー制御指令2に基づき、仮想センシングデータをアプリケーションサーバ12へと送信する。これにより、仮想センシングデータが提供される。
【0066】
図5Aと
図5Bに、元センサから仮想センサへのデータフロー制御指令1と、仮想センサからアプリへのデータフロー制御指令2の一例を示す。例えば、アプリA002よりアプリ側メタデータ(
図2B参照)を受信した場合、マッチングにより、仮想センサV002(
図2A参照)が抽出される。したがって、データフロー制御指令1には、
図5Aに示すように、元センサを特定する情報として、センサID(R005、R006、R007)とそのネットワークアドレスが、仮想センサを特定する情報として、仮想センサID(V002)とそのネットワークアドレスが、時間情報として、アプリから要求されたセンシング時間に基づく時間情報が、それぞれ設定される。また、データフロー制御指令2には、
図5Bに示すように、仮想センサを特定する情報として、仮想センサID(V002)と仮想センササーバ13のネットワークアドレスが、アプリを特定する情報として、アプリID(A002)とアプリケーションサーバ12のネットワークアドレスが、時間情報として、アプリから要求されたセンシング時間が、それぞれ設定される。
【0067】
ここで、データフロー指示部143は、データフロー制御指令1に基づくセンシングデータのセンシングもしくは送信がデータフロー制御指令2に基づく仮想センシングデータの生成もしくは送信よりも先に実行されるように、データフロー制御指令1およびデータフロー制御指令2それぞれの時間情報を設定するとよい。例えば、データフロー指示部143は、元センサから仮想センサへのデータ送信の遅延と、仮想センササーバ13における仮想センシングデータの生成に要する時間とに基づきマージンを計算し、データフロー制御指令1の時間情報を、データフロー制御指令2の時間情報に比べ、少なくともマージン分以上早い時刻に設定する。これにより、元センサによるセンシングもしくはデータ送信が仮想センサによる仮想センシングデータの生成もしくは送信よりも先に実行されることが保証される。すなわち、仮想センシングデータの生成に必要なセンシングデータ(元データ)が、元センサにおいて適時にセンシングされ、仮想センシングデータの生成ないし送信に間に合うように仮想センサに送られてくる。
【0068】
以上述べた本実施形態の構成によれば、データフロー制御指令1に基づいて元センサから仮想センサへのセンシングデータ(元データ)の送信が実行され、データフロー制御指令2に基づいて仮想センサからアプリケーションへの仮想センシングデータの送信が実行されることで、元センサと仮想センサとアプリケーションの三者間のデータ交換が行われる。この仕組みによれば、仮想センシングデータの生成に必要な元データが自動的に仮想センサへと送られるため、仮想センサが自ら(能動的に)必要な元データを収集したり蓄積したりする必要がなく、データ収集・管理のための余計な負荷も発生しない。よって、仮想センシングデータの効率的なデータフローを実現することができる。
【0069】
一方、実センサの場合には、データフロー制御指令3に基づいて実センサからアプリケーションへのセンシングデータの送信が実行される。このように、マッチングにより抽出されたセンサが実センサか仮想センサかによって、データフロー制御指令の内容および送信先を適宜変更することにより、実センサと仮想センサの両方のデータフローを簡単に実現できる。
【0070】
なお、上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。例えば上記実施形態で示したデータ構造やテーブル構造は一例であり、項目を適宜追加したり入れ替えたりしてもよい。また、上記実施形態では、センサネットワークにおけるセンシングデータの流通を例示したが、本発明は、センサ以外のデバイスを含むデバイスネットワークにおけるデータの流通にも適用可能である。その場合も、システムの基本的な構成は上記実施形態のものと同様であり、上記実施形態における「センサ」を「デバイス」と読み替え、「センシングデータ」を「データ」と読み替えればよい。