JPWO2014041826A1 - データフロー制御指令発生装置およびセンサ管理装置 - Google Patents

Abstract

センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得手段と、センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、センサ側メタデータおよびアプリ側メタデータのマッチングを行うことでアプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出するマッチング手段と、センサを管理するセンサ管理装置に対して、マッチング手段により抽出されたセンサとアプリケーションとを特定したデータフロー制御指令を送信する指示手段を有するデータフロー制御指令発生装置を用いる。

Description

本発明は、センシングデータを利用するセンサネットワークに関するものであり、特にデータフロー制御指令発生装置、センサ管理装置、データフロー制御指令発生プログラムおよび制御指令データストリームに関する。

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

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

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

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

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

特開２００７−３００５７１号公報 特開２０００−３３１２８４号公報

そこで、上記のようなセンサネットワークを形成することにより、様々な企業や団体が、世界中で大量に収集されたセンシングデータを、自己の目的に応じて利用可能とすることが必要である。
出願人らはさらに、センサネットワークの発展について鋭意検討している。例えば、ビッグデータを処理可能なアプリケーションサーバ上でデータを加工して付加価値を生み出し、提供することや、センシングデータの取引を活発化させて経済効果をもたらすことである。例えばセンサの所有者は、データ利用者に対してセンサの一時利用を許可したりセンシングデータを提供したりすることで対価を得られる。また利用者にとっては、センサを設置する投資が不要なため安価に必要なデータを得ることができるメリットがある。

上記のような、出願人らの検討に係るセンサネットワークは、さまざまな個所に設置された機械（に搭載されたセンサデバイス）が取得したデータを集中的に管理して利用可能とする点で、Ｍ２Ｍクラウドを具体的に実現する一形態とも言える。Ｍ２Ｍクラウドを基盤とするセンサネットワークが実現すれば、データ種別や取得位置、時間などが多様なデータを、何処からでも適切な形で把握し役立てることが可能となる。そのため、製造現場や物流などの産業分野から、セキュリティや医療、教育などの生活分野、そしてスマートグリッドや交通制御システムなどの社会インフラ分野まで、幅広い応用が期待されている。

また、ＩｏＴにおいては、時間、空間、人、物、情報、エネルギーなどの資源を様々な粒度で最適化するためのシステムを形成する。最適化するということは、資源を、必要性が低い部分から高い部分に移転したり、価値が高い形態で使用したりすることであり、資源の移転や使用権の設定、対価の支払いなどの取引が行われる。しかし従来、センシングデータなど流通させる仕組みは整備されていなかった。

本発明は上記の課題に鑑みてなされたものであり。その目的は、多くの物がネットワーク上に接続されたシステムにおいて、センシングデータなどの資源を適切に流通させる仕組みを提供することにある。

上記目的を達成するために、本発明では、センサネットワークにおいてデータフロー制御を行うことでセンシングデータの流通を適正化する構成を採用する。そこで本発明は、次のような第一の態様を取ることができる。すなわち、センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得手段と、前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、前記センサ側メタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを提供可能な前記センサを抽出するマッチング手段と、前記センサを管理するセンサ管理装置に対して、前記マッチング手段により抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を送信する指示手段と、を有することを特徴とするデータフロー制御指令発生装置である。

この構成によれば、アプリ側メタデータとセンサ側メタデータとの間でマッチングが行われ、センシングデータを必要とするアプリケーションと、そのデータを提供可能なセンサとが対応付けられる。そして、センサを管理する装置に対してデータフロー制御指令が送信される。これにより、種々の条件を加味した上でのセンシングデータの流通が促されサービスが向上するうえに、データの提供者と利用者双方にとって利益となる。ここでは、メタデータとはサーバによる検索やマッチングに用いる情報を言い、センサ側メタデータはセンサおよび当該センサにより得られるセンシングデータの属性に関する情報を、アプリ側メタデータはアプリケーション自身および当該アプリケーションが必要とするセンシングデータの属性に関する情報を指す。またデータフロー制御指令とは、データ提供元であるセンサと、データ利用先であるアプリケーションとを特定する情報を含み、データ提供元からデータ利用先にデータを流通させることを指令する指令情報である。データフロー制御指令によるセンサ管理装置への指示内容において、ある１つのセンサのセンシングデータを複数のアプリケーションに流通させるように指示することが可能である。また、複数のセンサのそれぞれから、センシングデータを１つのアプリケーションへ流通するように指示することもできる。さらに、複数のセンサのそれぞれからのセンシングデータを、複数のアプリケーションに流通させるように指令することもできる。

また、第一の態様において、センサ側メタデータ取得手段、アプリ側メタデータ取得手段は様々な構成を取り得る。例えば、これらのメタデータを予めデータフロー制御指令発生装置からアクセス可能なＤＢに格納しておく方法がある。この場合、マッチング処理に必要なメタデータは既にＤＢにあるため、データフロー制御指令が発せられるトリガとして、センサ側またはアプリ側からのイベント通知を行えば良い。さらに、データフロー制御指令発生装置において、センサ側メタデータＤＢまたはアプリ側メタデータＤＢのいずれかが存在しない構成も取り得る。この場合、イベント発生を検知したセンサの管理装置またはアプリケーションからメタデータが送信される。

本発明は、次のような第二の態様を取ることができる。すなわち、センサにより得られ、ネットワーク上のデータベースに格納されたセンシングデータに関する情報であるセンシングデータのメタデータを取得するセンシングデータのメタデータ取得手段と、前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、前記センシングデータのメタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを抽出するマッチング手段と、前記ネットワーク上のデータベースに対して、前記マッチング手段により抽出された前記センシングデータと前記アプリケーションとを特定したデータフロー制御指令を送信する指示手段と、を有することを特徴とするデータフロー制御指令発生装置である。

この構成によれば、実際のセンサの有無に関わらず、ＤＢ内にセンシングデータが存在すれば、データを必要とするアプリケーションとの間でデータマッチングが行われ、データフロー制御指令が送信される。これにより、データ流通の促進や、データの提供者および利用者の利益が図られる。

本発明は、次のような第三の態様を取ることができる。すなわち、センシングデータを出力するセンサに関する情報であるセンサ側メタデータを用いて前記センサを管理するセンサ管理装置であって、前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータと前記センサ側メタデータとのマッチングにより前記アプリケーションの要求を満たすものとして抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を受信する指令受信手段と、前記抽出されたセンサからのセンシングデータを、ネットワークを介して所定のパケット方式により前記アプリケーションに送信する送信手段と、を有することを特徴とするセンサ管理装置である。

この構成によれば、センサ管理装置の側でセンシングデータの提供をする際の煩雑さが減少し、センシングデータの流通が促進される。すなわち、センサ管理装置はマッチングの結果に基づく制御指令を受信し、それに従ってデータ送信を制御すれば良い。その結果、利用対価等が判定され、センサの所有者が適正な利益を得られる。
なお、この構成においては、送信手段がイベント発生をデータフロー制御指令発生装置に通知する構成を取ることもできるし、送信手段がイベント発生とともにセンサ側メタデータを送信する構成を取ることもできる。

本発明は、次のような第四の態様を取ることができる。すなわち、センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得ステップと、前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、前記センサ側メタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを提供可能な前記センサを抽出するマッチングステップと、前記センサを管理するセンサ管理装置に対して、前記マッチングステップにおいて抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を送信する指示ステップと、を情報処理装置に実行させることを特徴とするデータフロー制御指令発生プログラムである。

本発明は、次のような第五の態様を取ることができる。すなわち、センシングデータを出力するセンサに関する情報であるセンサ側メタデータを用いて前記センサを管理するセンサ管理装置の情報処理装置において動作するプログラムであって、前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータと前記センサ側メタデータとのマッチングにより前記アプリケーションの要求を満たすものとして抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を受信する指令受信ステップと、前記抽出されたセンサからのセンシングデータを、ネットワークを介して所定のパケット方式により前記アプリケーションに送信する送信ステップと、を前記情報処理装置に実行させることを特徴とするプログラムである。

これら第四または第五の構成によっても、メタデータの比較結果に基づき作成されたデータフロー制御指令を用いてセンシングデータのアプリケーションへの提供を制御することで、データ流通の適正化が図られ、サービス向上と、データ提供者および利用者に利益がもたらされる。

本発明は、次のような第六の態様を取ることができる。すなわち、センシングデータを出力するセンサを管理する情報処理装置が読み取り可能なデータストリームであって、前記センシングデータを必要とするアプリケーションを特定する情報と、前記アプリケーションの要求を満たすものとして抽出されたセンサを特定する情報と、前記抽出されたセンサと前記アプリケーションとを特定した指令情報と、を含むことを特徴とする制御指令データストリームである。

また第六の態様において、アプリケーションを特定する情報およびセンサを特定する情報を、センサに関する情報であるセンサ側メタデータと、アプリケーションに関する情報であるアプリ側メタデータのマッチングにより得られたものとすることができる。
このように、メタデータのマッチング等の結果に基づき作成された制御指令データストリームを用いれば、センシングデータを管理する情報処理装置がデータの適正な流通に寄与することが可能になる。

なお、本発明は、上記の通りデータフロー制御指令発生装置またはセンサ管理装置と考えることもできるし、これらを総合したシステムや、これらにセンサやアプリケーションサーバを含めたシステムとして捉えることもできる。また、本発明は、上記各装置の少なくともいずれかにおける処理を含む方法として考えることもできるし、この方法を実現するためのデータストリーム、この方法の各ステップをコンピュータに実行させるためのプログラム、あるいはプログラムを記録した記憶媒体として捉えることもできる。

本発明によれば、多くの物がネットワーク上に接続されたシステムにおいて、センシングデータなどの資源を適切に流通させる仕組みを提供できる。

図１は、交通制御システムの全体的な構成を示す図である。 図２Ａは、車両の隊列形成に関する処理全体の流れを示すフローチャートである。 図２Ｂは、車両の隊列形成における初期処理を示すフローチャートである。 図２Ｃは、車両の隊列形成支援を開始するときの処理を示すフローチャートである。 図２Ｄは、車両の隊列走行を維持する間の処理を示すフローチャートである。 図２Ｅは、車両が単独走行に移行するときの処理を示すフローチャートである。 サーバ側における隊列形成支援アプリケーションの構成および処理を模式的に示す図である。 サーバ側における隊列形成支援アプリケーションの隊列走行オブジェクトの状態遷移図である。 隊列走行時の信号機における制御を説明するための模式図である。 図６Ａは、センサ側イベント駆動型アクセスモードによるデータフロー制御を説明する図である。図６Ｂは、制御で用いられるデータ構造を示す図である。 センサ側イベント駆動型アクセスモードによるデータフロー制御を説明するフローチャートである。 図８Ａは、アプリ側イベント駆動型アクセスモードによるデータフロー制御を説明する図である。図８Ｂは、制御で用いられるデータ構造を示す図である。 図９Ａは、センサ側メタデータ駆動型アクセスモードによるデータフロー制御を説明する図である。図９Ｂは、制御で用いられるデータ構造を示す図である。 図１０Ａは、アプリ側メタデータ駆動型アクセスモードによるデータフロー制御を説明する図である。図１０Ｂは、制御で用いられるデータ構造を示す図である。 図１１Ａは、仮想センサおよびセンシングデータを記憶したＤＢによるデータフロー制御を説明する図である。図１１Ｂは、制御で用いられるデータ構造を示す図である。 図１２Ａは、センサ、センシングデータで用いるメタデータのデータ構造を示す図である。図１２Ｂは、アプリで用いるメタデータのデータ構造を示す図である。

