特許 6398894 データフロー制御装置およびデータフロー制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6398894

(24)【登録日】2018年9月14日

(45)【発行日】2018年10月3日

(54)【発明の名称】データフロー制御装置およびデータフロー制御方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20180920BHJP

   H04M 11/00 20060101ALI20180920BHJP

【ＦＩ】

   G06F13/00 351N

   H04M11/00 301

【請求項の数】12

【全頁数】19

(21)【出願番号】特願2015-131161(P2015-131161)

(22)【出願日】2015年6月30日

(65)【公開番号】特開2017-16306(P2017-16306A)

(43)【公開日】2017年1月19日

【審査請求日】2018年4月12日

【早期審査対象出願】

(73)【特許権者】

【識別番号】000002945

【氏名又は名称】オムロン株式会社

(74)【代理人】

【識別番号】100124039

【弁理士】

【氏名又は名称】立花 顕治

(74)【代理人】

【識別番号】100179213

【弁理士】

【氏名又は名称】山下 未知子

(74)【代理人】

【識別番号】100170542

【弁理士】

【氏名又は名称】桝田 剛

(74)【代理人】

【識別番号】100150072

【弁理士】

【氏名又は名称】藤原 賢司

(72)【発明者】

【氏名】久野 敦司

【審査官】 小林 義晴

(56)【参考文献】

【文献】 国際公開第２０１３／１５３８９０（ＷＯ，Ａ１）

【文献】 国際公開第２０１４／０３０５１０（ＷＯ，Ａ１）

【文献】 中村哲也，他２名，適応型通信サービスにおけるコンテクスト情報提供方式，情報処理学会研究報告，日本，社団法人情報処理学会，２０００年 ２月 ４日，第2000巻,第14号，p.83-90

【文献】 小村和輝，他２名，移動エントロピーを用いた銘柄間影響度ネットワークによる投資指標の分析，第１３回人工知能学会金融情報学研究会資料（ＳＩＧ−ＦＩＮ−０１３−０８），日本，人工知能学会，２０１４年１０月１１日，p.1-6

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｈ０４Ｍ １１／００

(57)【特許請求の範囲】

【請求項1】

複数のデバイスのうちの少なくともいずれかのデバイスにおいて得られるデータを、当該データを利用するアプリケーションへと提供する、データフローを制御するためのデータフロー制御装置であって、
前記複数のデバイスのそれぞれにおいて得られるデータである複数のデバイス指標と、
前記アプリケーションが制御又は予測する指標である目的指標とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークを記憶する因果ネットワーク記憶部と、
前記アプリケーションからデータ要求を受けた場合に、前記因果ネットワークに基づき、前記アプリケーションの目的指標と因果関係を有する少なくとも１つのデバイス指標を前記複数のデバイス指標の中から選択するデバイス指標選択部と、
前記選択されたデバイス指標に対応するデバイスにおいて得られるデータが、前記アプリケーションへ提供されるように、データフローを制御するデータフロー制御部と、
を有することを特徴とするデータフロー制御装置。

【請求項2】

前記因果関係は、２つの指標のあいだの因果強度の情報と、前記２つの指標のうちの一方の指標の影響が他方の指標に伝播するのにかかる遅延時間の情報とを含む
ことを特徴とする請求項１に記載のデータフロー制御装置。

【請求項3】

前記因果関係は、移動エントロピーを用いて定義される
ことを特徴とする請求項２に記載のデータフロー制御装置。

【請求項4】

前記デバイス指標選択部は、前記因果ネットワークにおいて、前記目的指標からの距離が近いデバイス指標を優先的に選択し、距離が同じ場合には因果強度が強い方のデバイス指標を優先的に選択し、距離も因果強度も同じ場合には遅延時間が短い方のデバイス指標を優先的に選択する
ことを特徴とする請求項２又は３に記載のデータフロー制御装置。

【請求項5】

前記デバイス指標選択部は、デバイスがアクティブか非アクティブかを確認し、非アクティブなデバイスに対応するデバイス指標を選択の対象から除外する
ことを特徴とする請求項１〜４のうちいずれか１項に記載のデータフロー制御装置。

【請求項6】

複数のデバイスのうちの少なくともいずれかのデバイスにおいて得られるデータを、当該データを利用するアプリケーションへと提供する、データフローを制御するためのデータフロー制御方法であって、
コンピュータが、前記アプリケーションからデータ要求を受けた場合に、前記複数のデバイスのそれぞれにおいて得られるデータである複数のデバイス指標と、前記アプリケーションが制御又は予測する指標である目的指標とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークに基づき、前記アプリケーションの目的指標と因果関係を有する少なくとも１つのデバイス指標を前記複数のデバイス指標の中から選択するステップと、
前記コンピュータが、前記選択されたデバイス指標に対応するデバイスにおいて得られるデータが、前記アプリケーションへ提供されるように、データフローを制御するステップと、
を有することを特徴とするデータフロー制御方法。

【請求項7】

請求項６に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラム。

【請求項8】

複数のデバイスの各々からデバイス指標の時系列データを取得し、
前記複数のデバイスのうちの少なくともいずれかからデータの提供を受け、当該データを利用するアプリケーションから、当該アプリケーションが制御又は予測する指標である目的指標の時系列データを取得し、
前記複数のデバイスにそれぞれ対応する複数の前記デバイス指標の前記時系列データ及び前記目的指標の前記時系列データに基づいて、前記複数のデバイス指標と前記目的指標とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークを生成する因果ネットワーク生成部
を有することを特徴とする学習装置。

【請求項9】

前記因果関係は、２つの指標のあいだの因果強度の情報と、前記２つの指標のうちの一方の指標の影響が他方の指標に伝播するのにかかる遅延時間の情報とを含む
ことを特徴とする請求項８に記載の学習装置。

【請求項10】

前記因果関係は、移動エントロピーを用いて定義される
ことを特徴とする請求項８又は９に記載の学習装置。

【請求項11】

コンピュータが、複数のデバイスの各々からデバイス指標の時系列データを取得するステップと、
前記コンピュータが、前記複数のデバイスのうちの少なくともいずれかからデータの提供を受け、当該データを利用するアプリケーションから、当該アプリケーションが制御又は予測する指標である目的指標の時系列データを取得するステップと、
前記コンピュータが、前記複数のデバイスにそれぞれ対応する複数の前記デバイス指標の前記時系列データ及び前記目的指標の前記時系列データに基づいて、前記複数のデバイス指標と前記目的指標とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークを生成するステップと、
を有することを特徴とする学習方法。

