特開2015-226102(P2015-226102A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ オムロン株式会社の特許一覧
<>
  • 特開2015226102-仮想センサのメタデータ構造 図000003
  • 特開2015226102-仮想センサのメタデータ構造 図000004
  • 特開2015226102-仮想センサのメタデータ構造 図000005
  • 特開2015226102-仮想センサのメタデータ構造 図000006
  • 特開2015226102-仮想センサのメタデータ構造 図000007
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2015-226102(P2015-226102A)
(43)【公開日】2015年12月14日
(54)【発明の名称】仮想センサのメタデータ構造
(51)【国際特許分類】
   H04Q 9/00 20060101AFI20151117BHJP
【FI】
   H04Q9/00 311J
【審査請求】未請求
【請求項の数】7
【出願形態】OL
【全頁数】18
(21)【出願番号】特願2014-108373(P2014-108373)
(22)【出願日】2014年5月26日
(71)【出願人】
【識別番号】000002945
【氏名又は名称】オムロン株式会社
(74)【代理人】
【識別番号】100085006
【弁理士】
【氏名又は名称】世良 和信
(74)【代理人】
【識別番号】100100549
【弁理士】
【氏名又は名称】川口 嘉之
(74)【代理人】
【識別番号】100096873
【弁理士】
【氏名又は名称】金井 廣泰
(74)【代理人】
【識別番号】100123319
【弁理士】
【氏名又は名称】関根 武彦
(74)【代理人】
【識別番号】100125357
【弁理士】
【氏名又は名称】中村 剛
(74)【代理人】
【識別番号】100123098
【弁理士】
【氏名又は名称】今堀 克彦
(74)【代理人】
【識別番号】100138357
【弁理士】
【氏名又は名称】矢澤 広伸
(72)【発明者】
【氏名】大和 哲二
(72)【発明者】
【氏名】久野 敦司
【テーマコード(参考)】
5K048
【Fターム(参考)】
5K048AA02
5K048BA34
5K048EB10
5K048FC01
5K048HA01
5K048HA02
(57)【要約】
【課題】センサネットワークにおける仮想センサの利用及び仮想センサのセンシングデータの流通を容易化するための技術を提供する。
【解決手段】他のセンサから得られる入力センシングデータをもとに新たなセンシングデータを生成し出力する仮想センサ、に関する情報を定義する仮想センサのメタデータのデータ構造であって、仮想センサがセンシングする位置又は領域を示す対象領域データと、仮想センサの種別又は仮想センサにより出力されるセンシングデータの種別を示す種別データと、入力センシングデータを得る1以上の他のセンサを特定するセンサ識別データと、を含む。
【選択図】図3
【特許請求の範囲】
【請求項1】
他のセンサから得られる入力センシングデータをもとに新たなセンシングデータを生成し出力する仮想センサ、に関する情報を定義する仮想センサのメタデータのデータ構造であって、
仮想センサがセンシングを行う位置又は領域を示す対象領域データと、
仮想センサのセンサ種別又は仮想センサにより出力されるセンシングデータのデータ種別を示す種別データと、
入力センシングデータを得る1以上の他のセンサを特定するセンサ識別データと、
を含むことを特徴とする仮想センサのメタデータのデータ構造。
【請求項2】
前記入力センシングデータから前記新たなセンシングデータを生成するための関数を特定する関数識別データをさらに含むことを特徴とする請求項1に記載の仮想センサのメタデータのデータ構造。
【請求項3】
実センサであるか仮想センサであるかを示すセンサクラスデータをさらに含むことを特徴とする請求項1又は2に記載の仮想センサのメタデータのデータ構造。
【請求項4】
仮想センサのネットワーク・アドレスを示すアドレスデータをさらに含むことを特徴とする請求項1〜3のうちいずれか1項に記載の仮想センサのメタデータのデータ構造。
【請求項5】
仮想センサのセンシング対象を示す対象データをさらに含むことを特徴とする請求項1〜4のうちいずれか1項に記載の仮想センサのメタデータのデータ構造。
【請求項6】
仮想センサがセンシングを行う時刻又は時間範囲を示す時間データをさらに含むことを特徴とする請求項1〜5のうちいずれか1項に記載の仮想センサのメタデータのデータ構造。
【請求項7】
センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得手段と、
前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
前記センサ側メタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出するマッチング手段と、
前記センサを管理するセンサ管理装置に対して、前記マッチング手段により抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を送信する指示手段と、を有し、
前記センサには、他のセンサから得られる入力センシングデータをもとに新たなセンシングデータを生成し出力する仮想センサが含まれており、
仮想センサのセンサ側メタデータが、請求項1〜6のうちいずれか1項に記載のデータ構造を有している
ことを特徴とするデータフロー制御指令発生装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、センシングデータを利用するセンサネットワークに関するものであり、特に、仮想センサのセンシングデータの利用に関わる技術に関する。
【背景技術】
【0002】
現在、M2Mクラウドと呼ばれるIT環境が注目を集めている。M2M(Machine to Machine)とは、様々な用途、大きさや性能を持つ機械同士がネットワーク上で情報をやり取りするシステムを指す。この情報を利用することで、それぞれの機械の適切な制御や、実社会の状況解析が可能になる。M2Mを支える無線通信技術の向上や機械の小型化、低廉化などにより、実用化への期待が高まっている。
【0003】
このようなM2Mの技術をクラウドコンピューティング環境上で実現したものはM2Mクラウドと呼ばれる。これは、M2Mに必要な基本機能、例えばデータの収集蓄積から加工、分析のようなサービスをクラウド上のアプリケーションとして提供し、どこからでも利用可能にしたものである。データの一括管理によって信頼性や網羅性を高めることができる。また利用者にとっては、収集されたデータやコンピュータ資源を必要な分だけ利用できるメリットがある。そのため、個別にシステムを構築することなくビッグデータを解析して付加価値を得ることが可能であり、幅広い分野での応用が期待されている。
【0004】
また、特許文献1に示すように、センサネットワークと呼ばれる技術が検討されている。これは、センシング機能と通信機能をもつセンサデバイス(以下、単に「センサ」とも呼ぶ)を様々な場所、移動体、産業設備などに設置し、それらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能とするものである。
【0005】
通常、センサは、その所有者自身が必要とするデータを収集するために設置される。そのため所有者がデータ収集を行うとき以外は利用されていない(センサ自体が稼働していない、またはセンサが稼働していてもセンシングデータが利用されない)ことが多い。そのためセンシングデータの流通性は低く、第三者にとっていかに有意義なデータであっても、センサの所有者自身による分析、利用に留まっていた。その結果、設備の重複投資や、各自が設置したセンサとの通信によるネットワークの輻湊を招いていた。
【0006】
また、IoT(Internet of Things)という技術が検討されている。これは、世界に存在する多くの物に関する情報をネット上で組み合わせることで新しい価値を生むもので、社会インフラを始めとする様々なサービスのシームレスな展開が期待されている。IoTから価値を生み出すためには、ネットに繋がる物の状態を知る必要があり、センシングと通信が重要な要素技術となる。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2007−300571号公報
【特許文献2】特開2013−145205号公報
【特許文献3】特開2013−36887号公報
【特許文献4】特許第5445722号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
出願人らは、センサネットワークの発展について鋭意検討している(例えば特許文献4
参照)。例えば、ビッグデータを処理可能なアプリケーションサーバ上でデータを加工して付加価値を生み出し、提供することや、センシングデータの取引を活発化させて経済効果をもたらすことである。例えばセンサの所有者は、データ利用者に対してセンサの一時利用を許可したりセンシングデータを提供したりすることで対価を得られる。また利用者にとっては、センサを設置する投資が不要なため安価に必要なデータを得ることができるメリットがある。
【0009】
上記のような、出願人らの検討に係るセンサネットワークは、さまざまな個所に設置された機械(に搭載されたセンサデバイス)が取得したデータを集中的に管理して利用可能とする点で、M2Mクラウドを具体的に実現する一形態とも言える。M2Mクラウドを基盤とするセンサネットワークが実現すれば、データ種別や取得位置、時間などが多様なデータを、何処からでも適切な形で把握し役立てることが可能となる。そのため、製造現場や物流などの産業分野から、セキュリティや医療、教育などの生活分野、そしてスマートグリッドや交通制御システムなどの社会インフラ分野まで、幅広い応用が期待される。
【0010】
また、IoTにおいては、時間、空間、人、物、情報、エネルギーなどの資源を様々な粒度で最適化するためのシステムを形成する。最適化するということは、資源を、必要性が低い部分から高い部分に移転したり、価値が高い形態で使用したりすることであり、資源の移転や使用権の設定、対価の支払いなどの取引が行われる。しかし従来、センシングデータなど流通させる仕組みは整備されていなかった。
【0011】
さらに出願人らは、センサネットワークを発展・拡大させる要素技術の一つとして「仮想センサ」と呼ばれる技術に注目している。例えば、他のセンサから得られるセンシングデータを加工して新たなデータとして出力するプログラムモジュールを仮想センサとして用意し、センサネットワークの利用者に提供すれば、利用者は実センサとの区別なく仮想センサを利用できる。このような仮想センサの導入により、リソース(実センサ)の利用率の向上、新たな付加価値をもつセンシングデータの提供など、様々な効果が期待できる。なお、仮想センサそのものの概念は既に知られているが(特許文献2、3、4参照)、センサネットワークのなかで仮想センサの他人による利用や仮想センサのセンシングデータの流通を実現するための仕組みは今まで考慮されていなかった。
【0012】
本発明は上記の課題に鑑みてなされたものであり、センサネットワークにおける仮想センサの利用及び仮想センサのセンシングデータの流通を容易化するための技術を提供することを目的とする。
【課題を解決するための手段】
【0013】
請求項1に係る仮想センサのメタデータのデータ構造は、他のセンサから得られる入力センシングデータをもとに新たなセンシングデータを生成し出力する仮想センサ、に関する情報を定義する仮想センサのメタデータのデータ構造であって、仮想センサがセンシングを行う位置又は領域を示す対象領域データと、仮想センサのセンサ種別又は仮想センサにより出力されるセンシングデータのデータ種別を示す種別データと、入力センシングデータを得る1以上の他のセンサを特定するセンサ識別データと、を含むことを特徴とする。
【0014】
「仮想センサ」とは、他のセンサから得られる入力センシングデータをもとに新たなセンシングデータを生成し出力する機能モジュールであり、物理的なデバイスではない点(実体を有しない点)で通常のセンサ(「実センサ」と称す)とは区別される。ここで「他のセンサ」は実センサでもよいし仮想センサでもよい。また「他のセンサ」の数(あるいは「入力センシングデータ」の数)は1つでもよいし複数でもよい。仮想センサにより生成される「新たなセンシングデータ」は、元の入力センシングデータに対し所定の関数に
よる演算を施すことで得られるデータであれば、どのようなデータでもよい。また「仮想センサのメタデータ」とは、仮想センサに関する情報(仮想センサの属性ともいう)を記述したデータであり、本発明では、センサネットワークにおいてセンサの検索やマッチング、又は、新たなセンシングデータの生成に利用される情報を記述したメタデータを想定している。
【0015】
請求項1に係るデータ構造をもつメタデータにより仮想センサの属性を記述することによって、センシング対象の位置・領域やセンサ種別・データ種別などの条件による仮想センサの検索やマッチングを、当該メタデータを利用して行うことができる。また、センシング対象の位置・領域やセンサ種別・データ種別といった条件であれば、仮想センサと実センサを区別なく(同じ検索条件を用いて)扱うことができる。これにより、センサの利用側(利用者又は利用アプリケーション)の利便性を向上することができる。一方、このメタデータを参照すれば仮想センサの動作に必要な他のセンサを特定することも可能であるため、仮想センサの管理側(管理システム)の処理(例えば、仮想センサの動作に必要なデータの取得及び新たなセンシングデータの生成など)の利便性も向上する。以上より、センサネットワークにおける仮想センサの利用及び仮想センサのセンシングデータの流通を容易化することが可能となる。
【0016】
請求項2に係る仮想センサのメタデータのデータ構造は、前記入力センシングデータから前記新たなセンシングデータを生成するための関数を特定する関数識別データをさらに含むことを特徴とする。この関数識別データを参照することにより、新たなセンシングデータを生成するために必要な関数(例えばプログラムモジュールとして提供される)を容易に特定できるため、仮想センサの管理や実装が容易に実現できる。
【0017】
請求項3に係る仮想センサのメタデータのデータ構造は、実センサであるか仮想センサであるかを示すセンサクラスデータをさらに含むことを特徴とする。これにより、メタデータ(のセンサクラスデータ)を参照するだけで実センサと仮想センサの区別ができるため、実センサと仮想センサのあいだで、センサもしくはセンシングデータの取り扱い又は処理を分けなければならないときに、容易に実装が可能となる。
【0018】
請求項4に係る仮想センサのメタデータのデータ構造は、仮想センサのネットワーク・アドレスを示すアドレスデータをさらに含むことを特徴とする。これにより、センサネットワーク上の仮想センサの論理的な場所を知ることができるため、仮想センサへのアクセスを容易に実現できる。
【0019】
請求項5に係る仮想センサのメタデータのデータ構造は、仮想センサのセンシング対象を示す対象データをさらに含むことを特徴とする。これにより、センシング対象そのものを条件として仮想センサの検索やマッチングを行うことができ、センサの利用側の利便性を向上することができる。
【0020】
請求項6に係る仮想センサのメタデータのデータ構造は、仮想センサがセンシングを行う時刻又は時間範囲を示す時間データをさらに含むことを特徴とする。これにより、仮想センサの稼働時間を条件として仮想センサの検索やマッチングを行うことができ、センサの利用側の利便性を向上することができる。
【0021】
請求項7に係るデータフロー制御指令発生装置は、センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得手段と、前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、前記センサ側メタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満
たすセンシングデータを提供可能なセンサを抽出するマッチング手段と、前記センサを管理するセンサ管理装置に対して、前記マッチング手段により抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を送信する指示手段と、を有し、前記センサには、他のセンサから得られる入力センシングデータをもとに新たなセンシングデータを生成し出力する仮想センサが含まれており、仮想センサのセンサ側メタデータが、請求項1〜6のうちいずれか1項に記載のデータ構造を有していることを特徴とする。
【0022】
請求項7に係るデータフロー制御指令発生装置によれば、アプリ側メタデータとセンサ側メタデータとのあいだでマッチングが行われ、センシングデータを必要とするアプリケーションと、そのデータを提供可能な仮想センサとが対応付けられる。そして、センサを管理する装置に対してデータフロー制御指令が送信される。これにより、種々の条件を加味した上でのセンシングデータの流通が促されサービスが向上するうえに、データの提供者と利用者双方にとって利益となる。センサ側メタデータは、センサおよび当該センサにより得られるセンシングデータの属性に関する情報を、アプリ側メタデータは、アプリケーション自身および当該アプリケーションが必要とするセンシングデータの属性に関する情報を指す。またデータフロー制御指令とは、データ提供元であるセンサと、データ利用先であるアプリケーションとを特定する情報を含み、データ提供元からデータ利用先にデータを流通させることを指令する指令情報である。データフロー制御指令によるセンサ管理装置への指示内容において、ある1つのセンサのセンシングデータを複数のアプリケーションに流通させるように指示することが可能である。また複数のセンサのそれぞれから、センシングデータを1つのアプリケーションへ流通するように指示することもできる。さらに、複数のセンサのそれぞれからのセンシングデータを、複数のアプリケーションに流通させるように指令することもできる。このような仕組みによれば、実センサと仮想センサの両方を同じ枠組みで(区別せずに)取り扱うことが可能となる。
【発明の効果】
【0023】
本発明によれば、センサネットワークにおける仮想センサの利用及び仮想センサのセンシングデータの流通を容易化することができる。
【図面の簡単な説明】
【0024】
図1】本発明の実施形態に係るセンサネットワークシステムの全体的な構成を示す図。
図2】実センサのメタデータのデータ構造と一例を示す図。
図3】仮想センサのメタデータのデータ構造と一例を示す図。
図4】センシングデータのメタデータのデータ構造と一例を示す図。
図5】アプリ側メタデータのデータ構造を示す図。
【発明を実施するための形態】
【0025】
以下に図面を参照しつつ、本発明の好適な実施の形態を説明する。ただし、以下に記載されている各構成の説明は、発明が適用されるシステムの構成や各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。
【0026】
以下に述べる実施形態では、本発明をM2Mクラウドを用いたセンサネットワークシステムに適用した例について説明する。かかる仕組みが実現すれば、センサネットワーク上に存在する多数のセンサ(実センサ、仮想センサの両方が混在し得る)から得られる多種多様な情報のなかから、所望の情報を誰もがどこからでも容易に取得することができるようになり、センサ(リソース)の有効利用、並びに、データ提供者からデータ利用者へのセンシングデータの流通が促進されると期待される。このシステムは、例えば、交通状況のセンシングデータに基づく交通制御システム、環境のセンシングデータに基づく気象予測システム、ビッグデータを利用した各種分析システムなど、様々な用途への応用展開が
可能である。
【0027】
<システムの全体構成>
図1を参照して、本発明の実施形態に係るセンサネットワークシステムの全体的な構成を説明する。このセンサネットワークシステムは、データの提供元からデータの利用先へのセンシングデータの流通を制御するためのシステムであり、概略、データの提供元としての複数の実センサ10と、センサネットワークアダプタ11と、データの利用先としての複数のアプリケーションサーバ12と、データの提供元からのセンシングデータの収集、蓄積、センシングデータの分析、センシングデータや分析結果の利用先への配信などを担当するM2Mクラウドサーバ13と、データの提供元と利用先のマッチングを担当するセンサネットワークサーバ14とを有している。
【0028】
各ブロックのあいだはインターネット等の広域ネットワーク又はLANにより通信可能に接続されている。なお、ネットワークは単一のネットワークとは限らず、様々な通信方式やトポロジーをもつ複数のネットワークを相互に接続した概念的なものと考えてもよい。要するに、センシングデータの送受信や、センシングデータの流通に関わるメタデータ及びデータフロー制御指令等のデータの送受信が実現できれば、どのような形態のネットワークを利用してもよい。
【0029】
以下、各ブロックの構成と機能について詳しく説明する。
【0030】
(実センサ)
実センサ10は、センシング対象の物理量やその変化を検出し、センシングデータとして記録または出力するデバイスである。本明細書では、仮想センサとの区別のため、物理的な実体をもつセンサを「実センサ」と呼ぶ(仮想センサと実センサを区別する必要がないときは単に「センサ」と記す場合もある)。実センサ10には、例えば、画像センサ(監視カメラなど)、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、RFIDセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射能センサ、ガスセンサ、加速度センサ、ジャイロスコープ、GPSセンサ、スマートフォンなどでテキスト入力をするためのデバイスおよびInput Method(一般的に、IMEと略記される)からなる入力システムなどが該当する。本実施形態のセンサネットワークシステムには、ここで例示したセンサをはじめとして、いかなる種類のセンサを利用することができる。また、工場のFAや生産管理、都市交通制御、気象等の環境計測、ヘルスケア、防犯など、世の中のあらゆる場所に様々な用途・目的で多数のセンサが既に設置されているが、これらのセンサを本システムに接続することも可能である。なお、センサネットワークシステムは、一種類のセンサのみで構成してもよいし、複数の種類のセンサを混在させてもよい。
【0031】
(センサネットワークアダプタ)
センサネットワークアダプタ11は、1つ又は複数の実センサ10と物理的又は電気的に接続され、実センサ10からセンシングデータを取得するデバイスである。またセンサネットワークアダプタ11は、CPU等の情報処理装置によりセンシングデータに所定の処理を施す機能を有する。またセンサネットワークアダプタ11は、外部との通信機能を有しており、M2Mクラウドサーバ13、アプリケーションサーバ12、センサネットワークサーバ14等とネットワークを介して通信が可能である。
【0032】
例えば、スマートフォン、タブレット端末、モバイルPCなどの携帯型端末は、画像センサ、GPSセンサ、加速度センサ、マイクなどのセンサを内蔵し、各センサで得られたデータを加工し出力する機能やネットワーク通信機能を有している。したがって、これらの携帯型端末は、実センサ10とセンサネットワークアダプタ11とが物理的に一体となったデバイスの例である。
【0033】
(M2Mクラウドサーバ)
M2Mクラウドサーバ13は、センシングデータの管理・分析・流通を担うサーバである。ハードウエア的には、情報処理装置(CPU)、メモリ、補助記憶装置(HDD等)、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。様々な場所に存在するセンサネットワークアダプタ11からネットワーク経由でアクセスを受け、大量のセンシングデータを受信してデータベースに蓄積し、データの利用先であるアプリケーションサーバ12に対して必要なデータを提供する、という大量のデータ処理を実行するのに必要な性能を有する。
【0034】
M2Mクラウドサーバ13は、センシングデータDB(データベース)130、仮想センサDB131などを有している。センシングデータDB130は、センサネットワークアダプタ11より収集したセンシングデータを蓄積し管理するデータベースである。また、仮想センサDB131は、複数の仮想センサが登録されているデータベースである。
【0035】
(仮想センサ)
仮想センサは、他のセンサから得られる入力センシングデータを加工、分析等して新たなセンシングデータを生成する機能モジュールである。概念的には、仮想センサは、1以上のセンサ(入力センシングデータの取得先のセンサ)と、入力センシングデータを加工、分析等するプログラムである仮想センサ関数との組み合わせで構成され、物理的なデバイスではない点で実センサ10とは区別される。本実施形態のセンサネットワークシステムは、実センサ10だけでなく、仮想センサの利用や仮想センサにより生成・出力されるセンシングデータの流通を可能としたところに特徴を有している。
【0036】
例えば、あるアプリケーションサーバ12が必要としている情報が「ある交差点Xを通過する車両の速度」であったとする。センサネットワークに接続された実センサ10のなかに交差点Xに設置された車速センサが存在していれば、この車速センサで得られたセンシングデータをアプリケーションサーバ12に提供すればよい。しかし、アプリケーションサーバ12の要求に完全に合致する実センサが存在しない場合もあり得る。そのような場合に、もし交差点Xの入口側と出口側にそれぞれカメラが設置されていたならば、入口側カメラと出口側カメラのそれぞれから得られた画像データと時刻情報とをもとに、車が交差点の入口から出口まで移動するのに要した時間を計算し、その結果から車の速度を推定することができる。すなわち、入口側カメラと出口側カメラで得られる2つの時系列画像データと、入口と出口の間の距離データとを用い、同一の車と画像認識された車についての入口と出口の通過時刻の差によって、前記距離を割り算することで通過車両の速度を計算する仮想センサ関数により、車速センサと同等の機能を実現する仮想センサを作り出すことができるのである。なお、ここで例示したもの以外にも様々な種類の仮想センサを作ることが可能である。すなわち、1つ又は複数の入力センシングデータから、元の入力センシングデータとは異なる価値(新たな価値)をもつデータを生成し出力する機能を提供するモジュールであれば仮想センサと呼ぶことができ、アイデア次第で様々な仮想センサを創出できる。
【0037】
上記例より分かるように、本システムにおいて仮想センサの利用を可能にすることで、センサネットワークのリソース(実センサ)の利用率の向上や、新たな価値をもつセンシングデータの提供など、様々な効果が期待できる。
【0038】
(アプリケーションサーバ)
アプリケーションサーバ12は、センシングデータを用いる各種アプリケーションプログラムがインストールされ、要求に応じた演算処理を行って結果を返却するサーバ装置である。アプリケーションサーバ12も、情報処理装置(CPU)、メモリ、補助記憶装置
(HDD等)、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。アプリケーションサーバ12は、センシングデータの利用者が設置するものであり、その用途・目的に応じて様々なアプリケーションが想定される。
【0039】
アプリケーションの例としては、例えば、道路に設置されたセンサや、道路上を走行する車両に搭載された車載端末又は運転者のスマートフォンなどから、各地点の交通状況を収集して渋滞マップを生成し、渋滞情報を利用する事業者等に提供するアプリケーションが考えられる。他にも、スマートフォンや車載カメラなどで走行中に撮影された画像データを収集し、各地点の状況を知りたい利用者に提供する映像配信アプリケーション、渋滞情報等を元に車両の走行ルートを検索する経路探索アプリケーション、特定の場所に設置されたカメラの映像から通行者の属性(性別、年齢層など)の統計データを推定し、各種調査用のデータとして提供するアプリケーションなど、様々なものが考えられる。
【0040】
このように、センサネットワークの利用者は、個々のセンサのセンシングデータを直接取得することもできるし、それだけでなく、アプリケーションを指定して処理を要求することで、個々のセンサを意識することなく所望の情報を得ることができる。
【0041】
(センサネットワークサーバ)
センサネットワークサーバ14は、センサネットワークに係るセンサの管理等を行うサーバ装置である。センサネットワークサーバ14も、情報処理装置(CPU)、メモリ、補助記憶装置(HDD等)、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。
【0042】
センサネットワークシステムは、多数の(又は多種多様な)センサをネットワーク化し、センシングデータの収集や利用を可能とするものであるが、本実施形態では、センサの所有者(データ提供元)が、企業等のデータ利用者(アプリケーションサーバ)に対してセンシングデータを提供して対価を得る仕組みを想定している。これにより、センサの所有者(データ提供元)にとっては収益の機会、利用者にとっては安価なデータ取得というメリットが得られる。センサネットワークサーバ14は、このようなセンシングデータの取引の仲介を行うサーバ装置であり、データ提供元とデータ利用者のあいだのマッチングを行い、センシングデータの適切な流通を実現する。
【0043】
ところで、データ提供元とデータ利用者のあいだのマッチングを行う際に、データ利用者の希望条件に合致するデータを膨大なセンシングデータのなかから抽出するのは現実的ではない。そこで本システムでは、センサネットワークに登録されているすべてのセンサ(実センサ、仮想センサ含む)について、センサに関する情報(属性)を記述したセンサ側メタデータを準備するとともに、データ利用者であるアプリケーションに関する情報(属性)を記述したアプリ側メタデータを用いる。そして、メタデータ同士の比較により、データ提供元(センサ)と利用先(アプリケーション)の適切なマッチングを行う。
【0044】
図1のシステム構成例では、センサネットワークサーバ14の中にセンサ側メタデータが登録されたセンサ側メタデータDB140を設置し、センサネットワークサーバ14が、アプリケーションサーバ12からアプリ側メタデータを受信したイベントをトリガとして、当該アプリ側メタデータとセンサ側メタデータDB140から読み込んだセンサ側メタデータのあいだのマッチングを行う。ただしこの構成は一例であり、センサ側メタデータDBをセンサネットワークサーバ14とは別に(例えばクラウド上に)設置してもよい。あるいは、アプリ側からのイベント(例えばアプリ側メタデータの受信)をトリガにするのではなく、センサ側からのイベント(例えばセンシングデータの更新通知)をトリガにしてアプリ側メタデータとセンサ側メタデータのマッチングを行う方法でもよい。その場合には、各アプリケーションサーバ12のアプリ側メタデータをあらかじめ登録したア
プリ側メタデータDBをセンサネットワークサーバ14に設けておくこともできる。
【0045】
(実センサのセンサ側メタデータ)
図2(a)に、実センサのメタデータのデータ構造の一例を示す。
【0046】
実センサのメタデータには、大項目として、「1.センサの属性情報」、「2.センシング対象の属性情報」、「3.センシング対象領域の属性情報」、「4.センシング動作の属性情報」が含まれる。
【0047】
「1.センサの属性情報」は、センサデバイス自体の属性を示すデータであり、「センサクラス」、「センサクラスNo.」、「センサ種別」、「センサの位置・姿勢」、「センサの所有者ID」、「センサのID、アドレス」、「センサの動作履歴情報」などのデータを含んでいる。「センサクラス」は、当該センサが実センサであるか仮想センサであるかを示す情報である。例えば、実センサの場合は「0」、仮想センサの場合は「1」のように、センサクラスを示すフラグが記述される。「センサクラスNo.」は、当該センサのセンサクラスNo.を示す情報である。センサクラスNo.とは、センサの種別を示す番号であり、本システムにおいて種別ごとに予め番号が割り当てられている。例えば、速度センサは「001」、加速度センサは「002」、加加速度センサは「003」、画像センサは「004」・・・のように割り当てられる。センサクラスNo.は、番号ではなく、符号で表記してもよい。また、センサの種別が同じ場合でも実センサと仮想センサの間でセンサクラスNo.を異ならせてもよい(例えば、実センサの速度センサは「RC001」、仮想センサの速度センサは「VC001」)。「センサ種別」もセンサの種別を示す情報であり、番号でなく、「速度センサ」、「加速度センサ」・・・などの文字列で記述される。「センサの位置・姿勢」は、当該センサの設置位置(例えば緯度・経度情報)とセンサの向き(例えば「北向き」など)を示す情報である。「センサの所有者ID」は、当該センサの所有者を特定するための情報である。センサ利用の対価の支払い先やセンサ故障時の連絡先などを取得する際に利用される。「センサのID、アドレス」は、センサネットワークの中から当該センサを特定するための情報(ID)と、当該センサにアクセスするためのネットワーク・アドレスを示す情報(アドレス)である。ネットワーク・アドレスとしては、例えばIPアドレス、MACアドレス、URI(Uniform Resource Identifier)などを利用できる。「センサの動作履歴情報」は、当該センサで発生し
たエラーのログを記録するための情報である。これは例えば、センサやセンシングデータの信頼性を評価する目的で利用される。
【0048】
「2.センシング対象の属性情報」は、センシング対象(つまり、何をセンシングするか)に関する属性を示すデータであり、「対象の種類」、「対象の物理属性」、「対象のID」などのデータを含んでいる。これらのデータはすべて記述する必要はない。例えば、一般物体である「自動車」がセンシング対象の場合には、「対象の種類」に「自動車」と記述し、他のデータは空欄とする。物理属性はセンシング対象の絞り込みに利用でき、例えば、「対象の物理属性」に「赤色」と記述した場合は、「赤色の自動車」がセンシング対象となる。なお、不特定の物体でなく特定物体がセンシング対象の場合には(例えば、車両ナンバーがxxxxの自動車など)、特定物体を識別するためのIDを「対象のID」に記述すればよい。
【0049】
「3.センシング対象領域の属性情報」は、当該センサがセンシングを行う空間と時間を示すデータであり、「位置範囲」と「時間範囲」のデータを含んでいる。「位置範囲」は、センシングを行う位置又は領域を示す対象領域データである。例えば、空間内の1点の位置座標を示すデータ(例えば緯度・経度情報)でもよいし、広がり(面積)をもつ領域を示すデータ(例えば、多角形領域の各頂点の位置座標、中心点の位置座標と半径の情報、地名など)でもよい。なお、「1.センサの属性情報」内の「センサの位置」と「位
置範囲」とは必ずしも一致しない。温度センサや降雨センサのようにセンサの設置位置の状態を検知するセンサの場合は、設置位置とセンシング対象の位置が一致するが、監視カメラのようなセンサでは、設置位置から離れた地点の映像を取得するものもあるからである。「時間範囲」は、当該センサがセンシングを行う時間を示す時間データである。例えば、「8:00、10:00、12:00」のようにセンシングを実施する時刻を記述してもよいし、「8:00〜15:00」のようにセンサが稼働している時間範囲を記述してもよい。
【0050】
「4.センシング動作の属性情報」は、当該センサの動作条件を示すデータであり、「センシング制御パラメータ」と「サンプリング仕様、量子化仕様」とを含んでいる。「センシング制御パラメータ」に記述される内容はセンサ種別ごとに様々である。例えば画像センサ(カメラ)の場合は、シャッタスピード、露出などの撮影条件を記述できるし、照明をあてて撮影を行うようなアクティブセンシングの場合には照明光の強さなどの条件を記述してもよい。「サンプリング仕様、量子化仕様」には、センシングデータの取得条件(例えば、サンプリング周期(データ取込周期)、解像度、分解能、データのビット数など)を記述できる。
【0051】
図2(b)は、ある実センサの情報を記述したメタデータの一例である。このメタデータを参照することで、この実センサが、東京都千代田区半蔵門交差点に設置され、9:00〜21:00に半蔵門交差点を通過する赤い自動車を検知可能な画像センサであることが分かる。また画像センサの所有者や、ネットワーク上のアクセス先なども特定することができる。
【0052】
(仮想センサのセンサ側メタデータ)
次に、図3(a)を用いて仮想センサのメタデータのデータ構造について説明する。本システムでは、実センサと仮想センサとを基本的に区別なく取り扱うことができるように、仮想センサのメタデータのデータ構造は実センサのメタデータを継承(包含)する構造となっている。以下、仮想センサのデータ構造について説明する。
【0053】
仮想センサのメタデータには、大項目として、「1.センサの属性情報」、「2.センシング対象の属性情報」、「3.センシング対象領域の属性情報」、「4.センシング動作の属性情報」、「5.実センサの属性情報」、「6.関数の属性情報」が含まれる。
【0054】
「1.センサの属性情報」、「2.センシング対象の属性情報」、「3.センシング対象領域の属性情報」、「4.センシング動作の属性情報」の4項目については、図2(a)に示した実センサのメタデータのデータ構造と同じものである。ただし、「1.センサの属性情報」における「センサの所有者ID」には、仮想センサを作成し登録した者(例えば、仮想センサ関数をプログラミングし、センシング動作の属性情報を設定し、仮想センサのその他のメタデータを設定登録した者)を所有者として記述する。仮想センサの所有者と仮想センサを構成する実センサの所有者とは必ずしも同一人である必要はない。「センサの位置・姿勢」は空欄でもよいし、仮想センサを構成する実センサの設置位置や姿勢のデータを記述してもよい。「センサのアドレス」については、仮想センサの管理及び制御を担うサーバ(本実施形態ではM2Mクラウドサーバ)のネットワーク・アドレスを記述する。
【0055】
また、「3.センシング対象領域の属性情報」における「位置範囲」には、仮想センサが仮想的なセンシングを行う位置又は領域(つまり、仮想センサが出力する新たなセンシングデータが関係する位置又は領域)を示す対象領域データを記述する。例えば、複数の実センサの組み合わせにより広範囲の情報を取得する仮想センサの場合には、複数の実センサそれぞれのセンシング対象領域を包含する位置範囲を仮想センサのセンシング対象領
域とすることができる。あるいは、東名高速上り線の交通量を測定する実センサのセンシングデータを元に、所定時間後の首都高速道路の交通量を予測する仮想センサのように、実センサのセンシング対象領域と仮想センサのセンシング対象領域とが異なる場合もある。
【0056】
「5.実センサの属性情報」と「6.関数の属性情報」は仮想センサのメタデータにのみ含まれる情報である。「5.実センサの属性情報」は、当該仮想センサが入力センシングデータを取得する他のセンサを特定するためのセンサ識別データである。「実センサの属性情報」には、「センサ種別」と「センサID」とが含まれる。「センサID」によりデータ取得先のセンサを一意に特定することができる。仮想センサが複数の入力センシングデータを利用する場合には、入力センシングデータごとに「5.実センサの属性情報」を繰り返し記述する。なお、実センサの属性情報という項目名を付しているが、「センサID」には仮想センサのセンサIDを記述することもできる。仮想センサで生成されたセンシングデータを元に、他の仮想センサが新たなセンシングデータを生成することも可能だからである。「6.関数の属性情報」は、入力センシングデータから新たなセンシングデータを生成するのに用いる仮想センサ関数を特定するための関数識別データである。「関数の属性情報」には、「関数ID」が含まれる。「関数ID」により仮想センサDB131に登録された仮想センサ関数(プログラムモジュール)を呼び出すことが可能である。
【0057】
図3(b)は、ある仮想センサの情報を記述したメタデータの一例である。このメタデータを参照することで、この仮想センサが、9:00〜21:00に半蔵門交差点を通過する赤い自動車の車速を検知可能な速度センサであることが分かる。また仮想センサの所有者や、仮想センサを管理するM2Mクラウドサーバのネットワーク上のアクセス先なども特定することができる。
【0058】
(センシングデータのメタデータ)
図4(a)は、センシングデータのメタデータのデータ構造の一例である。センシングデータのメタデータとは、実センサ又は仮想センサで得られた個々のセンシングデータの属性を記述したデータである。センシングデータのメタデータには、「管理者または所有者のID」、「アクセス権限範囲」、「精度、単位系」、「信頼度」、「利用可能範囲」、「利用の対価の体系」、「使用センサのID」、「センシングデータID」などのデータが含まれる。
【0059】
「管理者または所有者のID」は、当該センシングデータの権利を管理または所有する者を特定するための識別情報である。当該センシングデータを出力したセンサの「所有者ID」と一致する場合もある。「アクセス権限範囲」は、当該センシングデータの利用を許可する権限の範囲を示す情報である。例えば、アクセス権限範囲が「0」の場合は誰でも利用可能、「1」の場合は第1の権限レベルの者まで利用可能、「2」の場合は第2の権限レベルの者まで利用可能、・・・のように利用される。「精度、単位系」は、当該センシングデータの精度(例えば有効桁数)、単位系を示す情報である。「信頼度」は、当該センシングデータの信頼度(例えば、センシングデータの値が許容誤差範囲内である確率)を示す情報である。「利用可能範囲」は、当該センシングデータの利用目的(例えば、アカデミック利用に限る、商用利用は不可など)を示す情報である。「利用の対価の体系」は、当該センシングデータを利用したときの対価支払の料金設定を示す情報である。例えば、従量課金か固定料金か、利用目的ごとの料金など、予めいくつかの料金体系が用意されており、「利用の対価の体系」には料金体系を指定する情報が記述される。「使用センサのID」は、当該センシングデータを出力したセンサの「センサID」である。「センシングデータID」は、当該センシングデータを一意に特定するための識別情報である。
【0060】
図4(b)は、あるセンシングデータの情報を記述したメタデータの一例である。このメタデータを参照することで、このセンシングデータの利用の是非を判断する際に参考となる情報を得ることができる。
【0061】
なお、センシングデータのメタデータは、センシングデータのレベルでデータ検索や提供元と利用先のマッチングを行う場合などに利用可能である。したがって、システムの仕様がセンサのレベルでの検索やマッチングに限られる場合には、センシングデータのメタデータは必須ではない。あるいは、トラフィックやデータ容量が超大となることを避けるために、一部のセンシングデータに対してのみメタデータを設定したり、個々のセンシングデータでなく、所定の条件で纏められたセンシングデータ群(例えばあるセンサの一日分のセンシングデータ群、ある地域に存在する複数のセンサから得られたセンシングデータ群など)に対して一つのメタデータを設定してもよい。
【0062】
(アプリ側メタデータ)
図5は、アプリ側メタデータのデータ構造の一例を示す。
【0063】
アプリ側メタデータには、アプリケーションが必要とするセンシングデータの条件(センサとセンシングデータの属性)を記述したデータである「1.必要とするセンサの属性情報」、「2.必要とするセンシング対象の属性情報」、「3.必要とするセンシング対象領域の属性情報」、「4.必要とするセンシング動作の属性情報」、「5.必要とするセンシングデータの管理属性」と、アプリケーション自身の属性を記述したデータである「6.アプリ自身のメタデータ」とが含まれる。
【0064】
「1.必要とするセンサの属性情報」から「5.必要とするセンシングデータの管理属性」までの項目に記述されるデータは、図2(a)、図3(a)、図4(a)に示した同名のデータと対応している。すなわち、アプリケーションが必要とするセンシングデータの条件に関わるメタデータは、センサ側メタデータの項目のなかから「センサの所有者ID」、「センサのID」、「管理者または所有者のID」、「センシングデータID」などのセンサ又はセンシングデータに固有の項目を除外したデータ構造を有している。
【0065】
「6.アプリ自身のメタデータ」は、「アプリのファイル名」、「当該アプリファイルが稼働するサーバのアドレス」、「当該アプリの起動を可能とするセンサ側イベントの定義」などのデータを含む。「アプリのファイル名」とは、アプリケーションサーバにインストールされているアプリケーションプログラムの名称であり、「当該アプリファイルが稼働するサーバのアドレス」とは、アプリケーションサーバのネットワーク・アドレス(IPアドレスなど)である。この2つを指定することで、アプリを特定することができる。「当該アプリの起動を可能とするセンサ側イベントの定義」は、アプリに引き渡すイベント符号(タグ名)を定義する情報である。例えば、センシングデータの値に対応するイベント符号(タグ名)を関数やテーブルなどで定義できる。
【0066】
(処理フロー)
次に、本システムの処理フローの一例を説明する。ここでは、アプリケーションサーバ12から発行されたアプリ側メタデータをセンサネットワークサーバ14が受信したことをトリガとして、センサネットワークサーバ14がアプリ側メタデータとセンサ側メタデータのマッチングを行い、適切なセンサからアプリへのセンシングデータのデータフロー制御指令を発行する処理例について説明する。このようにアプリ側メタデータがトリガとなる方式を、アプリ側メタデータ駆動型アクセスモードと呼ぶ。
【0067】
アプリ側メタデータ駆動型アクセスモードの一例として、以下、スマートフォンにイン
ストールされたカーナビゲーションアプリが、当該スマートフォンの所持者の移動に応じて、少し先(1km先、10分後など)の位置の映像や情報を提示する実施例を説明する。かかる機能は、車両進行方向での状況を把握し、進路変更するか否かを判断する際に利用できる。この実施例ではスマートフォンが図1のアプリケーションサーバ12に対応し、カーナビゲーションアプリがセンシングデータを利用するアプリケーションに対応する。また、当該アプリが利用するセンサとしては、他の車両に搭載されたセンサ、他の車両の乗員が所持するスマートフォン、道路や信号機などのインフラに設置されたセンサなどが想定される。
【0068】
例えば、渋滞に遭遇した運転者が所持するスマートフォンのカーナビゲーションアプリに対し、経路の案内要求を入力したとする。カーナビゲーションアプリは、経路案内に必要な情報を収集するために必要となるセンシングデータの条件を記述したアプリ側メタデータを生成し、アプリ側メタデータをセンサネットワークサーバ14に送信する。例えば、車両の現在位置と進行方向とカーナビゲーションアプリに設定された目的地の情報をもとにセンシングデータが必要なエリア(例えば現在位置と目的地を包含する円形エリア)を計算した上で、当該エリア内の道路状況に関わるデータを取得可能であり、且つ、現在時刻において利用可能なセンサを抽出するための条件をアプリ側メタデータに記述すればよい。
【0069】
センサネットワークサーバ14は、受信したアプリ側メタデータと、センサ側メタデータDB140に登録されているセンサ側メタデータとのマッチングを行い、アプリが必要とするセンシングデータを提供可能なセンサを特定する。センサ側メタデータDB140には、実センサと仮想センサいずれのセンサ側メタデータも登録されている。メタデータ同士のマッチングは、図5に示した「1.必要とするセンサの属性情報」から「5.必要とするセンシングデータの管理属性」までの項目に記述されたデータの全部又は一部を用いればよいので、実センサと仮想センサとで処理を分ける必要がない。すなわち、本実施形態で述べたデータ構造のメタデータを用いたことで、実センサと仮想センサを同じようにマッチングできる。
【0070】
アプリ側メタデータに記述された条件に合うセンサ側メタデータが抽出できた場合には、センサネットワークサーバ14は、アプリ側メタデータと抽出されたセンサ側メタデータとを参照して、センシングデータの提供元となるセンサとデータの利用先となるアプリケーションとを特定したデータフロー制御指令を生成する。データフロー制御指令には、少なくとも、データ提供元であるセンサを特定するための情報(例えばセンサのID、アドレスなど)と、データ利用先であるアプリケーションを特定するための情報(例えばアプリケーションサーバのアドレス、アプリのファイル名、タグ名など)とを含んでいる。あるいは、データフロー制御指令の中にアプリ側メタデータとセンサ側メタデータの全部又はサブセットを含めてもよい。センサネットワークサーバ14は、このデータフロー制御指令をセンサを管理する装置に対して送出する。具体的には、実センサの場合であれば、実センサを管理するセンサネットワークアダプタ11に対しデータフロー制御指令を送り、仮想センサの場合であれば、仮想センサの管理機能をもつM2Mクラウドサーバ13に対しデータフロー制御指令を送る。
【0071】
データフロー制御指令を受信したセンサネットワークアダプタ11は、データフロー制御指令の中で指定されたセンサからセンシングデータを取得し、所定のヘッダを付してパケットデータを生成し、当該パケットデータをネットワーク経由でアプリケーションに送信する。センシングデータとしては例えば他の車両の位置情報や速度情報、他の車両や道路上のカメラで撮影された映像情報などが考えられる。
【0072】
一方、データフロー制御指令を受信したM2Mクラウドサーバ13は、データフロー制
御指令の中で指定された仮想センサについて、必要な処理を実行する。具体的には、当該仮想センサの処理に必要な入力センシングデータをセンシングデータDB130から取得し、仮想センサDB131から仮想センサ関数を呼び出す。これにより、入力センシングデータを元に新たなセンシングデータが生成される。例えば、車両の進行方向1km先のエリアに点在する複数台のカメラの映像データを元に、複数の経路の交通状況を計算し、新たなセンシングデータとして出力する処理などが想定される。生成した新たなセンシングデータは、所定のヘッダが付されたパケットデータとして、アプリケーションに送信される。
【0073】
入力センシングデータの取得先となるセンサIDや、呼び出す仮想センサ関数を特定する関数IDについては、センサ側メタデータに記述されている。例えばデータフロー制御指令のなかにセンサ側メタデータの全部又はサブセットが含まれている場合は、M2Mクラウドサーバ13は、データフロー制御指令からセンサIDや関数IDを取得可能である。別の構成として、M2Mクラウドサーバ13の側にも、センサネットワークサーバ14のセンサ側メタデータDB140と同様の仮想センサ定義データベースを設けてもよい。この場合、データフロー制御指令のなかに少なくとも仮想センサのセンサIDを記述しておけば、このセンサIDをキーとして、M2Mクラウドサーバ13が仮想センサ定義データベースから仮想センサを構成する他のセンサのIDや関数IDなどを取得することが可能である。
【0074】
以上に示すシステムによれば、センサと利用者が固定された従来のIoTと異なり、ネットワーク上において、センシングデータの送受信に関して利用対価の処理を含む情報流通の最適化が可能となる。そのため、アプリケーションサーバにおいて新たな付加価値のある情報が生成されてセンサ資源が有効活用される。例えば、移動する車両などのセンサ情報が必要な場合など、構成要素が流動的なシステムにおいてシームレスに情報提供ができる。また、アプリケーションの側では、複数のセンサ候補がある場合に利用対価などの条件に基づき有利なセンサを選択したり、複数のセンサを全て用いて精度を上げたりできる。また、センシングデータ処理はセンサやアプリの特性に応じて様々な粒度で実行可能なので、汎用性の高いデータ基盤を形成できる。
【0075】
特に本システムでは、メタデータにより仮想センサの属性を記述することによって、センシング対象の位置・領域やセンサ種別・データ種別などの条件による仮想センサの検索やマッチングを、当該メタデータを利用して行うことを可能にしている。センシング対象の位置・領域やセンサ種別・データ種別といった条件であれば、仮想センサと実センサを区別なく(同じ検索条件を用いて)扱うことができる。これにより、センサの利用側(利用者又は利用アプリケーション)の利便性を向上することができる。一方、このメタデータを参照すれば仮想センサの動作に必要な他のセンサを特定することも可能であるため、仮想センサの管理側(管理システム)の処理(例えば、仮想センサの動作に必要なデータの取得及び新たなセンシングデータの生成など)の利便性も向上する。これより、センサネットワークにおける仮想センサの利用及び仮想センサのセンシングデータの流通を容易化することが可能となる。
【0076】
(変形例)
上述した実施形態は本発明の一具体例を示したものであり、本発明の範囲をそれらの具体例に限定する趣旨のものではない。
【0077】
例えば上記実施形態で図示したメタデータのデータ構造は一例であり、図示されたすべての項目を含んでいる必要はないし、逆に図示された項目以外の項目を含んでいてもよい。また、図1に示したセンサネットワークシステムの構成も一例にすぎず、他の構成のシステムで本発明に係るメタデータを利用することも可能である。
【符号の説明】
【0078】
10:実センサ
11:センサネットワークアダプタ
12:アプリケーションサーバ
13:クラウドサーバ
14:センサネットワークサーバ
130:センシングデータDB
131:仮想センサDB
140:センサ側メタデータDB
図1
図2
図3
図4
図5