［実施形態１］
以下に図面を参照しつつ、本発明の好適な実施の形態を説明する。ただし、以下に記載されている各構成の説明は、発明が適用されるシステムの構成や各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。

上述したように、Ｍ２Ｍクラウドを基盤とするセンサネットワークが実現すれば、多様なデータを、何処からでも適切な形で把握し役立てることが可能となるため、幅広い応用が期待されている。
とりわけ、交通制御システムにおいては、各車両や信号機、各所に設置されたカメラなど、関係するセンサデバイスが多種多様に存在するので、センシングデータを処理してスムーズな交通を実現することへの要望が強い。

ここで、従来の交通制御システムにおける問題点、特に交通渋滞について検討する。交通渋滞は時間のロスや燃料の浪費により社会生産性を低下させるとともに、事故の発生や周辺環境の悪化などを引き起こす。
一般道路において、渋滞の最大の原因は、信号機がボトルネックとなって交通量が減少することである。従って、赤信号／青信号の変更タイミングや点灯時間の制御は、交通制御システムが行う制御動作の中でも、交通をスムーズにするために重要である。特に交差点における信号機は複数の交通の流れに関わるため重要度が高い。

一般道路では各車両が個別の目的地を持っており、運転者の運転技術や速度順守の意識にも個人差があるため、速度や進行方向は車両ごとにバラバラとなる。その結果、例えば各車両が右折や左折のために交差点で停止したり、車線変更をしたり、速度を変化させたりして、後続車両の通行を妨げて流れを滞らせ、渋滞を引き起こす。

我が国では通常、信号機の制御は警察の管理の下で行われ、交通量の多い道路では、信号機ごとに予め定められた制御パターンの中から曜日や時間帯に応じたものが選択される。道路上での交通量を可及的に大きくするためには、なるべく多くの車両（あるいは、車両に乗車した人数）が通過できるように青信号の変更タイミングや点灯時間を制御することが必要である。その際に、実際の交通状況に応じて柔軟に信号の制御パターンを変更できれば、交通をスムーズにすることに寄与すると考えられる。

バスや緊急車両などの公共車両については、既に公共車両優先システム（ＰＴＰＳ：Ｐｕｂｌｉｃ Ｔｒａｎｓｐｏｒｔａｔｉｏｎ Ｐｒｉｏｒｉｔｙ Ｓｙｓｔｅｍ）と呼ばれる施策が、主にバスレーンとの組合せで導入されている。これは、バスの存在を信号機で検知すると青信号の時間を延長する技術であり、バス運行の定時性を確保して乗客を満足させることにより、公共交通の利用を促進している。その結果として、バスによる大人数の輸送と車両数の減少を目指している。他にも消防車、救急車等の緊急車両を優先する仕組みが考えられているが、一般車両にこのような仕組みは無い。

一方、様々な観点から、複数の車両が隊列を組んで道路を走ることのメリットが検討されている。まず、隊列走行による省エネルギー化が期待される。これは、隊列を組むと、走行風などの空気の流れに対して下流側の車両が上流側の車両の陰に入ることにより、受ける風圧が小さくなることによる。その結果、各車両の燃費を向上させることができる。

特許文献２には、複数のメンバーが複数の車両でグループを形成するときの技術が記載されている。この場合、ある車両の運転者に、グループに属する他の車両の位置を通知するために、車両に備えたＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）装置により各車両が自車の位置を取得し、携帯電話等を用いて他の車両に送信する。この情報を受信すると、グループに属する車の位置をカーナビゲーション装置の地図上で表示する。

特許文献２の場合、グループのメンバーは、例えば会社や趣味の仲間など、隊列走行を予定する同士である。交通システム側からみると、各車両がバラバラに移動される場合よりも渋滞が抑制できると考えられる。
このように、目的地（走行経路上の中間目的地を含む）あるいは経路と、走行時間帯とを同じくする複数の車両が隊列を組んで走行することは、運転者にとっても、交通の観点からも有益である。

しかし、車両が隊列走行を行うに当たっては、グループを作って隊列を組むまでの問題と、隊列走行中に起こる問題がある。前者は、予め運転者同士が知り合い、目的地あるいは経路や、走行時間帯を合わせておかなければ、隊列を組めないという問題である。後者としては、車両数が増えると、集団を見失う車両が現れるという問題がある。後者としてはまた、隊列の長さによっては、信号機を通過する途中で青信号から赤信号への切り替え時間が来てしまい、一部の車両が一緒に移動できなくなる問題もある。

このような問題点に対処し、隊列走行によるメリットを社会全体で享受するために、車両同士が自発的に隊列を組んで目的地まで走ることに任せるだけではなく、交通制御システムが積極的にグループ形成に関与し、車両を誘導するとともに、走行中の障害を除去することが求められている。

さらに、隊列走行の他にも、道路上を走行する車両間の位置関係は重要である。例えば、他の車両と所定以上の距離を開ける必要がある場合や、逆に他の車両と所定範囲内を走行したい場合もある。このような走行を可能にすることも求められている。

このような実情をふまえ、本実施形態の技術では、センサネットワークを用いることにより、交通制御システムにおいて、車両間の位置関係を形成することを支援し、スムーズな走行を可能とする。

＜システムの全体構成＞
図１のブロック図を参照して、本発明に係る交通制御システムの全体的な構成を説明する。本実施形態における車両位置関係形成支援制御は、信号機の通過に当たり優遇処理を可能とするような車両隊列の形成支援である。ただし制御の内容はこれに限られず、詳細は後述するが、車両と他の車両の位置関係が所定条件を満たすようにするための支援制御が含まれる。

交通制御システム１は、車両２と、運転者等が所持して車両２に設置される携帯通信端末であるスマートフォン３と、スマートフォン３が通信する携帯端末用のネットワーク４と、クラウド環境を提供するＭ２Ｍクラウドサーバ５と、センサネットワークに関するサービスを行うセンサネットワークサーバ６と、アプリケーションサーバ７と、信号管理システム８と、信号機９と、から構成されている。上記各ブロックの構成は任意に設計でき、特に限定されない。またネットワーク４の構成やブロック間の通信方式などにも特に限定はない。以下、交通制御システム１の各ブロックの構成と機能についてさらに詳細に説明する。

（車両２）
車両２は、運転者の操作に従って、出発地から目的地まで走行する。図中では車両２ａ〜車両２ｄの四台がグループを形成し、隊列２０Ａを組んで道路上を走行している様子を示す。

（スマートフォン３）
スマートフォン３は、運転者や同乗者によって車両２に設置される携帯通信端末である。ＣＰＵなどの情報処理装置を搭載し、アプリケーションをインストールして利用できる。また、現在位置を取得するＧＰＳ機能を持つ。さらに加速度センサにより車両２の移動速度を取得できることが好ましい。また、運転者からの入力を受け付ける手段と、運転者に情報を出力する手段を有する。前者の入力手段としては、タッチパネル、物理ボタンあるいは仮想ボタン、もしくは音声入力機能がある。後者の出力手段としては、タッチパネルに表示部を兼ねさせたり、音声で出力したりできる。さらに本実施形態においては、端末を、ひいては車両を特定するために、固有のＩＤ情報（Ｓ＿ＩＤ）を内部のメモリに格納している。

スマートフォン３は、ネットワーク４を介してＭ２Ｍクラウドサーバ５と通信可能であり、さらにＭ２Ｍクラウドサーバ５を経由してセンサネットワークサーバ６の情報にアクセスできる。また、アプリケーションサーバ７の演算資源を利用するクライアントとしても振る舞う。逆にこれらのサーバは、ネットワーク４を介して車両２から情報を取得する。本発明の移動計画情報送信手段や指令情報受信手段は、スマートフォン３の通信機能に対応している。

（車両用アプリ３１）
車両用アプリ３１はスマートフォン３にインストールされる。アプリケーションサーバ側の隊列処理アプリ７１と対応し、その指令情報をネットワーク４経由で取得する。車両用アプリ３１は、カーナビゲーションアプリを兼ねるか、共同して動作することが好ましい。このようなアプリの指示に従ってＣＰＵが制御を行うことにより、スマートフォン３は本発明の移動支援端末装置として機能する。

（クレードル３２）
スマートフォン３を車両２に固定するために、クレードル３２を使用できる。クレードル３２に設置されたときに車両用アプリ３１が起動するようにすれば操作を簡略化できる。あるいは運転者がスマートフォン３上のアイコンをタッチして起動しても良い。

なお本実施形態においては、車両用アプリ３１をインストールされ、センサデバイスとしても機能するスマートフォン３を用いているが、これらの機能を持ちネットワーク４と情報の送受信が可能な装置群を総称して本発明の移動支援端末装置としても良い。例えばカーナビゲーション装置には、音声等で運転操作を指示する機能、ＧＰＳ等により現在位置を取得する機能、目的地を入力されると走行経路や時間帯を提示する機能を有しているものがあるので、このような装置を本発明に転用できる。また、通信機能として車両の無線通信設備を利用できるし、ＧＰＳ機能や表示装置、入力手段についても、車両の設備を利用できる。

（ネットワーク４）
ネットワーク４は、スマートフォン３の通信の基盤となるものであり、通信会社等により構築された既存の通信網を利用できる。またネットワーク４は単一のネットワークとは限らず、様々な通信方式やトポロジーを持つ複数のネットワークを接続した概念的なものと考えても良い。要するに、車両側とサーバ側で情報を送受信可能にする通信網であれば構わない。

（Ｍ２Ｍクラウドサーバ５）
Ｍ２Ｍクラウドサーバ５は、本発明の交通制御システムの全体的な管理を担う。ハードウェア的には、情報処理装置（ＣＰＵ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備えるコンピュータにより構成できる。様々な場所に存在するセンサデバイスからネットワーク経由でアクセスを受け、大量のデータを送受信して蓄積し、アプリケーションからの求めに応じて提供するのに足りるだけの性能を有する。