【請求項12】

請求項１１に記載の学習方法の各ステップをコンピュータに実行させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、センサなどのデバイスにおいて得られるデータを当該データを利用するアプリケーションへと提供するデータフローを制御するための技術に関する。

【背景技術】

【0002】

現在、Ｍ２Ｍクラウドと呼ばれるＩＴ環境が注目を集めている。Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）とは、様々な用途、大きさや性能を持つ機械同士がネットワーク上で情報をやり取りするシステムを指す。この情報を利用することで、それぞれの機械の適切な制御や、実社会の状況解析が可能になる。Ｍ２Ｍを支える無線通信技術の向上や機械の小型化、低廉化などにより、実用化への期待が高まっている。

【0003】

このようなＭ２Ｍの技術をクラウドコンピューティング環境上で実現したものはＭ２Ｍクラウドと呼ばれる。これは、Ｍ２Ｍに必要な基本機能、例えばデータの収集蓄積から加工、分析のようなサービスをクラウド上のアプリケーションとして提供し、どこからでも利用可能にしたものである。データの一括管理によって信頼性や網羅性を高めることができる。また利用者にとっては、収集されたデータやコンピュータ資源を必要な分だけ利用できるメリットがある。そのため、個別にシステムを構築することなくビッグデータを解析して付加価値を得ることが可能であり、幅広い分野での応用が期待されている。

【0004】

また、特許文献１に示すように、センサネットワークと呼ばれる技術が検討されている。これは、センシング機能と通信機能をもつセンサデバイス（以下、単に「センサ」とも呼ぶ）を様々な場所や産業設備に設置し、それらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能とするものである。

【0005】

通常、センサは、その所有者自身が必要とするデータを収集するために設置される。そのため所有者がデータ収集を行うとき以外は利用されていない（センサ自体が稼働していない、またはセンサが稼働していてもセンシングデータが利用されない）ことが多い。そのためセンシングデータの流通性は低く、第三者にとっていかに有意義なデータであっても、センサの所有者自身による分析、利用に留まっていた。その結果、設備の重複投資や、各自が設置したセンサとの通信によるネットワークの輻湊を招いていた。

【0006】

また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）という技術が検討されている。これは、世界に存在する多くの物に関する情報をネット上で組み合わせることで新しい価値を生むもので、社会インフラを始めとする様々なサービスのシームレスな展開が期待されている。ＩｏＴから価値を生み出すためには、ネットに繋がる物の状態を知る必要があり、センシングと通信が重要な要素技術となる。

【0007】

そこで本出願人は、ＩｏＴにおいてセンシングデータなどの資源を適切に流通させる仕組みを実現するため、センサに関する情報が記述された「センサ側メタデータ」とセンシングデータを利用するアプリケーションに関する情報が記述された「アプリ側メタデータ」とのマッチングを行うことで、アプリケーションの要求を満たすセンシングデータを取得可能なセンサを特定し、センサからアプリケーションへのデータフローを制御するシステムを検討している（特許文献３参照）。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２００７−３００５７１号公報

【特許文献2】特開２０００−３３１２８４号公報

【特許文献3】国際公開第２０１４／０４１８２６号

【発明の概要】

【発明が解決しようとする課題】

【0009】

特許文献３のシステムでは、アプリ側メタデータの中に、アプリケーションが必要とするセンシングデータの種類や仕様を定義しなければならない。

【0010】

しかしながら、アプリケーションの開発者や設計者が、アプリケーションの目的を達成するために、どのようなデバイスからどのようなセンシングデータを収集しアプリケーションの制御に役立てればよいか、を適切に設計するのは容易ではない。その理由の一つは、ＩｏＴではあらゆるセンサがネットワークに接続され、膨大な数・様々な種類のセンシングデータが利用可能となるからである。また、第二の理由は、現実世界においては様々な事象や要素が複雑に関連しているため、それを適切にモデル化し、アプリケーションの目的（結果）と強い因果関係をもつセンシングデータ（原因）を見極めるのが極めて難しいことにある。

【0011】

また仮に、必要なセンシングデータの種類や仕様を事前に定義できたとしても、センサの停止・故障・移動などによりネットワークの構成（つまり、利用可能なセンサや取得可能なデータ）が時々刻々と変化する可能性があり、定義どおりのセンシングデータが得られない事態も発生し得る。システムのロバスト性を高めるためには、利用可能なセンサやセンシングデータのうちから最も適切なものをアプリケーションに提供できるようなフレキシブルな仕組みが望ましい。

【0012】

なお、ここまでセンサネットワークを例に挙げて説明をしたが、アクチュエータ（コントローラ）のネットワークの場合にも、全く同様の課題が発生し得る。「センサ」と「アクチュエータ（コントローラ）」とは、「状態を検知（取得）する」のか「状態を変化させる」のかという違いはあるものの、所定の範囲の対象領域に対して何らかの作用を行うという点では共通である。アクチュエータネットワークの場合は、センサから得られるセンシングデータの代わりに、アクチュエータに与えるコントロールデータが流通の対象となる。以下、「センサ」と「アクチュエータ」を包含する概念として「デバイス」という用語を用いる。また、「センサネットワーク」と「アクチュエータネットワーク」を包含する概念として「デバイスネットワーク」という用語を用いる。デバイスネットワークにはセンサとアクチュエータの両方が接続されることもあり得る。

【0013】

本発明は上記実情に鑑みなされたものであり、デバイスネットワークにおけるデータの利用をより容易にするための技術を提供することを目的とする。

【課題を解決するための手段】

【0014】

請求項１に係る発明は、複数のデバイスのうちの少なくともいずれかのデバイスにおいて得られるデータを、当該データを利用するアプリケーションへと提供する、データフローを制御するためのデータフロー制御装置であって、前記複数のデバイスのそれぞれにおいて得られるデータである複数のデバイス指標と、前記アプリケーションが制御又は予測する指標である目的指標とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークを記憶する因果ネットワーク記憶部と、前記アプリケーションからデータ要求を受けた場合に、前記因果ネットワークに基づき、前記アプリケーションの目的指標と因果関係を有する少なくとも１つのデバイス指標を前記複数のデバイス指標の中から選択するデバイス指標選択部と、前記選択されたデバイス指標に対応するデバイスにおいて得られるデータが、前記アプリケーションへ提供されるように、データフローを制御するデータフロー制御部と、を有することを特徴とするデータフロー制御装置である。