（センサネットワークサーバ６）
センサネットワークサーバ６は、センサネットワークに係るセンサデバイスの管理等を行うサーバ装置である。センサネットワークサーバ６もＭ２Ｍクラウドサーバと同様のコンピュータにより構成できる。

ここでセンサネットワークについて簡単に説明する。センサネットワークはセンシング機能と通信機能をもつセンサデバイスをネットワーク化し、センシングデータの収集や利用を可能とするものだが、本発明者では、センサの所有者が、企業等のデータ利用希望者に対してセンシングデータを提供して対価を得る仕組みを想定している。これにより、所有者にとっては収益の機会、利用者にとっての安価なデータ取得というメリットが得られる。センサネットワークサーバ６はこのような取引の仲介を行うサーバ装置であり、本発明でのセンサデバイスはスマートフォン３である。

（データ提供契約ＤＢ６１，データ利用契約ＤＢ６２）
センサネットワークサーバ６（センサ管理装置）は、所有者からの登録に応じて、データ提供契約ＤＢ６１に所有者およびセンサデバイスに関する情報を格納する。センサデバイスに関する情報として、センサの種類、位置、対応するアプリケーションなどがある。また所有者に関する情報として、利用可能期間、データの使用目的（学術目的のみ使用可など）、使用範囲（非営利のみ使用可など）、対価などがある。これらの情報は、各センサデバイス（ここではスマートフォン３）のＩＤ情報（Ｓ＿ＩＤ）に紐付けられた形で保持しており、Ｍ２Ｍクラウドサーバ５からの要求に応じて読み出される。これはデバイス情報格納手段に対応する。
また、センサネットワークサーバ６は、利用者からの登録に応じて、データ利用契約ＤＢ６２にデータ利用に関する情報を格納する。この情報には、アプリケーションが求める条件、あるいはデータを直接必要とする利用者側の条件が含まれる。例えば、データの種類、取得場所、データ取得周期や精度、支払う対価の上限などがある。
センサネットワークサーバ６はこれらのデータベースを参照して利用者の条件とセンサをマッチングするとともに、利用実績に応じた利用者からの料金徴収と所有者への対価支払を管理する。本実施形態ではＩＤ情報（Ｓ＿ＩＤ）ごとに利用して良いアプリケーション番号（Ａ１，Ａ２，・・・ＡＮ）が格納されている。これは利用条件格納手段に対応する。

（アプリケーションサーバ７）
アプリケーションサーバ７は、センシングデータを用いる各種アプリケーションをインストールされ、要求に応じた演算処理を行って結果を返却するサーバ装置である。アプリケーションサーバ７もコンピュータにより構成できる。

（各種アプリケーション）
以下にアプリケーションの例を挙げて説明する。隊列処理アプリ７１は本発明の中心的な処理を行うアプリケーションであり、各車両の位置や移動計画（走行経路、各道路区間の走行時間帯など）に基づいて適切な車両グループを抽出して隊列形成を指示する。また、信号機において隊列を優先的に通過させるように信号管理装置８に対して指示を出す。
その他は、アプリケーションの例として記載した。渋滞マップアプリ７２は、スマートフォン３から位置情報や移動速度等を収集して、各車両からの情報を集計して渋滞マップを生成し、道路の状況を利用する事業者等に販売する。映像配信アプリ７Ｎは、スマートフォン３や車載カメラなどのセンサデバイスから走行中に撮影した画像や動画を収集し、各地点の状況を知りたい利用者に提供する。撮影映像は他にも、道路の傷を探知するアプリケーションや、違法駐車を検出するアプリケーションにも利用できる。
このように、センサネットワークの利用者は、個々のセンシングデータを直接購入するだけでなく、アプリケーションを指定して処理を要求することで、個々のセンサデバイスを意識すること無く必要な情報を得られる。

なお、以上の説明ではＭ２Ｍクラウドサーバ５、センサネットワークサーバ６およびアプリケーションサーバ７を別個のブロックとしている。しかし実際の物理的な配置は、構築費用、要求される性能、ネットワーク条件あるいはリスク分散等を考慮した上で自由に構成することができる。例えば単一の装置の各モジュールとして構成してもよいし、複数のコンピュータを協働させて用いてもよい。要するに、様々な場所のセンサデバイスとの情報の送受信と、大量のデータをアプリケーションにより処理することが可能なサーバを用いれば、本発明を実現することができる。センサデバイスたる車両側の移動支援端末装置（スマートフォン）と対比する意味で、上記各サーバを「サーバ側」と総称する。本発明の移動計画情報受信手段や指令情報送信手段は、サーバ側のいずれかの通信機能を利用している。さらにグループ抽出手段や指令情報生成手段は、サーバ側のいずれかの情報処理装置を利用している。サーバ側をまとめて、本発明の車両位置関係形成支援装置として捉えることもできる。

（信号管理装置８，信号機９）
信号管理装置８は、道路上における信号機９の赤青の点灯、消灯を制御する。通常は、信号機ごとに所与のパターンから曜日や時間帯に応じたものを選択して制御を行う。ただし、実際の交通状況に応じて柔軟に点灯状態を制御することも可能であり、隊列処理アプリ７１の指示が合った場合は優先的に通過させる処理を実行する。図では、隊列２０Ａが信号機９の下を通過しようとしている。

＜車両側処理フロー＞
図２Ａ〜図２Ｅのフローチャートを参照しつつ、本実施形態における隊列形成と優遇走行を具体的に記載する。

図２Ａは、車両の隊列形成に関するスマートフォン３での処理の概要を示すフローチャートである。本フローは車両２のエンジンが始動し、移動を開始しようとする時点から始まる。

（初期処理）
ステップＳ１０１において、初期処理が行われる。初期処理の詳細を図２Ｂのフローに示す。
図２ＢのステップＳ１０１１において、スマートフォン３の車両用アプリ３１が起動される。車両２のダッシュボードに設置されたクレードル３２に接続すると自動的に起動するようにしても良く、電源供給の点で好適である。また運転者（同乗者でも良い。以下同様とする）がアイコンから起動しても良い。上述したように車両用アプリはカーナビゲーションアプリを兼ねているので、運転者はナビゲーションを受けるために進んで本アプリを起動する。
ステップＳ１０１２において、車両用アプリ３１は、スマートフォン３のＧＰＳ機能を利用してＧＰＳ衛星と通信を行い、車両２の現在位置を取得する。
ステップＳ１０１３において、車両用アプリ３１は、運転者から入力手段を用いた目的地入力を受け付ける。運転者は目的地を入力し、カーナビによるルート案内を要求する。
ステップＳ１０１４において、車両用アプリ３１は、移動計画を作成する。カーナビゲーション機能により作成される移動計画は、現在位置と目的地を結ぶ走行経路と到着時間の目安を含む。さらに本実施形態では、走行経路を適切な規模で区切った各区間について走行予定の時間帯を決定する。これは走行経路の少なくとも一部が他の車両と一致していれば隊列を組めるようにするためである。経路の区切り方は任意であり、例えば中間地点と通過予定時刻の組を生成しても良いし、全経路を交差点等を目安に複数の区間に分けて、各区間の走行予定時間帯を計算しても良い。
上記各ステップによって作成された情報（位置、目的地）は移動計画（Ｓ＿ＤＡＴＡ）とも呼ばれ、移動計画を生成する機能は移動計画生成手段とも呼ばれる。またＧＰＳ機能など、車両に関する情報を取得する各機能をまとめて車両情報取得手段とも呼ぶ。

図２Ａのフローに戻り、ステップＳ１０２において、車両用アプリ３１は、運転者に隊列走行を希望するかどうかをスマートフォン３の出力手段により確認する。希望しない場合（Ｓ１０２＝Ｎ）、運転者は通常のカーナビゲーション機能に従って目的地を目指すので、本フローは終了する。なお、本ステップを省略して、常に隊列走行を行うようにしても構わない。

（隊列形成支援処理）
ステップＳ１０３において、隊列形成支援処理が行われる。本処理の詳細を図２Ｃのフローに示す。
図２ＣのステップＳ１０３１において、車両用アプリ３１は、移動計画（Ｓ＿ＤＡＴＡ）と、スマートフォン３のＩＤ情報（Ｓ＿ＩＤ）をＭ２Ｍクラウドサーバ５に送信する。さらに「スマートフォン３がクレードル３２に接続中である」という情報を送信しても良い。これは、スマートフォン３が車両に設置されているかどうかをサーバ側が判定可能とするためである。なお、ステップＳ１０２で隊列走行を「希望しない」としていた場合でも、移動計画とＩＤ情報を送信しても良い。このような車両は隊列走行には影響しないものの、センサネットワークへのセンシングデータ提供という点では有効である。
ステップＳ１０３２において、車両用アプリ３１は、加速度センサ等により車両が走行を開始したことを検知する。
ステップＳ１０３３において、車両用アプリ３１は、車両２の現在位置と速度を取得して送信する。この処理は必須ではないが、サーバ側で隊列形成の指令を的確に行うために好ましい。
ステップＳ１０３４において、車両用アプリ３１は、隊列処理アプリ７１から隊列加入の指令が来ているかどうかをネットワーク４経由で問い合わせる。指令がなければ（Ｓ１０３４＝Ｎ）、前ステップに戻り、所定時間をおいて問い合わせを繰り返す。
指令（ＮＡＶＩ＿ＭＳＧ）があれば（Ｓ１０３４＝Ｙ）、ステップＳ１０３５に進み、運転者に対し隊列への加入を促すメッセージを出力する。走行中であれば音声出力が望ましい。運転者が本ステップの指令に従って運転操作を行うことにより、隊列が形成される。いったん隊列に加入すれば、車両を追尾するか、ナビゲーションに従って運転を続ける。車両２が隊列の最初の一台である場合は、ナビゲーションに従って運転する間に後続車両が参加する。

（隊列加入時の運転操作方法）
車両２が既存の隊列に加入する場合、隊列に含まれる車両を見分け、他の車両と混ざらないように隊列を形成するための指令を出すことになる。その際車両の特定方法は限定されず、例えば「５秒後にあなたの右を通過する車両を追尾して下さい」といったように時間で特定し音声出力する方法でも良い。また車種や色、サイズ等の外見的特徴を伝えることが好ましい。また、既に隊列中にいる車両のハザードランプを制御して、点滅パターンで伝達しても良い。あるいはセンサネットワークに加入している車両に対してＬＥＤ等を用いた専用の表示器を配布しておき、その点灯により特定しても良い。
隊列への加入が完了したことは、車両側からサーバ側へ通知される。あるいはサーバ側で、各車両がＧＰＳで取得した位置情報を比較して、一定の距離内にあれば加入完了としても良い。
なお、運転技術には個人差があるため、隊列への加入に失敗した場合には走行経路の再計算や、再度加入する機会を通知するなどのフォローを行うことが好ましい。
また、隊列に参加できる車両台数に上限を設けることも考えられる。隊列が長すぎると他の車両等への影響が大きくなり過ぎるためである。