【0015】

請求項１に係る発明によれば、アプリケーションの目的（アプリケーションが制御又は予測する指標）を与えると、その目的と因果関係を有するデータが、対応するデバイスからアプリケーションへと自動的に提供される。したがって、デバイスネットワーク内にどのようなデバイスが存在しどのようなデータが取得できるかとか、目的とする制御や予測を行うためにどのようなデータを参照すべきか、といった知識がなくても、アプリケーションの設計・開発が可能となる。よって、従来に比べて、デバイスネットワークにおけるデータを利用するアプリケーションの設計・開発が容易となり、デバイスネットワークにおけるデータの利用・流通が促進される。

【0016】

請求項２に係る発明は、前記因果関係は、２つの指標のあいだの因果強度の情報と、前記２つの指標のうちの一方の指標の影響が他方の指標に伝播するのにかかる遅延時間の情報とを含むことを特徴とする請求項１に記載のデータフロー制御装置である。請求項２に係る発明によれば、一方の指標（原因指標）から他方の指標（結果指標）への時間遅れ（伝播遅延）を考慮した因果関係を評価できる。

【0017】

請求項３に係る発明は、前記因果関係は、移動エントロピーを用いて定義されることを特徴とする請求項２に記載のデータフロー制御装置である。請求項３に係る発明によれば、移動エントロピーを用いることで時間遅れ（伝播遅延）を伴う因果関係及びその因果強度を適切に求めることができる。

【0018】

請求項４に係る発明は、前記デバイス指標選択部は、前記因果ネットワークにおいて、前記目的指標からの距離が近いデバイス指標を優先的に選択し、距離が同じ場合には因果強度が強い方のデバイス指標を優先的に選択し、距離も因果強度も同じ場合には遅延時間が短い方のデバイス指標を優先的に選択することを特徴とする請求項２又は３に記載のデータフロー制御装置である。請求項４に係る発明によれば、目的指標との関係が最も強いデバイス指標を選択することができる。このように選択されたデバイス指標を用いれば、高い妥当性をもって目的指標の値を推測することができる。

【0019】

請求項５に係る発明は、前記デバイス指標選択部は、デバイスがアクティブか非アクティブかを確認し、非アクティブなデバイスに対応するデバイス指標を選択の対象から除外することを特徴とする請求項１〜４のうちいずれか１項に記載のデータフロー制御装置である。請求項５に係る発明によれば、例えば、故障、停止、移動など、何らかの原因によって非アクティブな状態（データを取得できない状態）となっているデバイスが選択の対象から除外される。したがって、現在アクティブなデバイスのなかから、適切なデバイス（アプリケーションの目的指標と因果関係を有するデータを取得可能なデバイス）を自動で選択でき、システムのロバスト性を高めることができる。

【0020】

請求項６に係る発明は、複数のデバイスのうちの少なくともいずれかのデバイスにおいて得られるデータを、当該データを利用するアプリケーションへと提供する、データフローを制御するためのデータフロー制御方法であって、前記アプリケーションからデータ要求を受けた場合に、前記複数のデバイスのそれぞれにおいて得られるデータである複数のデバイス指標と、前記アプリケーションが制御又は予測する指標である目的指標とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークに基づき、前記アプリケーションの目的指標と因果関係を有する少なくとも１つのデバイス指標を前記複数のデバイス指標の中から選択するステップと、前記選択されたデバイス指標に対応するデバイスにおいて得られるデータが、前記アプリケーションへ提供されるように、データフローを制御するステップと、を有することを特徴とするデータフロー制御方法である。

【0021】

請求項６に係る発明によれば、アプリケーションの目的（アプリケーションが制御又は
予測する指標）を与えると、その目的と因果関係を有するデータが、対応するデバイスからアプリケーションへと自動的に提供される。したがって、デバイスネットワーク内にどのようなデバイスが存在しどのようなデータが取得できるかとか、目的とする制御や予測を行うためにどのようなデータを参照すべきか、といった知識がなくても、アプリケーションの設計・開発が可能となる。よって、従来に比べて、デバイスネットワークにおけるデータを利用するアプリケーションの設計・開発が容易となり、デバイスネットワークにおけるデータの利用・流通が促進される。

【0022】

請求項７に係る発明は、請求項６に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラムである。

【0023】

請求項７に係る発明によれば、アプリケーションの目的（アプリケーションが制御又は予測する指標）を与えると、その目的と因果関係を有するデータが、対応するデバイスからアプリケーションへと自動的に提供される。したがって、デバイスネットワーク内にどのようなデバイスが存在しどのようなデータが取得できるかとか、目的とする制御や予測を行うためにどのようなデータを参照すべきか、といった知識がなくても、アプリケーションの設計・開発が可能となる。よって、従来に比べて、デバイスネットワークにおけるデータを利用するアプリケーションの設計・開発が容易となり、デバイスネットワークにおけるデータの利用・流通が促進される。

【0024】

請求項８に係る発明は、センシングデータを出力するセンサを管理する情報処理装置が読み取り可能なデータストリームであって、前記センシングデータを利用するアプリケーションを特定する情報と、前記アプリケーションが制御又は予測する指標である目的指標と因果関係を有するセンシングデータを出力するものとして選択されたセンサを特定する情報と、前記選択されたセンサで得られるセンシングデータと前記目的指標のあいだの因果関係情報と、を含むことを特徴とする制御指令データストリームである。請求項８に係る発明によれば、アプリケーションの目的（アプリケーションが制御又は予測する指標）と因果関係を有するセンシングデータが対応するセンサからアプリケーションへと提供されるデータフローを実現できる。

【0025】

請求項９に係る発明は、前記因果関係情報は、前記センシングデータと前記目的指標のあいだの因果強度の情報と、前記センシングデータの影響が前記目的指標に伝播するのにかかる遅延時間の情報とを含むことを特徴とする請求項８に記載の制御指令データストリームである。請求項９に係る発明によれば、センシングデータ（原因指標）から目的指標（結果指標）への時間遅れ（伝播遅延）を考慮した因果関係を考慮したデータフロー制御を実現できる。

【0026】