（隊列走行維持処理）
図２Ａのフローに戻り、ステップＳ１０４において、隊列走行維持処理が行われる。本処理の詳細を図２Ｄのフローに示す。
図２ＤのステップＳ１０４１において、車両用アプリ３１は、車両２の現在位置、速度を取得してサーバ側に送信する。この情報を受けた隊列処理アプリ７１は、隊列が交通状況を反映した適切な走行を行えるように、車両２に指令情報を送信する。
そこで車両用アプリ３１は、ステップＳ１０４２において変更指令があるかを問い合わせ、もしあれば（Ｓ１０４２＝Ｙ）受信してステップＳ１０４３に進み、運転者に出力する。変更情報としては、例えば交通法規を順守するための指示や、新たな車両の加入を受け入れるための運転指示が考えられる。また通常のカーナビゲーション機能による指令、例えば渋滞や交通規制に応じた運転変更指示も同時に行う。本発明のように信号機において優遇処理を受けられるのは、隊列走行を維持している途中である。

（隊列離脱または隊列継続に関する処理）
図２Ａのフローに戻り、ステップＳ１０５において、車両用アプリ３１は、隊列離脱トリガがあるかどうかを検出する。隊列離脱トリガは、車両内からまたは外部からの、隊列離脱を示すイベントである。例えば、車両内からのイベントには、運転者からの明示あるいは黙示の離脱要求がある。明示の要求とは、運転者が音声で離脱の意思表示をするか、同乗者がタッチパネルで離脱操作をした場合である。黙示の要求とは、カーナビゲーションアプリの目的地が変更された場合や、指示されたルートから外れるような運転操作が行われた場合である。また外部からのイベントには、共通の経路を外れる場合や、何らかの理由で隊列のメンバーとして相応しくないと判断された場合の指令情報がある。トリガを検出すると（Ｓ１０５＝Ｙ）、ステップＳ１０６に移行する。

ステップＳ１０６の詳細を図２Ｅのフローに示す。
図２ＥのステップＳ１０６１において、車両用アプリ３１は、移行のための情報を出力する。通常のナビゲーションと同様の指示方法でも構わない。
ステップＳ１０６２において、運転者は、隊列離脱のための運転操作を実行する。
ステップＳ１０６３において、運転者は、単独走行を継続する。なお、単独走行に移行した後でも、運転者の希望により、あるいはサーバ側からの指令により、別の隊列に再度加入することは可能である。前者としては例えば、休憩などでいったん停車した後に隊列走行を再開する場合がある。後者としては例えば、走行経路全体のうち、隊列形成可能な区画が２箇所以上存在する場合がある。

図２Ａに戻り、ステップＳ１０７で隊列に再度加入するかどうかを検出する。上述したような隊列再開の事情があれば（Ｓ１０７＝Ｙ）、Ｓ１０３に戻り別の隊列に加入する。
一方、そもそも隊列を離脱していない場合や（Ｓ１０５＝Ｎ）、Ｓ１０７で単独走行を継続する場合は（Ｓ１０７＝Ｎ）、ステップＳ１０８に移行し、現在の走行状態を維持する。

（終了処理）
ステップＳ１０９において、現在位置と入力された目的地を比較し、到着したかどうかを判定する。到着していれば（Ｓ１０９＝Ｙ）、その旨を運転者に出力し、ナビゲーションおよび隊列走行支援を終了する。到着していなければ（Ｓ１０９＝Ｎ）、ステップＳ１０４に戻り走行を続ける。なお、既に単独走行している場合にはＳ１０４，Ｓ１０５は適用されない。

以上説明したところによれば、車両用アプリ３１は、カーナビゲーションアプリと協働しつつサーバ側からの指令に応じて運転者を適切に誘導することにより、運転者に通常の運転以上の負担を掛けること無く、隊列への加入および離脱を促す。

＜サーバ側での処理＞
続いてサーバ側、すなわちＭ２Ｍクラウドサーバ５、センサネットワークサーバ６、アプリケーションサーバ７中の隊列処理アプリ７１での処理について説明する。特にここでは、図１の右上に示したセンサネットワーク処理と、図３に示した隊列処理アプリ７１の処理を中心として説明する。

（センサネットワーク処理）
上で述べたように、データ提供契約ＤＢ６１にはＩＤ情報（Ｓ＿ＩＤ）に紐付けられて、当該ＩＤ情報を持つスマートフォンからのセンシングデータを利用して良いアプリケーション番号（ＡＰＰＬＹ＿ＩＤ）が格納されている。そこでセンサネットワークサーバ６は、Ｍ２Ｍクラウドサーバ５からの仲介を受けて、隊列処理アプリ７１（ＡＰＰＬＹ＿ＩＤ＝Ａ１）が利用可能なセンサデバイスの情報を送信する。図１の例では、車両２に対応するＳ＿ＩＤは、（ＡＰＰＬＹ＿ＩＤ＝｛Ａ１，Ａ３｝）に対してセンシングデータの利用を許可している。つまり、隊列処理アプリ７１のほか、渋滞マップアプリ７３（ＡＰＰＬＹ＿ＩＤ＝Ａ３）でもデータを利用できる。なお、データ利用契約ＤＢ６２を参照して、隊列処理アプリ７１の所有者への課金処理なども行われる。
Ｍ２Ｍクラウドサーバ５は、ネットワーク４を介して受信したスマートフォンからの情報（Ｓ＿ＩＤ，Ｓ＿ＤＡＴＡ）をデータベースに格納している（蓄積手段であり、図３の、現在位置および移動計画ＤＢ３０１に対応）。このＤＢ３０１に格納されたデータの中から、センサネットワークサーバ６から得たＳ＿ＩＤを持つもの（すなわち、隊列処理アプリ７１での利用を許可したもの）を、アプリケーションサーバ７に送信する（Ｓ＿ＩＤ，Ｓ＿ＤＡＴＡ）。なお、当該データベースは、車両２に設置されたスマートフォン３との通信結果を踏まえて、Ｍ２Ｍクラウドサーバ５により随時、登録または更新される（図２ＤのＳ１０４１に対応）。

（隊列走行制御時の動作）
図３左下のプロセスＰ３０１において、サーバ側（本実施形態ではＭ２Ｍクラウドサーバ５）は、スマートフォン３から送信された情報（Ｓ＿ＩＤ，Ｓ＿ＤＡＴＡ）を取得し、ＤＢ３０１に格納する。これにより隊列走行生成処理が開始される。

図３左上のプロセスＰ３０２において、サーバ側（本実施形態では隊列処理アプリ７１）は、隊列走行グループ候補と、隊列走行区間および隊列走行時間帯の組からなる、隊列走行データを抽出する。この処理は、取得した車両ごとの移動計画に基づき、走行経路の少なくとも一部が同じ時間帯に重なる車両グループを選択し、隊列走行区間および時間帯の組からなる隊列走行データを抽出するものである。さらに隊列走行データごとに、隊列走行制御オブジェクトの生成から消滅までが管理される。例えば図３中央に示した隊列走行データｋには、隊列走行グループ候補ｋを構成する車両のリストと、これらの車両が隊列走行するべき道路区間および走行スケジュール（言い換えると、各車両の経路と時間帯が一致した情報）が含まれている。
すなわち隊列走行生成処理では、ＤＢ３０１を参照して、同じ時間帯に同じ経路を通る車両が一定数以上ある場合にグループとして抽出する。隊列走行データとは、抽出された車両を特定する情報（Ｓ＿ＩＤ）、区間を特定する情報（地図上の区間情報）、時間帯で特定されるデータであり、一定の期間、一緒に走行する隊列の候補となる。車両グループを抽出する際には、走行区間（走行方向も）および時間帯をキーとして車両を選択すると良い。なるべく多くの隊列を形成するためには、煩雑になり過ぎない範囲で走行経路を細分化すると良い。
あるいは、車両のグルーピングにおいては、まず隊列走行する経路区間を決定し、そこを同じ時間帯に通過する車両をピックアップしても良い。

プロセスＰ３０２は、図３に示したように、アプリケーションサーバ７のマルチスレッド処理により、隊列走行データ（１〜Ｎ）ごとに隊列走行制御オブジェクト（１〜Ｎ）を生成する。したがって、交通制御システム１の中で形成し得る隊列の数だけ隊列走行制御オブジェクトが存在する。目的地に到着して隊列走行が終了すると、その隊列を制御していた隊列走行制御オブジェクトも消滅する。

隊列走行制御オブジェクトの主要な処理は、プロセスＰ３０３およびＰ３０４である。Ｐ３０３では、隊列に参加する車両（２ａ〜２ｎ）に隊列走行制御のための指令（図1のＮＡＶＩ＿ＭＳＧ）を送信する。指令情報を受けた車両が、図２Ｃ、図２Ｄのフローで示したように運転されることにより隊列走行が実現する。Ｐ３０４では、信号管理装置８に信号操作を要求する指令を送信する。この指令には、対象となる信号機の位置情報と、青信号を点灯させる時間（ＰＬＡＣＥ，ＴＩＭＥ）が含まれる。すると信号管理装置が信号機９に、青信号の点灯指示と点灯時間を送信する（ＳＩＧ＿ＣＴＲＬ，ＴＩＭＥ）。このように、Ｐ３０３とＰ３０４が連動して隊列を優先的に通過させる。隊列走行制御オブジェクトは、道路ネットワークデータおよび信号管理装置との交信用データを格納されたＤＢ３０２を参照して、Ｐ３０３やＰ３０４に必要な情報を得る。

＜隊列走行制御オブジェクトの状態遷移＞
図４を参照して、隊列走行制御オブジェクトの生成から消滅までを詳細に検討する。図中、Ｅ０〜Ｅ９は隊列に起こるイベントを表し、Ｓ１〜Ｓ６は隊列の状態を表す。

（優遇処理について）
ここで前提として、本実施形態での車両の台数と優遇条件の関係について説明する。本実施形態では、車両台数をＮ１＞Ｎ２と置いたとき、隊列にＮ１台以上の車両が参加すると信号機における優先通過が可能になるものとする。また、Ｎ２台以上の車両が参加していれば、優先通過はできないものの、何らかの交通システム上あるいは経済上のメリットが得られるものとする。例えば、高速道路の利用における割引料金の適用、ガソリンスタンドでの給油時の割引、ＰＡやＳＡ、道の駅等の休憩施設におけるサービスの享受などである。さらに本実施形態では、隊列への参加可能台数に上限（Ｎ３台）を設けて、センサネットワークに不参加の車両等への影響を抑えることとする。
また、隊列の車両台数が優遇条件を満たしていても、所定の安全基準も満たさない車両に対しては信号機の優先通過権を与えないことも、交通秩序維持の観点から好ましい。例えば隊列平均速度が法定速度を超えている場合や、路肩走行あるいは幅寄せ等を行う車両が参加している場合などである。