なお、本発明は、上記構成ないし機能の少なくとも一部を有するデータフロー制御装置として捉えることができる。また、本発明は、データフロー制御装置を有するデバイスネットワークシステム、センサネットワークシステム、アクチュエータネットワークシステムとして捉えることもできる。また、本発明は、上記処理の少なくとも一部を含むデータフロー制御方法、又は、かかる方法をコンピュータに実行させるためのプログラム、又は、そのようなプログラムを非一時的に記録したコンピュータ読取可能な記録媒体として捉えることもできる。また、本発明は、上記データフローを制御するための制御指令データストリームとして捉えることもできる。上記構成及び処理の各々は技術的な矛盾が生じない限り互いに組み合わせて本発明を構成することができる。

【発明の効果】

【0027】

本発明によれば、デバイスネットワークにおけるデータの利用をより容易にすることができる。

【図面の簡単な説明】

【0028】

【図1】デバイスネットワークシステムの因果ネットワークの生成に関わる機能を示すブロック図。

【図2】デバイスネットワークシステムのデータフロー制御に関わる機能を示すブロック図。

【図3】因果ネットワークの生成処理のフローチャート。

【図4】因果ネットワークの生成処理のフローチャート。

【図5】目的指標の時系列データの一例。

【図6】デバイス指標の時系列データの一例。

【図7】因果関係データの一例。

【図8】因果ネットワークの一例。

【図9】デバイス指標の選択処理およびデータフロー制御処理のフローチャート。

【図10】因果ネットワークに基づくデバイス指標の選択を模式的に示す図。

【図11】因果ネットワークに基づくデバイス制御を模式的に示す図。

【発明を実施するための形態】

【0029】

＜システム構成＞
図１および図２を参照して、本発明の実施形態に係るデバイスネットワークシステムの構成例を説明する。図１は、デバイスネットワークシステムの因果ネットワークの生成に関わる機能を示すブロック図であり、図２は、デバイスネットワークシステムのデータフロー制御に関わる機能を示すブロック図である。

【0030】

デバイスネットワークシステムとは、多数のデバイスにおいて取得されるデータを、それを利用するアプリケーションへとオンライン且つリアルタイムで提供可能な仕組みである。デバイスネットワークシステムは、主に、デバイスネットワーク１、Ｍ２Ｍクラウドサーバ２、アプリケーション３、データフロー制御装置４などで構成される。

【0031】

（デバイスネットワーク）
デバイスネットワーク１は、多数のデバイス１０によって構成されるネットワークである。デバイス１０の数、種類、設置位置、ネットワークの構成や通信方式などは任意に設計でき、特に限定されない。各々のデバイス１０は、例えばインターネットなどの広域ネットワークを介してＭ２Ｍクラウドサーバ２、アプリケーション３、データフロー制御装置４と通信可能である。

【0032】

各々のデバイス１０は、空間又は時空間で規定される対象領域に対して作用するデバイスであって、「センサ」と「アクチュエータ」とに大別できる。ここで「空間」とは２次元（ｘ，ｙ）又は３次元（ｘ，ｙ，ｚ）で規定される領域であり、「時空間」とは「空間」に「時間（ｔ）」の次元を加えたもの、つまり３次元（ｘ，ｙ；ｔ）又は４次元（ｘ，ｙ，ｚ；ｔ）で規定される領域をいう。なお本明細書では、「センサ」の語を、対象領域の状態を検知（取得）するデバイスという意味で用い、「アクチュエータ」の語を、対象領域の状態を変化させるデバイスという意味で用いる。センサには、例えば、画像センサ（カメラ）、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、ＲＦＩＤセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射能センサ、ガスセンサなどが該当し、本システムではいかなる種類のセンサも利用することができる。またアクチュエータには、例えば、モータ、ソレノイド、コントローラ、ロボット、照明、スピーカ、ディスプレイ、デジタルサイネージ、空調など様々なものが該当し、本システムではいかなる種類のアクチュエータも利用することができる。携帯電話、スマートフォン、スレート型端末（タブレットＰＣ）のように、センサ（画像センサなど）とアクチュエータ（ディスプレイ、スピーカなど）の両方を備えるデバイスも存在する。なお、デバイスネットワーク１の
中には、様々な種類のデバイスを混在させることが可能である。

【0033】

（Ｍ２Ｍクラウドサーバ）
Ｍ２Ｍクラウドサーバ２は、デバイスネットワーク１を構成する各デバイス１０に関する情報や各デバイス１０にて取得されたデータなどを管理すると共に、各デバイス１０にて取得されたデータを広域ネットワークを通じて利用者（アプリケーション３）へと提供するサーバシステムである。

【0034】

Ｍ２Ｍクラウドサーバ２は、デバイス１０を管理するためのデータベースであるデバイスデータＤＢ２０を有する。デバイスデータＤＢ２０には、デバイスに関する情報として、例えば、デバイスの属性情報（デバイスの種類、デバイスの位置・姿勢、デバイスの所有者、デバイスＩＤ、ネットワークアドレス、動作履歴など）、対象領域（センシングする領域又はアクチュエータが作用を及ぼす領域）の属性情報（位置範囲、時間範囲など）、対象物（センシングの対象又はアクチュエータが作用を及ぼす対象）の属性情報（種類、物理属性、対象物ＩＤなど）、動作の属性情報（制御可能な項目、センシングのサンプリング仕様、量子化仕様など）、データの属性（データの管理者または所有者、利用範囲（例えばアカデミック利用に限る、商用利用禁止など）、アクセス権限範囲、データの種類、精度、単位系、信頼度、利用可能範囲、利用の対価、利用可能時間、データＩＤなど）などが登録される。またデバイスデータＤＢ２０には、デバイスにて取得されたデータとして、センサの場合にはセンシングデータ（センサ測定値）が、アクチュエータの場合にはコントロールデータ（アクチュエータ制御値）が、それぞれ格納される。センシングデータやコントロールデータは最新のデータだけでなく、所定の期間分の時系列データが蓄積されているとよい。

【0035】

（アプリケーション）
アプリケーション３は、デバイスネットワーク１から得られるデータを利用する装置又はソフトウェアモジュールである。アプリケーション３としては、デバイスネットワーク１から得られるデータを基に制御対象を制御するものや、デバイスネットワーク１から得られるデータを基に未知又は未来の状態を予測するものなどが想定される。例えば、オフィスの生産性を向上させるアプリケーション、工場の消費エネルギを抑えたり予測したりするアプリケーション、渋滞予測を行うアプリケーションなど、いかなるアプリケーションでもよい。