（隊列の形成と維持）
Ｅ０は、隊列処理アプリ７１により車両グループが抽出され、隊列走行制御オブジェクトが生成されることを示す。これにより、隊列走行の先頭車両が指定されて、先頭車両の単独走行の状態となる（Ｓ１）。なお、指定された先頭車両は特にそれを意識する必要はない。
Ｅ１は、グループに含まれる他の車両に対して、隊列への参加を促す指令情報が発信されることを示す。これにより、複数の車両により隊列が形成されているが、信号機での優遇を受ける条件を満たしていない状態となる（Ｓ２）。このとき台数はＮ２台以上、Ｎ１台未満である。まだ参加していない候補車両に対しては、引き続きイベントＥ１による合流指令がなされる。この状態において、交通システム上あるいは経済上のメリットを与えるために、隊列走行制御オブジェクトは、提携した事業者等に隊列参加車両の情報などを送信しても良い。
Ｅ２は、隊列を構成する車両数が優遇条件を満たすＮ１台以上となり、かつ平均走行速度が適正となったことを示す。ここで平均走行速度を考慮しているのは、上述したように安全運転を促すためである。これにより、優遇走行を実行しつつ、さらに隊列への合流車両が存在する状態となる（Ｓ３）。Ｓ３の状態になると、隊列走行制御オブジェクトは、信号管理機８に対して隊列の優先的通過を求める指示を行う（図３のＰ３０４）。
Ｅ３は、平均走行速度が不適正であることを示す。この場合、走行の優遇が受けられない隊列走行の状態となる（Ｓ６）。
Ｅ４は、隊列を構成する車両数が上限（Ｎ３台）に達したことを示す。これにより、隊列への合流の受け入れを停止したまま優遇走行を継続している状態となる（Ｓ６）。このとき隊列走行制御オブジェクトはイベントＥ１を発生させず、信号機への指示と通常のナビゲーションのみを行う。
Ｅ５は、隊列を構成する車両のいくつかが離脱したことを示す。ただし車両台数が未だＮ２台以上であれば、優遇を受けられるＳ３状態に留まる。一方、Ｅ６は、車両の離脱により車両数が優遇条件を満たさなくなった（Ｎ２台未満となった）場合であり、Ｓ２状態に遷移する。

（隊列の消滅）
Ｅ７は、車両の離脱で、車両数が隊列を維持できない数（本実施形態では２台以下）になったことを示す。このイベントは、Ｓ２，Ｓ３，Ｓ４といった隊列走行中に発生する。これにより、隊列は消滅状態となる（Ｓ５）。
Ｅ８は、隊列走行中に全車両が目的地に到着したことを示す。これによっても隊列は消滅状態となる（Ｓ５）。
隊列がＥ７またはＥ８により消滅した後、隊列走行制御オブジェクトは消滅する。あるいはオブジェクトをそのまま利用して、次の隊列走行の先頭車両を指定しても良い（イベントＥ９）。この場合は再度Ｓ１に遷移する。

＜信号機の優先通過＞
図５を参照しつつ、交差点等の信号機における隊列の優先制御について説明する。

（基本的な優遇処理）
図５中、優遇を受けるべき隊列２０Ａを形成する車両群は、第一交差点５０１ａの方向に進行している。信号管理装置８は、隊列が第一交差点５０１ａから所定距離（例えば３００ｍ）に近づくと、交差点内の信号機を青色にする。これにより隊列２０Ａは停止することなく交差点に進入し通過できる。
さらに、次の第二交差点５０１ｂの信号機を制御しても良い。この場合、図示したように、第一交差点５０１ａと第二交差点５０１ｂを同時に青にすれば良い。あるいは、先頭車両の各交差点への進入タイミングに合わせて青信号を点灯することでも、適切な制御が可能である。この制御方法を用いる場合、先頭車両が露払い区間５０２に入った時点で第二交差点５０１ｂを青信号に変更し、隊列が通過するまで青信号を維持すれば良い。

（追加的な優遇処理）
さらに必要に応じて、隊列以外の車両に指令情報を送ったり、交通制御をおこなったりして、隊列の前方を走る車両の数を減らし、道路を通りやすくすることも考えられる。例えば、露払い区間５０２や第一または第二交差点に他の車両が入らないよう信号機を制御する。
かかる処理は、例えば、隊列２０Ａの車両台数が多いため優先通過させることによる渋滞抑制効果が大きい場合や、一つの交差点では車両が通過し切れない場合がある。また、社会的な重要度が高い車両や、価値の高いセンシングデータを提供する者に対するボーナスとして、かかる追加措置を行っても良い。

（隊列同士の競合）
優先通過の対象となる隊列が複数同時に存在する場合、隊列同士の競合をどのように処理するかが問題となる。例えば第二交差点５０１ｂに別方向から隊列２０Ｂが進入しようとしているときに、どちらを優先するかの基準が必要である。これは交通制御システムの総合的な状況や他の車両への影響度合いによって決められる。例えば台数の多い隊列を優先することや、乗車人数が多いほうを優先することが可能であり、後者であれば乗り合いの促進にもつながる。あるいはハイブリッドカー、低燃費車またはＥＶ車等のエコカーを優先することにより乗り換えを促すこともできる。さらに、隊列処理アプリ７１が、両隊列の速度を指令情報により調整して、交差点を通過するタイミングをずらしても良い。このような調整は、隊列走行制御オブジェクト同士の情報交換により実現できる。

［変形例］
移動計画を作成する処理に関する変形例を説明する。上記実施形態では、スマートフォン３にインストールされた車両用アプリ３１が、車両の現在位置および目的地に基づいて移動計画情報を生成し（図２ＢのＳ１０１４）、サーバ側に送信していた（図２ＣのＳ１０３１）。しかしこの移動計画作成処理を車両側で行うのではなく、サーバ側に行わせることも可能である。

具体的には、アプリケーションサーバ７は、スマートフォン３の通信装置（車両情報送信手段とも呼べる）から現在位置と目的地に関する情報を受信する。そして隊列処理アプリ７１が演算資源を用いて移動計画を作成し、ＤＢ３０１に蓄積する。後は上記実施形態と同様に、隊列走行制御オブジェクトから各車両に指令情報を送信する。

この方法でも、車両が隊列を組んで走行する上で何ら支障はない。またスマートフォン３にとっては、移動計画を生成する重い演算処理を行わずに済むため、装置を簡易かつ安価に構成できるというメリットがある。

［実施形態２］
上記実施形態１では、車両位置関係形成支援として隊列の形成支援を行った。本実施形態では、指令情報としてそれ以外の位置関係を形成するようなナビゲーションをする場合について説明する。

（他の車両と所定以上の距離を置く位置関係）
まず、対象となる車両が、特定の他の車両と所定以上の距離を置くような制御がある。例えば公共交通機関であるバスの後方を走っている車両は、バスが停留所で停車することによって停止や車線変更を余儀なくされる。これにより目的地への到着が遅くなり運転者のストレスとなることに加え、交通の停滞を引き起こす。そこで、サーバ側からの指令情報において、例えば「同じレーン上でバスの後方２００ｍ以内に入らない」といったナビゲーションを行う。これにより、上記のような問題の発生を防止することが可能となる。この場合、ナビゲーション対象となる車両以外の、バス等の車両に関する移動計画情報は、必ずしも当該バス等との通信により取得しなくても良い。例えば公共車両の運行に関するデータベースを参照することにより、ナビゲーション対象車両への指令情報を生成することも可能である。

（他の車両から所定の範囲内にある位置関係）
次に、対象となる車両と自分の車両とが、所定の距離範囲内に維持されるような制御がある。例えば会社の同僚など、複数の車両が含まれるグループがあり、同じ目的地へ向けて走行している場合、各車両の運転者はなるべく互いの距離を開けずに、一緒に（近い時間に）目的地に到着したいと考える。そこで、各車両をスマートフォンのＩＤ情報などで特定し、その位置情報を反映して所定の距離（例えば１００ｍ）以上離れないようなナビゲーションを行う。これにより、各車両が近い時間帯に到着できるという効果が得られる。

＜本発明の効果＞
本発明を適用することにより、以下の様なメリットが得られる。

（交通全体のメリット）
上述したように、渋滞の最大の原因は信号機における車両の停滞である。また各車両の目的地や、運転者の運転技術あるいは順法意識に差異があることによっても交通が乱れて渋滞がおこる。その結果、事故の発生や環境悪化、ストレス増大による社会生産性の低下を招来している。
しかし本発明に係る交通制御システムによれば、車両グループに隊列を形成させて誘導し、信号機において優遇されるようになり、かつ、道路ネットワークデータに基づき随時最適化されたナビゲーションが行われる。このように、パターン化された従来技術とは異なり、信号機が交通の実情に応じて柔軟に制御される結果、相対的に多くの車両がスムーズに走行可能となる。これを交通システム全体で見ると、車両が赤信号で停止する回数の総量が減ることになり、車両が停滞しなくなるので渋滞が緩和される。
また指令情報により法定速度を守らせることや、速度超過した車両には優遇措置を与えないことにして法規順守を促すことができるので、住民や道路管理者にとっても安全性の向上という効果がある。さらに、車両の排気ガスによる環境悪化を抑制できる。

（運転者等のメリット）
車両の運転者や同乗者にとっては、信号機で停止する確率が減るため、早く、かつ、ストレス無く目的地に到着できる。また、停止や発進の回数が減少し、安定した速度で走行することにより燃費が向上する。また、隊列走行により風圧の影響が減少するため、さらに燃費が向上する。このとき、サーバ側からのナビゲーションに従うことにより、自然に法定速度を守って走行できる上、他の車両と遭遇する回数も減るので、交通事故を起こしにくくなる。
また、本発明ではサーバ側からグループ形成の指示が送信されるため、運転者同士が予め経路や走行時間帯を合わせなくても隊列を組むことができる。さらなる効果として、運転者同士の仲間意識を高めることができる。すなわち、目的地や走行時間帯を同じくする者は、日常の生活圏や行動パターン（例えば通勤通学先や好みのレジャー等）も似通っている可能性が高いので、新たな人間関係を構築できる。
また、信号機の優先通過以外の優遇処理、例えば図４で説明したように、提携事業者による交通システム上あるいは経済上のメリットが得られる。この場合、提携する事業者にとっても、団体客が来場することにより営業機会が増加することになる。

（センサネットワーク上のメリット）
本発明では、センサネットワークの利点はそのまま享受できる。すなわち、センサの有効活用と簡易なデータ入手である。さらにカーナビゲーションアプリという、多くの車両が用いる機能と抱き合わせて隊列走行処理を行うことにより、取引されるセンシングデータ量が増大して経済活動が活発化する。
センサネットワークの運営者やデータ利用者にとっては、信頼性の高いセンシングデータの収集と利用が可能となる。特に、グループに参加する複数の車両のデータに基づく平均化処理や多数決論理処理により、信頼度を向上させられる。また、位置情報や速度情報に加えて画像情報なども入手してセンサーフュージョン処理をしても良い。これにより例えば、道路の路面の傷を探知するセンサや、違法駐車車両の検出が可能となり、かかるサービスを提供するアプリケーションに有益である。また、各車両の移動計画情報を入手するということは、将来の渋滞を予測するアプリケーションにも有効といえる。
一方、センサネットワークのデータ提供者であるセンサデバイス（車両あるいはスマートフォン）の所有者にとっては、データ販売機会の増大につながる。

なお、本発明における車両は四輪車とは限らない。例えば二輪車のみのグループや四輪車と二輪車が混在したグループでも構わない。また、速度によっては自転車を含めることもできる。

［実施形態３］
本実施形態では、ネットワークに接続され、ＩｏＴを構成する物（Ｔｈｉｎｇ）の情報を効率的に利用するために、適切なデータフロー制御を行う方法について述べる。ここでは「物」として様々なセンサを想定し、得られたセンシングデータから新たな価値を持つ情報を生成する。本実施形態の枠組みは、利用料金などを条件としたデータ流通のみならず、より広範なセンシングデータ利用に適用できる。また、本実施形態ではセンサネットワークサーバがデータフロー制御を行うが、本発明の適用先はこれに限られない。例えば各センサネットワークアダプタが自律的に機能しつつ、相互に連携して情報を利用しあうことも可能である。

＜センサ側イベント駆動型アクセスモード＞
図６Ａは、本実施形態におけるシステムの構成要素とデータの流れの一例を説明するための図である。主な構成要素として、センサ（６３１Ａ、６３１Ｂ）、センサネットワークアダプタ６３、センサネットワークサーバ６、アプリケーションサーバ７、インターネット等のネットワーク４がある。

（装置構成）
センサ（６３１Ａ、６３１Ｂ）は、何らかの物理量やその変化を検出し、センシングデータとして記録または出力するデバイスである。センサネットワークアダプタ６３は、センサと物理的または電気的に接続されてセンシングデータ取得する。また、ＣＰＵ等の情報処理装置によりセンシングデータに所定の処理を施す。また、外部との通信機能を有し、ネットワーク４を経由したアプリケーションサーバ７との通信や、センサネットワークサーバ６との通信が可能である。
一例として、センサネットワークアダプタ６３としてスマートフォンを、センサ６３１Ａおよび６３１Ｂとしてそれぞれ、位置センサ（ＧＰＳ）および加速度センサを想定できる。スマートフォンの場合、カメラ、マイク、入力システムなどもセンサと言える。

センサネットワークサーバ６は、センサに関する情報とアプリケーションに関する情報をマッチングし、センサ側への指示としてデータフロー制御を行う。センサネットワークサーバ６は、センサ側メタデータＤＢ６６１およびアプリ側メタデータＤＢ６６２から情報を取得する。各ＤＢはサーバの内外いずれにあっても良い。ここではメタデータとは、サーバによる検索やマッチングに用いるための、センサおよび当該センサにより得られるセンシングデータの属性に関する情報（センサ側メタデータ）、ならびに、アプリケーション自身および当該アプリケーションが必要とするセンシングデータの属性に関する情報（アプリ側メタデータ）を言う。マッチング処理およびメタデータの構造については後述する。

アプリケーションサーバ７は、センシングデータを利用して演算処理を行い、目的に応じた情報を生成する。例えばアプリケーションサーバ７ｋでは、各車両の位置情報と加速度情報を利用して渋滞状況配信やルート案内などを行う交通情報アプリを、アプリケーションサーバ７ｍでは交通量調査アプリを動作させると想定できる。

（処理フロー）
図７のフローチャートを参照しつつ、処理の手順について説明する。
ステップＳ７０１にて、センサ６３１がセンシングデータを取得する。

ステップＳ７０２にて、センサネットワークアダプタ６３が、イベント発生を検出する（図６Ａ中の丸数字１）。そして、センサネットワークサーバにセンサ側イベント通知を送信する（丸数字２）。
検出処理は、センサやアダプタの種類に応じた方法でなされる。例えば継続的に統計量を取得するセンサにおいて、アダプタが定期的に統計量を監視し、閾値以上の値になった時にイベント発生と判定する。車両等に用いる速度センサによる速度検出、液面センサによる水位検出において閾値以上の値となった場合や、画像センサにおいて一定以上の画素値の変化が検出された場合が挙げられる。
また、センサネットワークアダプタ６３の情報処理能力によっては、統計量の変化を解釈して、状態変化を判断してもよい。例えば、速度センサによる検出値が法定速度を超えている場合に「危険運転状態」と判定したり、液面センサが所定以上の場合に「水漏れあり」と判定したりすることが考えられる。また、画像センサで得られた画素値の変化に基づき人物認識などの画像処理を行い、人物が存在するという情報や、特定した人物名をもって検出結果としても良い。他に、センサがスイッチの場合、ＯＮ／ＯＦＦいずれの状態であるかを検出する。

ステップＳ７０３にて、センサネットワークアダプタが、センサ側メタデータＤＢ６６１内に記録されているセンサ６３１Ａのメタデータにマッチするアプリのメタデータを検索する。
上記Ｓ７０３においてマッチするアプリがあれば、ステップＳ７０４にて、センサネットワークサーバがデータフロー制御指令を作成して、センサネットワークアダプタに送信する（丸数字３）。

ステップＳ７０５にて、指令を受けたセンサネットワークアダプタ６３が、ネットワーク４経由でセンシングデータ（丸数字４）をアプリケーションサーバ７ｋ、７ｍに送信する。
センシングデータを送信する際のデータ構成例を説明する（丸数字５）。送信時には、宛先の指定が必要となる。宛先指定方法の一例として、アプリケーションサーバのＩＰアドレス、アプリファイル名（センシングデータを使用するプログラム名）、アプリファイル内でセンシングデータに割り当てられるタグ名、という組み合わせを利用できる。プログラム内での処理において用いる変数にタグを対応させると良い。センサが複数のデータを出力する場合、上記タグの数を増やすことで対応できる。かかるデータをセンサネットワークアダプタ６３からアプリケーションサーバ７に、ＴＣＰ／ＩＰプロトコルで送信する。

ステップＳ７０６にて、アプリケーションサーバがセンシングデータを利用して付加価値のあるサービスを提供する。

（データ構造とマッチング処理）
図６Ｂに示すように、センサ側イベント通知（丸数字２）は、少なくともセンサを特定する情報を含む。これには個々のセンサに割り当てられたセンサアドレスや、センサアダプタとそのポート番号で特定する方法がある。さらに、検出されたイベントを特定するための所定のイベント符号を送信すれば、より細かい制御を実行できる。
また、本実施形態を特徴付けるデータフロー制御指令（丸数字３）は、データ送信元の情報と、データ送信先の情報を含む。すなわちデータフロー制御指令とは、マッチング処理の結果に従い、センシングデータを適切な提供元から適切な利用者へ流通させるための指令情報を指す。前者の指定方法は、センサ側イベント情報と同様で良い。後者の指定方法は、上述したようにＩＰアドレス等を用いることができる。

センサ側メタデータＤＢ６６１には、センサアドレスごとに全てのメタデータが登録されている。データ構造の一例を図１２Ａに示す。ＤＢ中にはセンサに関する情報とセンシングデータに関する情報が含まれる。前者の例として、「１．センサの属性情報」の下の「（４）センサのＩＤ、アドレス」があり、これによりセンサを特定できる。また、後者の中には、図６Ｂで示したようなイベント発生符号を含められる。イベント発生符号を用いれば、イベント種類に応じてアプリケーションを選択するような細かい制御が行える。また、定期的な通信とイベント発生の通知を同じプロトコルで実現できる。

アプリ側メタデータは、アプリケーションごとに、アプリ側メタデータＤＢ６６２に登録されている。データ構造の一例を図１２Ｂに示す。ＤＢ中にはアプリケーションで必要とするセンシングデータに関する情報と、アプリケーション自身の情報が含まれる。

センサネットワークサーバ６が受信したセンサ側イベント通知を解析してセンサアドレスを取得し、それをキーとしてセンサ側メタデータＤＢ６６１を探索する。これにより、図１２Ａに示したような情報が得られる。次いでセンサネットワークサーバ６は、アプリ側メタデータＤＢ６６２から、このセンサで得られたセンシングデータを必要とするアプリケーションを探索する。具体的には、センサおよびセンシングデータの情報を、図１２Ｂの「１．必要とするセンサの属性情報」〜「５．必要とするセンシングデータの管理属性」と突き合わせ、一致した場合にデータを採用する。アプリ側の必要条件と完全一致しなくても、所定の範囲であればデータを送信するように、誤差の許容幅を設けておいても良い。なお、マッチングにおける条件は、センサとセンシングデータの種類に関するものだけでなく、利用対価の条件も含まれる。逆に、利用対価はメタデータの一種類であるとも言える。

マッチングにより特定されるアプリケーションは単数あるいは複数の場合があり、複数の場合、同じサーバあるいは異なるサーバ上で動作し得る。また、アプリケーションが相互通信し、連動して動作することもある。センサネットワークサーバ６は、図１２Ｂの「６．アプリ自身のメタデータ」を参照してデータフロー制御指令を作成し、センサネットワークアダプタ６３に指示を出す。

以上に示すシステムによれば、センサと利用者が固定された従来のＩｏＴと異なり、ネットワーク上において、センシングデータの送受信に関して利用対価の処理を含む情報流通の最適化が可能となる。そのため、アプリケーションサーバにおいて新たな付加価値のある情報が生成されてセンサ資源が有効活用される。例えば、移動する車両などのセンサ情報が必要な場合など、構成要素が流動的なシステムにおいてシームレスに情報提供ができる。また、アプリケーションの側では、複数のセンサ候補がある場合に利用対価などの条件に基づき有利なセンサを選択したり、複数のセンサを全て用いて精度を上げたりできる。また、センシングデータ処理はセンサやアプリの特性に応じて様々な粒度で実行可能なので、汎用性の高いデータ基盤を形成できる。

＜アプリ側イベント駆動型アクセスモード＞
図８Ａは、本実施形態におけるシステムの構成要素とデータの流れに関する、上述のセンサ側イベント駆動型アクセスモードとは別の例を説明するための図である。構成要素自体は上の例と同じであり、処理開始のきっかけと手順が異なる。