【0036】

（データフロー制御装置）
データフロー制御装置４は、デバイスとアプリケーションのあいだの条件のマッチングを行い、アプリケーションが所期の目的（制御ないし予測）を達成するのに必要なデータが適切なデバイスから提供されるように、データフローを制御する機能を有する。

【0037】

従来システム（特許文献３参照）では、アプリケーションが必要なデータの仕様を定義したアプリ側メタデータを発行し、その要求仕様を満たすデバイスを探索するという仕組みを採っていた。しかしこのような仕組みの場合、アプリケーションの開発者や設計者が、デバイスネットワーク１内にどのようなデバイスが存在しどのようなデータが取得できるか、さらには、目的とする制御や予測を行うためにどのようなデータを参照すべきか、等を理解していなければならず、高度な開発スキルが要求されていた。また、前述した「オフィスの生産性の向上」を目的とするアプリケーションのように、目的とする制御や予測を行うためにどのようなデータを参照すればよいのか、容易には分からないケースも多い。また一見すると簡単に見える問題でも、実は現実世界における様々な事象が絡み合っているということもある。

【0038】

そこで、本システムでは、データフロー制御装置４が、（１）複数のデバイス１０のそ
れぞれにおいて得られるデータ（「デバイス指標」とよぶ）と、アプリケーション３が制御又は予測する指標（「目的指標」とよぶ）とを少なくとも含む、複数の指標のあいだの因果関係を表す因果ネットワークを生成する機能（図１参照）と、（２）この因果ネットワークを用いて、目的指標と因果関係をもつデバイス指標を選択し、その選択されたデバイス指標のデータがアプリケーション３へ提供されるようにデータフローを制御する機能（図２参照）を実施する。ここで、「アプリケーションが制御する指標」とは、アプリケーションが制御する制御対象の状態等を表す指標を意味し、例えば、制御対象の状態や出力をセンサ等により測定することで観測できる指標である。例えば、オフィスの生産性を向上するアプリケーションの場合であれば、生産性を直接又は間接的に表す指標として、時間当たりの処理件数や売り上げなどを目的指標として用いることができる。また「アプリケーションが予測する指標」とは、アプリケーションが計算によって予測ないし推定する指標を意味する。例えば、渋滞予測を行うアプリケーションの場合であれば、道路を通過するのに見込まれる時間や渋滞の長さなどを目的指標として用いることができる。詳細については後述する。

【0039】

Ｍ２Ｍクラウドサーバ２、アプリケーション３を実行する装置、データフロー制御装置４は、いずれも、ＣＰＵ（中央演算処理装置）、メモリ、補助記憶装置、通信ＩＦ、入力デバイス、表示デバイスなどを有する汎用のコンピュータにより構成することができる。後述する機能及び処理は、補助記憶装置に格納されたプログラムをＣＰＵが読み込み、実行することにより、実現されるものである。コンピュータとしては、パーソナルコンピュータ、スマートフォン、携帯情報端末などでもよいし、サーバコンピュータでもよい。また、一台のコンピュータでなく、複数のコンピュータにより分散処理を行ってもよい。

【0040】

＜因果ネットワークの生成＞
図１、図３〜図８を参照して、本実施形態のデータフロー制御装置４による因果ネットワークの生成について説明する。図３及び図４は、因果ネットワークの生成処理のフローチャートであり、図５は、目的指標の時系列データの一例、図６Ａ〜図６Ｄは、デバイス指標の時系列データの一例である。図７は、因果関係データの一例であり、図８は、因果ネットワークの一例である。

【0041】

本実施形態では、一具体例として、オフィスの生産性を向上するアプリケーション３を例に挙げる。図１および図３に示すように、データフロー制御装置４の因果ネットワーク生成部４０は、アプリケーション３から目的指標の時系列データを取得する（ステップＳ３０）。図５に目的指標の時系列データの一例を示す。ここでは、一時間ごとのオフィスの生産性を示す指標値（単位なし）が与えられる。この時系列データは、アプリケーション３が所定期間にわたって測定し記録したデータであり、例えば、時間当たりの処理件数や売り上げなどを目的指標として用いることができる。時系列データの期間は任意であるが、因果関係推定の信頼性を考慮すると、少なくとも数日間、望ましくは数週間から数か月分の時系列データが得られるとよい。

【0042】

次に、因果ネットワーク生成部４０は、Ｍ２Ｍクラウドサーバ２のデバイスデータＤＢ２０から、各デバイス１０のデバイス指標の時系列データを取得する（ステップＳ３１）。例えば、オフィス内に設置された温度センサで測定された室温の時系列データ（図６Ａ）、オフィスの外の設置された温度センサで測定された外気温の時系列データ（図６Ｂ）、オフィス内のエアコンの消費電力量の時系列データ（図６Ｃ）、オフィス内に設置された騒音センサで測定された騒音レベルの時系列データ（図６Ｄ）など、様々なデバイス指標を取得するとよい。他にも、例えば、オフィス内のエアコンの制御値（温度設定値）、オフィスの天井照明の制御値（明るさ設定）、オフィス内に設定された照度センサの測定値、オフィス全体の消費電力量、オフィスのＬＡＮのネットワーク負荷、オフィスのプリンタや複写機の印刷枚数など、様々な種類のセンシングデータないしコントロールデータ
を取得するとよい。なお、デバイスネットワーク１を構成するデバイス１０の数が膨大であり、すべてのデバイス１０のデバイス指標の時系列データを取得することがデータ容量や計算コストの点から現実的でない場合には、ステップＳ３１において一部のデバイス１０のデバイス指標の時系列データのみを取得してもよい。例えば、アプリケーション３の制御対象や予測範囲、あるいは位置範囲などに基づいて、関連性のありそうなデバイスを大まかに絞り込み、その絞り込まれたデバイスの時系列データのみをＭ２Ｍクラウドサーバ２から受け取ればよい（デバイスの絞り込みはＭ２Ｍクラウドサーバ２とデータフロー制御装置４のいずれが行ってもよい）。これにより因果ネットワークの生成にかかる計算コストを低減することができる。

【0043】

次に、因果ネットワーク生成部４０は、目的指標とデバイス指標の時系列データに基づき、２つの指標（原因と結果）の全通りの組み合わせについて、因果強度・相関係数・遅延時間を計算する（ステップＳ３２）。ステップＳ３２の処理の詳細を図４のフローチャートに示す。ここでは、目的指標とデバイス指標をあわせてｍ個の指標Ｅ１〜Ｅｍが得られたものとする。

【0044】

因果ネットワーク生成部４０は、ｍ個の指標Ｅ１〜Ｅｍの中から２つの指標の組（Ｅｉ，Ｅｊ）を選択し（ステップＳ４１）、以下に述べる処理を行う。ここで、Ｅｉが原因指標、Ｅｊが結果指標を表し、指標番号を表す添え字ｉ、ｊは、ｉ＝１〜ｍ、ｊ＝１〜ｍ、ｉ≠ｊを満たす。

【0045】

まず因果ネットワーク生成部４０は、遅延時間ｓを最小値ｓｍｉｎに設定する（ステップＳ４２）。そして、因果ネットワーク生成部４０は、原因指標Ｅｉと時間ｓ後の結果指標Ｅｊのあいだの因果強度を求める（ステップＳ４３）。本実施形態では、移動エントロピーＴＥｉｊを因果強度として用いる。

【0046】

移動エントロピーとは、二つの指標Ｘ、Ｙのあいだの伝播時間（遅延時間）を考慮した因果関係を評価する尺度ないし手法であり、指標Ｘから時間ｓ後の指標Ｙへと移動した平均情報量（エントロピー）を、原因指標Ｘが時間ｓ後に結果指標Ｙに与える影響の強さ（つまり因果強度）とみなす考え方である。なお、似た概念に相関係数があるが、相関係数は２つの指標ＸとＹの間の線形関係の度合いと線形関係の符号を評価するだけであり、因果の方向（どちらの指標が因でとちらが果か）および時間遅れを考慮していない点で、移動エントロピーとは異なる。

【0047】

指標Ｘ、Ｙそれぞれの時系列データをｘ（ｔ）、ｙ（ｔ）とし、確率密度関数をＰ（ｘ（ｔ））、Ｐ（ｙ（ｔ））とすると、指標Ｘを因、指標Ｙを果とする、遅延時間ｓに関する移動エントロピーＴＥ_ＸＹ（ｓ）は、次式で計算できる。

【数1】

ここで、Ｐ（ａ，ｂ）は、Ｐ（ａ）とＰ（ｂ）の結合確率密度変数を表し、［＊］は＊の時間平均を表す。

【0048】

上式から分かるように、移動エントロピーは、二つの指標Ｘ、Ｙの時系列データと遅延時間ｓを与えることで計算できる。ここで、指標Ｘ、Ｙのあいだに、Ｘを因、Ｙを果とする因果関係が存在する場合には、ＴＥ_ＸＹ（ｓ）の値と、因と果を入れ替えて計算したＴＥ_ＹＸ（ｓ）の値とのあいだに、ＴＥ_ＸＹ（ｓ）＞ＴＥ_ＹＸ（ｓ）が成立する。よって、
ＴＥ_ＸＹ（ｓ）とＴＥ_ＹＸ（ｓ）の値の大小関係を評価することにより、因果関係の存在および因果の方向を判断できる。また、ｓの値を変えながら移動エントロピーＴＥ_ＸＹ（ｓ）を計算することで、原因指標Ｘと結果指標Ｙのあいだの因果強度の最大値、及び、因果強度が最大となる遅延時間ｓを求めることができる。

【0049】

ステップＳ４１の処理において、逆方向の移動エントロピー、すなわち、時間ｓ後の指標Ｅｊから指標Ｅｉへの移動エントロピーＴＥｊｉを計算し、もし逆方向の移動エントロピーの方が大きい場合（ＴＥｊｉ＞ＴＥｉｊ）には、２つの指標（Ｅｉ，Ｅｊ）のあいだには指標Ｅｉが原因、指標Ｅｊが結果となる因果関係はないと判断し、因果強度をゼロにするとよい。

【0050】

原因指標Ｅｉと結果指標Ｅｊのあいだに因果関係が認められた場合（因果強度がゼロでない場合）は（ステップＳ４４；ＹＥＳ）、因果ネットワーク生成部４０は、原因指標Ｅｉと時間ｓ後の結果指標Ｅｊの相関係数を計算する（ステップＳ４５）。相関係数の計算方法は公知のため説明を省略する。

【0051】

以上のステップＳ４３〜Ｓ４５の処理を、ｓの値を時間ステップ幅Δｓずつ増やしながら繰り返し実行し（ステップＳ４６）、遅延時間の最大値ｓｍａｘまで処理を終えたら（ステップＳ４７）、次の指標の組の処理へと移行する（ステップＳ４８；ＮＯ）。そして、２つの指標の全通りの組について因果関係の評価を終えたら（ステップＳ４８；ＹＥＳ）、図３のステップＳ３３へ進む。

【0052】

因果ネットワーク生成部４０は、因果関係データを生成し、因果ネットワーク記憶部４１に格納する（ステップＳ３３）。

【0053】

図７は、因果関係データのデータ構造の一例を模式的に示している。因果関係データは、アプリケーション３又は目的指標を特定するための情報である「対象識別情報」と、ｍ個の指標それぞれがどのデバイスから取得した情報かを特定するための情報である「指標識別情報」と、２つの指標の組ごとの因果関係情報とを含んでいる。対象識別情報には、例えば、アプリケーション３のＩＤ、目的指標のＩＤなどが記述される。指標識別情報には、例えば、各指標に対応するデバイスのＩＤなどが記述される。ただし、指標１は目的指標とし、指標１の指標識別情報にはアプリケーション３のＩＤを記述するものとする。

【0054】

因果関係情報はｍ×ｍの２次元配列で構成されており（図７は、ｍ＝６の例である）、要素番号（ｉ，ｊ）のセルに原因指標ｉと結果指標ｊのあいだの因果関係情報が格納される。要素番号（３，４）の因果関係情報Ａｒｋ（３，４）のデータ記述例を以下に示す。

【0055】

Ａｒｋ（３，４） ＝ ｛
Ｃａｕｓａｌｉｔｙ ＝ ０．５８；
Ｄｅｌａｙ ＝ ３；
Ｃｏ＿ＣｏＥｆ ＝ −０．７
｝

【0056】