（処理フロー）
処理フローについて、図７のフローと異なる部分を中心に説明する。ここでは、アプリ側イベント駆動型アクセスモードの一例として、交通制御システムアプリが交通量制御を行う場合を説明する。
当該アプリは、交差点での事故発生の通知を受けると、それをトリガとして（丸数字１）、その交差点へ流入する道路の交通量を減らすために動作する。アプリはエリア内の監視カメラや車両のセンサ情報を得るために、アプリ側イベント通知（丸数字２）をセンサネットワークサーバに送信する。図８Ｂにあるように、この通知にイベント符号などの情報を付加して詳細な制御を行うことも好ましい。

センサネットワークサーバ６は、図８Ｂのようなデータフロー制御指令をセンサネットワークアダプタ６３に送信する（丸数字３）。指令内容は図６Ｂと同様に、データの宛先の情報が含まれる。指令を受けたセンサネットワークアダプタ６３は、センサ６３１Ａからのセンシングデータ（丸数字４）を所定のヘッダを付したパケット形式としてネットワーク４経由で送信する（丸数字５）。例えばセンサが車載ＧＰＳであれば位置情報が収集され、センサが路側の監視カメラによる撮影画像であれば画像データや、それをアダプタ側で解析した情報が収集される。アプリケーションサーバ７ｍの交通制御システムアプリ（ファイル名ｍ）は、収集した情報を利用して交通状況を把握し、信号制御や路側の電光掲示板への情報提供などを実行する。

＜センサ側メタデータ駆動型アクセスモード＞
図９Ａは、本実施形態におけるシステムの構成要素とデータの流れに関する、上述の各例とは別の例を説明するための図である。システムの構成要素のうち、センサネットワークサーバ６のセンサ側メタデータＤＢ６６１が存在しない。

（処理フロー）
処理フローについて、各例と異なる部分を中心に説明する。ここでは、センサ側メタデータ駆動型アクセスモードの一例として、アプリケーションサーバ上の映像配信アプリが、実際の路上を走行中の車両から撮影された動画像に基づくドライブ体感映像を配信する場合を説明する。

車載カメラであるセンサ６３１Ａは、センシングデータとして動画像を取得する。センサネットワークアダプタ６３は、これをイベント発生であると検出して（丸数字１）、センサ側メタデータを送信する（丸数字２）。図９Ｂにあるように、これには図１２Ａに示すメタデータが含まれており、メタデータ中のセンサアドレスによりセンサが特定される。この通知にイベント符号などの情報を付加して詳細な制御を行うことも好ましい。センサネットワークサーバ６は、受信したセンサ側メタデータと、アプリ側メタデータＤＢ６６２とを比較してマッチングを行い、データフロー制御指令を作成する（丸数字３）。なお、受信したメタデータを記憶装置（不図示）に登録しても良い。これにより、センサ側イベント駆動型アクセスモードと、本アクセスモードを切れ目なく利用できる。

データフロー制御指令を受信したセンサネットワークアダプタ６３は、センシングデータである動画像（丸数字４）を所定のヘッダを付したパケット形式としてネットワーク４経由で送信する（丸数字５）。アプリケーションサーバ７ｋの映像配信アプリ（ファイル名ｍ）は、得られたデータを用いてサービスを提供する。

本アクセスモードは、メタデータが常にセンサ側から送信されるので、例えば車載カメラのように位置が変化するセンサであっても、最新の状態を反映した鮮度の高い情報を用いたマッチングが行われる。またセンサネットワークサーバにおいてメタデータを蓄積していくことで、イベント駆動型とメタデータ駆動型の両方を実現できる。

＜アプリ側メタデータ駆動型アクセスモード＞
図１０Ａは、本実施形態におけるシステムの構成要素とデータの流れに関する、上述の各例とは別の例を説明するための図である。システムの構成要素のうち、センサネットワークサーバ６のアプリ側メタデータＤＢ６６２が存在しない。

（処理フロー）
処理フローについて、各例と異なる部分を中心に説明する。ここでは、アプリ側メタデータ駆動型アクセスモードの一例として、スマートフォンにインストールされたカーナビゲーションアプリが、当該スマートフォンの所持者の移動に応じて、少し先（１ｋｍ先、１０分後など）の位置の映像や情報を提示する場合を説明する。これは、車両進行方向での状況を把握し、進路変更するか否かを判断する際に利用できる。

カーナビゲーションアプリは、渋滞に行き会った運転者からの案内要求などのイベント発生をトリガとして（丸数字１）、少し先の状況を提示するために動作する。アプリはエリア内の監視カメラや車両のセンサ情報を得るために、アプリ側メタデータをセンサネットワークサーバ６に送信する（丸数字２）。図１０Ｂにあるように、この中には図１２Ｂに示すメタデータが含まれている。この通知にイベント符号などの情報を付加して詳細な制御を行うことも好ましい。

センサネットワークサーバ６は、受信したメタデータと、センサ側メタデータＤＢ６６１のマッチングを行い、アプリが必要とするセンシングデータを提供可能なセンサを特定する。そして、データフロー制御指令を作成してセンサネットワークアダプタ６３に送信する（丸数字３）。なお、受信したメタデータを記憶装置（不図示）に登録しても良い。

データフロー制御指令を受信したセンサネットワークアダプタ６３は、センシングデータ（丸数字４）を所定のヘッダを付したパケット形式としてネットワーク４経由で送信する（丸数字５）。センシングデータとしては例えば車両の位置情報、道路の画像情報、それらを情報処理装置により解析した道路の混雑状態など、様々な種類、粒度が考えられる。アプリケーションサーバ７ｍのカーナビゲーションアプリ（ファイル名ｍ）は、得られたデータを用いて運転者に情報を提供する。

本アクセスモードは、メタデータがアプリ側から送信されるので、例えば車載のスマートフォンのようにアプリ側の状況が随時変化する場合でも、最新の状態を反映した鮮度の高い情報を用いたマッチングが行われる。またセンサネットワークサーバにおいてメタデータを蓄積していくことで、イベント駆動型とメタデータ駆動型の両方を実現できる。

＜センシングデータＤＢを利用した制御モード＞
図１１Ａは、本実施形態におけるシステムの構成要素とデータの流れに関する、上述の各例とは別の例を説明するための図である。システムの構成要素として、Ｍ２Ｍクラウド１１０の基盤上にセンシングデータＤＢ１１０１が配置され、レコード１１０３が格納されている。また、センサネットワークサーバ６には、センシングデータのメタデータＤＢ６６３が存在する。そして後述するように、本発明の特徴であるデータフロー制御指令のフォーマットも異なる。

（処理フロー）
処理フローについて、「アプリ側メタデータ駆動型アクセスモード」と異なる部分を中心に説明する。本フローの状況が発生する例として、発生した交通事故の原因を調査しようとする管理者が、過去のある時点での道路上の状況を確認しようとする場合がある。

管理者は、アプリケーションに対してある時点での状況を提示するように要求する。これをトリガ（丸数字１）として、エリア内の監視カメラや車両のセンサ情報を得るために、アプリ側メタデータがセンサネットワークサーバ６に送信される（丸数字２）。図１１Ｂにあるように、この中には図１２Ｂに示すメタデータが含まれている。この通知にイベント符号などの情報を付加して詳細な制御を行うことも好ましい。

センサネットワークサーバ６は、受信したメタデータと、センシングデータのメタデータＤＢ６６３のマッチングを行い、アプリが必要とする過去のセンシングデータが、Ｍ２Ｍクラウド上のＤＢから提供可能であるかを探索する。そして、データフロー制御指令を作成してＭ２Ｍクラウド１１０に送信する（丸数字３）。なお、受信したメタデータを記憶装置（不図示）に登録しても良い。データフロー制御指令には、図１１Ｂにある通り、Ｍ２ＭクラウドのＤＢにおけるレコードを特定する情報が含まれている。

データフロー制御指令を受信したＭ２Ｍクラウド１１０は、センシングデータである過去の一時点での画像や車両情報（丸数字４）を、所定のヘッダを付したパケット形式としてネットワーク４経由で送信する（丸数字５）。アプリケーション（ファイル名ｍ）は、得られたデータを用いて管理者に情報を提供する。

本制御モードは、メタデータがアプリ側から送信されるので、例えば車載のスマートフォンのようにアプリ側の状況が随時変化する場合でも、最新の状態を反映した鮮度の高い情報を用いたマッチングが行われる。また、Ｍ２Ｍクラウド上に高性能な情報処理装置を配置し、センサーフュージョンを行うこともできる。例えば、上のフローではアプリケーションサーバの側でセンシングデータに基づく情報提示を行い、管理者の判断材料としていた。しかし、Ｍ２Ｍクラウド上の情報処理装置が、複数のセンサから得られた情報を統合して状況を判断してアプリ側に回答するような、仮想センサとして振る舞っても良い。この場合、データフロー制御指令は、仮想センサを構成する情報処理装置に対して送信される。

さらに、Ｍ２Ｍクラウド上存在する膨大なデータを利用して、大規模な仮想センサを構成できる。特に近年急速に普及しているスマートフォンは、その台数の多さと高機能からセンシングデータの提供元として期待されており、クラウド基盤上でデータの流通を促進する本発明の適用に好適である。

＜アクセスモードの切り替え＞
以上、各アクセスモードや制御モードにおける構成について図を用いて説明したが、実際のシステムでは同一の構成で各モードを兼ねることができる。そして、モード同士の間はシームレスに切り替えることも、固定して用いることも可能である。前者の場合、例えば、アプリ側から受信したデータがメタデータを含んでいるか、イベント通知であるかに応じてアクセスモードを切り替える。あるいは、受信したデータにモード指定を含める。また、メタデータマッチングにおいてアプリ側からの要求に適合するセンサがない場合に、Ｍ２Ｍクラウド上のメタデータ探索を行うこともできる。さらに、センサ側またはアプリ側メタデータ駆動型アクセスモードにおいて、受信したメタデータを随時記憶していくことで、探索可能となる割合を増やすこともできる。

＜メタデータＤＢの登録・更新処理の例＞
上述した各モードにおいて、センサやアプリのメタデータに変更が発生した場合、センサネットワークサーバ内のメタデータＤＢの登録・更新処理が必要となる。この登録・更新処理を、メタデータマッチングを基にしたセンシングデータの流通機能の効率をできるだけ低下させないで実行することが必要である。一つの解決方法として、センサネットワークサーバへセンサまたはアプリがデータ（イベント通知またはメタデータ）を送信する際に、アクセスモードを区別するためのアクセスモードフラグを一緒に送信する方法がある。以下、その手順を説明する。