Ｃａｕｓａｌｉｔｙは、原因指標ｉと結果指標ｊのあいだの最大の因果強度（移動エントロピー）を表す強度情報であり、Ｄｅｌａｙは、因果強度が最大となる遅延時間を表す時間情報である。Ｃｏ＿ＣｏＥｆは、原因指標ｉの増減に対する結果指標ｊの変化の方向（正の相関か負の相関か）を表す相関情報である。この例では、Ｄｅｌａｙの単位として「時間」を用い、相関情報として、原因指標ｉとＤｅｌａｙ後の結果指標ｊとのあいだの相関係数を用いている。すなわち、上記例の因果関係情報Ａｒｋ（３，４）からは、原因指標３と結果指標４とのあいだには因果関係が存在し、その因果の方向は指標３→指標４
であること、因果強度は０．５８であること、原因指標３の影響が結果指標４に伝播するのに３時間かかる（遅れる）こと、原因指標３と結果指標４とのあいだには負の相関があり、その強さは０．７であることなどが分かる。

【0057】

なお、前述したステップＳ４４において、指標ｉとｊのあいだに因果関係なしと判断された場合には、Ａｒｋ（ｉ，ｊ）にはＮＵＬＬが設定される。また、ｉ＝ｊとなるセルのＡｒｋ（ｉ，ｊ）にもＮＵＬＬが設定される。

【0058】

図８は、図７の因果関係データをもとに、指標間の因果関係を有向グラフで示した因果ネットワークの一例である。この有向グラフにおいて、各ノードが指標に対応しており、指標のＩＤと対応するデバイスのＩＤが各ノードに関連付けられている。２つのノードのあいだをリンクするアークが２つのノードのあいだの因果関係及び因果の方向を示している（アークの基端側が原因ノード、矢印側が結果ノード）。またアークの太さは因果強度を示している。図８の例では、デバイスＡで得られる指標３→デバイスＣで得られる指標６→デバイスＥで得られる指標４→アプリケーション３の目的指標１の順に因果の強い伝播があることがわかる。言い換えると、アプリケーション３の目的指標１の値ないし状態を推測するには、デバイス指標４、デバイス指標６、デバイス指標３が役立つことがわかる。

【0059】

＜データフローの制御＞
図２、図９、図１０を参照して、本実施形態のデータフロー制御装置４によるデータフロー制御について説明する。図９は、デバイス指標の選択処理およびデータフロー制御処理のフローチャートであり、図１０は、因果ネットワークに基づくデバイス指標の選択を模式的に示す図である。

【0060】

図２に示すように、データフロー制御装置４は、データフロー制御に関わる機能として、デバイス指標選択部４２およびデータフロー制御部４３を有している。因果ネットワーク記憶部４１には、アプリケーション３の目的指標について既に生成された因果関係データが格納されているものとする。

【0061】

まず、デバイス指標選択部４２は、アプリケーション３からデータ要求としてのアプリ側メタデータを取得する（ステップＳ９０）。アプリ側メタデータには、例えば、目的指標のＩＤ、希望する利用時間や料金などが含まれている。また、デバイス指標選択部４２は、Ｍ２Ｍクラウドサーバ２のデバイスデータＤＢ２０から、各デバイス１０のデバイス側メタデータを取得する（ステップＳ９１）。デバイス側メタデータには、前述したデバイスに関する情報が記述されている。なお、デバイスネットワーク１を構成するデバイス１０の数が膨大であり、すべてのデバイス１０のメタデータを取得することがデータ容量や計算コストの点から現実的でない場合には、ステップＳ９１において一部のデバイス１０のメタデータのみを取得してもよい。この場合も、例えば、アプリケーション３の制御対象や予測範囲、あるいは位置範囲などに基づいて、関連性のありそうなデバイスを大まかに絞り込み、その絞り込まれたデバイスのメタデータのみをＭ２Ｍクラウドサーバ２から受け取ればよい（デバイスの絞り込みはＭ２Ｍクラウドサーバ２とデータフロー制御装置４のいずれが行ってもよい）。

【0062】

次に、デバイス指標選択部４２は、因果ネットワーク記憶部４１に格納された因果ネットワーク（因果関係データ）に基づいて、目標指標と因果関係を有するデバイス指標を選択する（ステップＳ９２）。本実施形態では、以下のルールにしたがってデバイス指標の候補が選択される。

【0063】

（１）因果ネットワークにおいて、目的指標からの距離が近いデバイス指標を優先する
。なお「距離」は、２つの指標（ノード）のあいだにあるアークの数と定義する。
（２）距離が同じ場合は、因果強度が強い方の指標を優先する（ただし、因果強度が所定の閾値に満たない指標は選択しない）。
（３）距離も因果強度も同じ場合は、遅延時間が短い方の指標を優先する。

【0064】

図１０は、図８の因果ネットワークにおいて、因果強度が閾値よりも大きいという条件を満足する因果関係のみを示す、部分ネットワークである。この図１０に上記ルール（１）〜（３）を適用すると、指標４→指標２→指標６→指標３の順に候補が選ばれる。これにより、目的指標との関係が強いデバイス指標を優先的に選択することができる。

【0065】

デバイス指標選択部４２は、ステップＳ９２で選択された候補指標に対応するデバイスがアクティブか否かを確認する（ステップＳ９３）。デバイスがアクティブか非アクティブかを示す情報については、デバイスから直接得てもよいし（例えば、ｐｉｎｇコマンドなどを用いてデバイスのステイタスを確認する。）、Ｍ２Ｍクラウドサーバ２から得てもよい。デバイスが非アクティブの場合、すなわち、デバイスの停止、故障、移動などにより当該デバイスから現在のデータ（最新のデータ）を取得できない状態の場合は（ステップＳ９３；ＮＯ）、ステップＳ９２に戻り次の候補指標を選択する。デバイスがアクティブの場合、すなわち、当該デバイスから現在のデータを取得可能な状態の場合は（ステップＳ９３；ＹＥＳ）、デバイス指標選択部４２は、メタデータに記述された他の条件（例えば、対価、利用範囲、利用時間など）がアプリケーション３の要求とマッチするかを確認する（ステップＳ９４）。マッチしない条件がある場合には（ステップＳ９４；ＮＯ）、ステップＳ９２に戻り次の候補指標を選択する。以上の処理によって、目的指標と因果関係を有し、且つ、デバイスがアクティブで、且つ、他の条件も満足するデバイス指標が選択される。

【0066】

そして、データフロー制御部４３が、選択されたデバイス指標に対応するデバイス１０を送信元としアプリケーション３を送信先とするデータフロー制御指令を生成し、そのデータフロー制御指令をＭ２Ｍクラウドサーバ２に送信する（ステップＳ９５）。

【0067】

図１０において、「指標６：デバイスＣ」が選択された場合のデータフロー制御の一例を説明する。このときデータフロー制御部４３は、「デバイスＣ」から「アプリケーション３」へのデータフロー制御指令をＭ２Ｍクラウドサーバ２に送信する。データフロー制御指令には、例えば以下の情報が含まれる。
・デバイスＣのＩＤ
・アプリケーション３のＩＤ
・デバイスＣで取得される指標６（原因）→指標４（結果）の因果関係情報Ａｒｋ（６，４）
・指標４（原因）→目的指標１（結果）の因果関係情報Ａｒｋ（４，１）

【0068】

センサ等のデバイスを管理する情報処理装置としてのＭ２Ｍクラウドサーバ２は、データフロー制御部４３から発行（送信）されるデータフロー制御指令（制御指令データストリームとも呼ぶ）を読み取ると、次のデータフロー制御を実行する。Ｍ２Ｍクラウドサーバ２は、因果関係情報Ａｒｋ（６，４）における因果強度、遅延時間、相関係数などのパラメータに基づき、指標６のデータから指標４のデータを予測（推測）する予測関数ｆ_６→４を生成する。また、Ｍ２Ｍクラウドサーバ２は、同じように、指標４のデータから目的指標１のデータを予測（推測）する予測関数ｆ_４→１を生成する。

【0069】

そして、Ｍ２Ｍクラウドサーバ２は、デバイスＣにて取得した最新のデータｄｃから、目的指標１の予測データｄｐを、
ｄｐ＝ｆ_４→１（ｆ_６→４（ｄｃ））
のように計算し、データｄｐをアプリケーション３に送信する。このように、目的指標１との因果関係が強いデバイス指標６のデータｄｃから目的指標１のデータｄｐを求めるため、高い妥当性をもって目的指標１の値を推測することができる。

【0070】

なお、Ｍ２Ｍクラウドサーバ２で予測データｄｐを計算する代わりに、データｄｃと因果関係情報Ａｒｋ（６，４）及びＡｒｋ（４，１）、又は、データｄｃと予測関数ｆ_６→４及びｆ_４→１をアプリケーション３に送信し、アプリケーション３側でデータｄｃから目的指標１の値ｄｐの計算を実行してもよい。

【0071】

以上の構成によれば、アプリケーションの目的（アプリケーションが制御又は予測する指標）を与えると、その目的と因果関係を有するデータが、対応するデバイス１０からアプリケーション３へと自動的に提供される。したがって、デバイスネットワーク１内にどのようなデバイスが存在しどのようなデータが取得できるかとか、目的とする制御や予測を行うためにどのようなデータを参照すべきか、といった知識がなくても、アプリケーション３の設計・開発が可能となる。よって、従来に比べて、デバイスネットワーク１におけるデータを利用するアプリケーション３の設計・開発が容易となり、デバイスネットワーク１におけるデータの利用・流通が促進される。

【0072】

また、故障、停止、移動など、何らかの原因によって非アクティブな状態（データを取得できない状態）となっているデバイスが選択の対象から除外される。したがって、現在アクティブなデバイスのなかから、適切なデバイス（アプリケーション３の目的指標と因果関係を有するデータを取得可能なデバイス）を自動で選択でき、システムのロバスト性を高めることができる。

【0073】

＜アプリケーションによるデバイスの制御＞
上記実施形態では、アプリケーション３へ提供するデバイス指標を選択するために因果ネットワークを利用したが、さらに進んで、アプリケーション３が目的指標の値を積極的に調整するために因果ネットワークを利用することも可能である。

【0074】

図１１の例のように、目的指標１に影響を与え得る指標として、デバイス指標２，４，６，３が選ばれているとする。これらのデバイス指標に対応するデバイスＤ，Ｅ，Ｃ，Ａのなかにアクチュエータが存在する場合には、アプリケーション３から当該アクチュエータに対してデバイス制御命令を送ることで、目的指標１の値を調整（増加又は減少）させることが可能である。

【0075】

例えば、図１１において、
・デバイスＣがエアコン、指標６がエアコンの温度設定値
・デバイスＥが室内温度センサ、指標４がオフィス内の温度
・目的指標１がオフィスの生産性
と想定した場合、アプリケーション３が目的指標１（オフィスの生産性）の値を目標値に近づけるために、デバイスＣ（エアコン）の指標６（温度設定値）を変更するデバイス制御命令を送信し、オフィス内の温度を変更する、というシステムが構築できる。なお、デバイス制御命令は、アプリケーション３からデバイスＣへ直接送信してもよいし、Ｍ２Ｍクラウドサーバ２を仲介してもよい。

【0076】

このように、因果ネットワークを用いることにより、目的指標の値に影響を及ぼし得るアクチュエータを容易に特定することができる。またアプリケーション３によるデバイス制御を可能にしたことで、アプリケーション３による目的指標の積極的な調整が可能となり、アプリケーション開発の自由度が高まる。

【0077】

＜その他の実施形態＞
上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。

【0078】

例えば、上記実施形態では、因果ネットワークの例として数個の指標（デバイス）のみを図示したが、実際には数十から数百、あるいはそれ以上の指標（デバイス）の因果ネットワークを形成することも可能である。また上記実施形態では、デバイスの例としてセンサとアクチュエータを示したが、実デバイスだけでなく、仮想的なデバイス（例えば複数のセンサで得られたセンシングデータを組み合わせて１つのセンシングデータを出力するようにしたモジュールなど）を用いることもできる。また上記実施形態では、デバイス制御の例としてアクチュエータを制御する例を示したが、センサを制御（例えば、カメラのパン・チルト・ズームの調整、測定のサンプリング周期の変更など）することもできる。

【符号の説明】

【0079】

１：デバイスネットワーク
１０：デバイス
２：Ｍ２Ｍクラウドサーバ
２０：デバイスデータＤＢ
３：アプリケーション
４：データフロー制御装置
４０：因果ネットワーク生成部
４１：因果ネットワーク記憶部
４２：デバイス指標選択部
４３：データフロー制御部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】