（センサ側メタデータを新たに登録・更新する場合）
この場合、フラグにより「センサ側メタデータ駆動型アクセスモード」を指定する。データを受信したセンサネットワークサーバは、メタデータをセンサ側メタデータＤＢに登録し、以後は「センサ側イベント駆動型アクセスモード」の実行が可能である旨をセンサネットワークアダプタに送信する。

（アプリ側メタデータを新たに登録・更新する場合）
この場合、フラグにより「アプリ側メタデータ駆動型アクセスモード」を指定する。データを受信したセンサネットワークサーバは、メタデータをアプリ側メタデータＤＢに登録し、以後は「アプリ側イベント駆動型アクセスモード」の実行が可能である旨をアプリケーションサーバに送信する。

（センサのメタデータが登録済みで更新不要の場合）
この場合、フラグにより「センサ側イベント駆動型アクセスモード」を指定する。データを受信したセンサネットワークサーバは、メタデータのマッチングにおいてアプリが検知できない状況が基準以上続いた場合には、メタデータの更新が必要との情報を、センサネットワークアダプタに送信する。

（アプリのメタデータが登録済みで更新不要の場合）
この場合、フラグにより「アプリ側イベント駆動型アクセスモード」を指定する。データを受信したセンサネットワークサーバは、メタデータのマッチングにおいてセンサが検知できない状況が基準以上続いた場合には、メタデータの更新が必要との情報を、アプリケーションサーバに送信する。

＜メタデータの構成＞
センサ側およびアプリ側のメタデータの内容と使用方法の概要を説明する。なお、ここに挙げたものは代表的な例であり、この全てを含む必要はないし、表中に無い情報を付加しても良い。

（センサおよびセンシングデータのメタデータ）
図１２Ａにおいて、「１．センサの属性情報」はセンサ自身の情報であり、特に「（４）センサのＩＤ、アドレス」はマッチングにおいてセンサを特定するキーとなる。「２．センシング対象の属性情報」、「３．センシング対象領域の属性情報」は、種類の点で、アプリが必要とするデータを得られるかどうかの判断材料となる。「４．センシング動作の属性情報」は、アプリが必要とするデータ精度を得られるかどうかの判断材料となる。「５．センシングデータの管理属性」は、データ流通に必要となる利用対価や、データの信頼度の幅を設定する際に用いられる。

（アプリおよび、アプリが必要とするセンシングデータのメタデータ）
図１２Ｂにおいて、「１．必要とするセンサの属性情報」、「２．必要とするセンシング対象の属性情報」、「３．必要とするセンシング対象領域の属性情報」、「４．必要とするセンシング動作の属性情報」は、マッチングにおいてアプリの要求を特定するために必要である。「５．必要とするセンシングデータの管理属性」も、利用対価や信頼度を含め、マッチング判定に用いられる。そして「６．アプリ自身のメタデータ」は、データフロー制御指令を生成する際にも必要となる。例えば、イベント通知中のイベント符号がアプリ側のメタデータにおける「（３）当該アプリの起動を可能とするセンサ側イベント」に一致しており、他のメタデータ項目もマッチしている場合に、センサ側からの割り込みで当該アプリを起動できる。

上記のように、データフロー制御指令によりセンシングデータの流通が管理されるシステムに特徴を持つ本発明は、様々な角度から捉えることができる。典型的には、イベント通知やメタデータの受信に応じてマッチング処理をしてデータフロー制御指令を生成するセンサネットワークサーバ（データフロー制御指令発生装置）である。この場合、本発明のセンサ側メタデータ取得手段またはアプリ側メタデータ取得手段は、メタデータＤＢまたは受信データからメタデータを取得する。また、サーバ内の情報処理装置がマッチング手段、指示手段として機能する。これは、センサネットワークアダプタ（センサ管理装置）を用いる構成でも、Ｍ２Ｍクラウド上のデータベースにセンシングデータが格納された構成でも同様である。

また本発明は、データフロー制御指令に応じてデータ流通を制御するセンサネットワークアダプタ（センサ管理装置）としても捉えられる。この場合、アダプタ内の情報処理装置や通信装置が、本発明の指令受信手段や送信手段、検知手段として機能する。

また本発明は、システムの各構成要素における処理を情報処理装置に実行させるプログラムとしても捉えられる。さらに、マッチングの結果に基づき所定の規則で配列されたデータ構造を持ち、センサネットワークアダプタの情報処理装置に働きかけて、データの適正な流通を実現させる制御指令データストリームとしても捉えられる。

１：交通制御システム
２：車両，２０：車両の隊列
３：スマートフォン，３１：車両用アプリ
４：携帯ネットワーク
５：Ｍ２Ｍクラウドサーバ
６：センサネットワークサーバ
７：アプリケーションサーバ，７１：隊列処理アプリ
８：信号管理装置
９：信号機
６３：センサネットワークアダプタ，６３１Ａ・６３１Ｂ：センサ
６６１：センサ側メタデータＤＢ，６６２：アプリ側メタデータＤＢ

Claims (13)

1. センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得手段と、
   前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
   前記センサ側メタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを提供可能な前記センサを抽出するマッチング手段と、
   前記センサを管理するセンサ管理装置に対して、前記マッチング手段により抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を送信する指示手段と、
   を有することを特徴とするデータフロー制御指令発生装置。
2. 前記センサ側メタデータ取得手段は、前記センサ側メタデータが格納されたデータベースから当該センサ側メタデータを取得し、
   前記アプリ側メタデータ取得手段は、前記アプリ側メタデータが格納されたデータベースから当該アプリ側メタデータを取得し、
   前記マッチング手段は、前記センサ管理装置からの、前記センシングデータに基づき検知されたイベント発生の通知を受けて、前記マッチングを行う
   ことを特徴とする請求項１に記載のデータフロー制御指令発生装置。
3. 前記センサ側メタデータ取得手段は、前記センサ側メタデータが格納されたデータベースから当該センサ側メタデータを取得し、
   前記アプリ側メタデータ取得手段は、前記アプリ側メタデータが格納されたデータベースから当該アプリ側メタデータを取得し、
   前記マッチング手段は、前記アプリケーションからの、前記センシングデータを必要とするイベント発生の通知を受けて、前記マッチングを行う
   ことを特徴とする請求項１に記載のデータフロー制御指令発生装置。
4. 前記センサ側メタデータ取得手段は、前記センサ管理装置から、前記センシングデータに基づき検知されたイベント発生とともに送信される前記センサ側メタデータを受信し、
   前記アプリ側メタデータ取得手段は、前記アプリ側メタデータが格納されたデータベースから当該アプリ側メタデータを取得し、
   前記マッチング手段は、前記センサ側メタデータ取得手段が前記センサ側メタデータを受信すると、前記マッチングを行う
   ことを特徴とする請求項１に記載のデータフロー制御指令発生装置。
5. 前記センサ側メタデータ取得手段は、前記センサ側メタデータが格納されたデータベースから当該センサ側メタデータを取得し、
   前記アプリ側メタデータ取得手段は、前記アプリケーションから、前記センシングデータを必要とするイベント発生とともに送信される前記アプリ側メタデータを受信し、
   前記マッチング手段は、前記アプリ側メタデータ取得手段が前記アプリ側メタデータを受信すると、前記マッチングを行う
   ことを特徴とする請求項１に記載のデータフロー制御指令発生装置。
6. センサにより得られ、ネットワーク上のデータベースに格納されたセンシングデータに関する情報であるセンシングデータのメタデータを取得するセンシングデータのメタデータ取得手段と、
   前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
   前記センシングデータのメタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを抽出するマッチング手段と、
   前記ネットワーク上のデータベースに対して、前記マッチング手段により抽出された前記センシングデータと前記アプリケーションとを特定したデータフロー制御指令を送信する指示手段と、
   を有することを特徴とするデータフロー制御指令発生装置。
7. センシングデータを出力するセンサに関する情報であるセンサ側メタデータを用いて前記センサを管理するセンサ管理装置であって、
   前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータと前記センサ側メタデータとのマッチングにより前記アプリケーションの要求を満たすものとして抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を受信する指令受信手段と、
   前記抽出されたセンサからのセンシングデータを、ネットワークを介して所定のパケット方式により前記アプリケーションに送信する送信手段と、
   を有することを特徴とするセンサ管理装置。
8. 前記センシングデータを監視してイベント発生を検知する検知手段をさらに有し、
   前記送信手段は、前記イベント発生をデータフロー制御指令発生装置に通知し、
   前記データフロー制御指令は、前記イベント発生を通知されたデータフロー制御指令発生装置から送信されたものである
   ことを特徴とする請求項７に記載のセンサ管理装置。
9. 前記センシングデータを監視してイベント発生を検知する検知手段をさらに有し、
   前記送信手段は、前記イベント発生とともに前記センサ側メタデータをデータフロー制御指令発生装置に送信し、
   前記データフロー制御指令は、前記メタデータを送信されたデータフロー制御指令発生装置から送信されたものである
   ことを特徴とする請求項７に記載のセンサ管理装置。
10. センシングデータを出力するセンサに関する情報であるセンサ側メタデータを取得するセンサ側メタデータ取得ステップと、
    前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、
    前記センサ側メタデータおよび前記アプリ側メタデータのマッチングを行うことで前記アプリケーションの要求を満たすセンシングデータを提供可能な前記センサを抽出するマッチングステップと、
    前記センサを管理するセンサ管理装置に対して、前記マッチングステップにおいて抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を送信する指示ステップと、
    を情報処理装置に実行させることを特徴とするデータフロー制御指令発生プログラム。
11. センシングデータを出力するセンサに関する情報であるセンサ側メタデータを用いて前記センサを管理するセンサ管理装置の情報処理装置において動作するプログラムであって、
    前記センシングデータを利用してサービスを提供するアプリケーションに関する情報であるアプリ側メタデータと前記センサ側メタデータとのマッチングにより前記アプリケーションの要求を満たすものとして抽出されたセンサと前記アプリケーションとを特定したデータフロー制御指令を受信する指令受信ステップと、
    前記抽出されたセンサからのセンシングデータを、ネットワークを介して所定のパケット方式により前記アプリケーションに送信する送信ステップと、
    を前記情報処理装置に実行させることを特徴とするプログラム。
12. センシングデータを出力するセンサを管理する情報処理装置が読み取り可能なデータストリームであって、
    前記センシングデータを必要とするアプリケーションを特定する情報と、
    前記アプリケーションの要求を満たすものとして抽出されたセンサを特定する情報と、
    前記抽出されたセンサと前記アプリケーションとを特定した指令情報と、
    を含むことを特徴とする制御指令データストリーム。
13. 前記アプリケーションを特定する情報および前記センサを特定する情報は、センサに関する情報であるセンサ側メタデータと、アプリケーションに関する情報であるアプリ側メタデータのマッチングにより得られたものである
    ことを特徴とする請求項１２に記載の制御指令データストリーム。

Images