WO2021260970A1

WO2021260970A1 - ネットワークの制御方法、および、データ処理システム

Info

Publication number: WO2021260970A1
Application number: PCT/JP2020/045487
Authority: WO
Inventors: 靖明山岸; 浩久野
Original assignee: ソニーグループ株式会社
Priority date: 2020-06-26
Filing date: 2020-12-07
Publication date: 2021-12-30
Also published as: US20230239245A1; US11997017B2; JPWO2021260970A1

Abstract

本開示は、ネットワーク内のトラフィックを削減するとともに、データ処理するアプリケーションの処理負荷を低減させるようにするネットワークの制御方法、および、データ処理システムに関する。ネットワーク接続装置が、センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定する。本技術は、例えば、クラウドコンピューティングのネットワーク制御方法に適用できる。

Description

ネットワークの制御方法、および、データ処理システム

　本開示は、ネットワークの制御方法、および、データ処理システムに関し、特に、ネットワーク内のトラフィックを削減するとともに、データ処理するアプリケーションの処理負荷を低減させるようにしたネットワークの制御方法、および、データ処理システムに関する。

　本出願人は、特許文献１において、同期型のイメージセンサと非同期型のDVSとを組み合わせて用いた物体検出システムを先行して提案している。同期型のイメージセンサは、垂直同期信号に同期して撮像を行い、その垂直同期信号の周期で１フレーム（画面）の画像データであるフレームデータを出力するセンサである。DVSは、Dynamic Vision Sensorの略称であり、画素の輝度変化をイベントとして、イベントが発生した場合に、イベントの発生を表すイベントデータを出力するセンサである。DVSは垂直同期信号に依らずにイベントが発生したタイミングでイベントデータを出力するため、非同期型（又はアドレス制御型）のイメージセンサということができる。

　DVSからは、予測不可能かつ突発的にイベントデータが出る。イベントデータは遅延なく使えなければならないため時間粒度が極めて細かいデータとなっている。DVSから生成された大量のデータを、見境なくネットワークに注入すると、ネットワークのキャパシティに制限があるとすると、ネットワークが破綻し、本当に必要なデータが正しく処理できない可能性がある。ネットワークのキャパシティに制限がないとしても、ネットワーク上でデータ処理を行う計算資源が破綻する。すなわち、必要のない無駄な処理に計算資源が浪費される。したがって、ネットワークやネットワーク上の計算資源に負担をかけないため、イベントデータに対する何らかのフィルタリングを行ってからネットワークに注入しなければならない。

国際公開第２０２０／１９５７６９号

　このフィルタリングを、センサデータを生成するセンサデバイスだけで行うと、ネットワークそのものに負担をかけずに済むが、貧弱な計算資源のため、フィルタリングの精度に限界がある。センサデータをクラウド（ネットワーク）へ渡して、フィルタリングをクラウド内だけで行うと、クラウド上の豊富な計算資源を用いることができ、フィルタリングの精度を上げることができる。しかしながら、フィルタリング処理されないセンサデータをネットワーク上へ上げることになるので、計算資源をクラウド上の装置に分散させただけで、ネットワーク内を流れるデータの総量は変わらず、ネットワークやネットワーク上の計算資源の負担を減らすことができない。

　本開示は、このような状況に鑑みてなされたものであり、ネットワーク内のトラフィックを削減するとともに、データ処理するアプリケーションの処理負荷を低減させることができるようにするものである。

　本開示の第１の側面のネットワークの制御方法は、ネットワーク接続装置が、センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定する。

　本開示の第２の側面のデータ処理システムは、センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定するオーケストレータを備える。

　本開示の第１および第２の側面においては、センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所が、マニフェストに基づいて決定される。

　ネットワークとは、少なくとも２つの装置が接続され、ある装置から、他の装置に対して、情報の伝達をできるようにした仕組みをいう。ネットワークを介して通信する装置は、独立した装置どうしであっても良いし、１つの装置を構成している内部ブロックどうしであっても良い。

　なお、本開示の第１の側面のネットワークの制御方法および第２の側面のデータ処理システムは、コンピュータにプログラムを実行させることにより実現することができる。コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。

　データ処理システムは、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。

本開示を適用した一実施の形態であるデータ処理システムの構成例を示す図である。オーケストレータによるマニフェストの取得を説明する図である。図１のデータ処理システムによるアプリケーション配置制御を説明するフローチャートである。アプリケーションの配置方針を説明する図である。前処理として圧縮処理を行う場合のアプリケーションの配置方針を説明する図である。前処理として圧縮処理を行う場合のアプリケーションの配置方針を説明する図である。図５と図６のアプリケーション配置例を比較して示す図である。個別化処理を多段配置した場合のアプリケーションの配置方針を説明する図である。個別化処理を多段配置した場合のアプリケーションの配置方針を説明する図である。再利用性を重視する場合のアプリケーションの配置方針を説明する図である。再利用性を重視する場合のアプリケーションの配置方針を説明する図である。アプリケーション配置する際の評価軸と、その場合のアプリケーション配置の優先順位をまとめた図である。クラウドコンピューティングの構成例を示す図である。 DVSのイベントデータを利用して超解像画像を生成する例を示す図である。本技術を適用した画像処理システムの実施の形態である画像解析ネットワークシステムの構成例を示す図である。図１５の画像解析ネットワークシステムのアプリケーション適用例を示す図である。図１５の画像解析ネットワークシステムのアプリケーション適用例を示す図である。上流からROI超解像イメージストリームを配信する第１の例を示す図である。上流からROI超解像イメージストリームを配信する第１の例を示す図である。解析装置の分解能に応じたROI超解像イメージストリームの例を示す図である。上流からROI超解像イメージストリームを配信する第２の例を示す図である。上流からROI超解像イメージストリームを配信する第３の例を示す図である。上流からROI超解像イメージストリームを配信する第４の例を示す図である。上流からROI超解像イメージストリームを配信する例を示す図である。図１５の画像解析ネットワークシステムが行うROI超解像イメージストリームの配信例を示す図である。図２５の配信例の詳細を示す図である。イベントストリームが間引かれて伝送される例を示す図である。図２５の配信例の詳細を示す図である。各注目領域ROIのストリームの伝送経路を示した図である。図１５の画像解析ネットワークシステムの構成例を示すブロック図である。スナップショットと注目領域ROIの割り当ての例を示す図である。 ROIサブスクリプションリクエストを説明する図である。超解像処理ノードが解析装置の１つ上流側のノードに配置された場合の構成例を示すブロック図である。センサデバイスとブローカーノードのその他の構成例を示すブロック図である。センサデバイスとブローカーノードのその他の構成例を示すブロック図である。注目領域ROI単位のイベントストリームの第１のネットワーク伝送例を示す図である。注目領域ROI単位のイベントストリームの第１のネットワーク伝送例を示す図である。注目領域ROI単位のイベントストリームの第２のネットワーク伝送例を示す図である。 ROI超解像ストリームの例を示す図である。イベントデータの間引き合成を説明する図である。間引き合成前と間引き合成後の注目領域ROIのイベントストリームの例を示す図である。超解像画像解析処理の装置間の流れを説明するフローチャートである。超解像画像解析処理のモジュール間の流れを説明するフローチャートである。超解像画像解析処理のモジュール間の流れを説明するフローチャートである。超解像画像解析処理のモジュール間の流れを説明するフローチャートである。ストリームの伝送フォーマット例を示す図である。イベントパケットペイロードのフォーマット例を示す図である。本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。

　以下、添付図面を参照しながら、本開示を実施するための形態（以下、実施の形態という）について説明する。なお、本明細書において、「および／または」の記載は、「および」と「または」の両方を取り得ることを意味する。また、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。説明は以下の順序で行う。
１．データ処理システムの構成例
２．アプリケーション配置制御のフローチャート
３．最適配置の評価軸と配置方針
４．クラウドコンピューティングの構成例
５．DVSデータを用いた超解像ストリーム
６．超解像画像を用いた画像解析ネットワークシステム
７．ストリーム配信方法の例
８．画像解析ネットワークシステムが行うストリーム配信方法の例
９．画像解析ネットワークシステムのブロック図
１０．イメージストリームとROIイベントストリームの例
１１．ROIイベントストリームの間引き合成処理
１２．画像解析ネットワークシステムの処理の流れ
１３．ストリームの伝送フォーマットの例
１４．コンピュータ構成例

＜１．データ処理システムの構成例＞
　図１は、本開示を適用した一実施の形態であるデータ処理システムの構成例を示している。

　図１のデータ処理システム５００は、センサ５１１がセンシングにより生成したセンサデータをクラウド５２１へ送信（アップリンク）し、センサデータに対する所定のデータ処理をクラウド５２１上で行うネットワークシステムである。クラウド５２１上で実行されるデータ処理は、クラウド５２１で提供されるサービスに応じて決定される。例えば、センサ５１１がイメージセンサである場合、イメージセンサで生成された画像の認識処理や解析処理が、クラウド５２１上で実行される。

　センサ（Sensor）５１１は、例えば、同期型のイメージセンサ、非同期型のDVSなどで構成され、センシングにより生成したセンサデータを、エッジデバイス５１２へ供給するセンサデバイスである。同期型のイメージセンサは、垂直同期信号に同期して撮像を行い、その垂直同期信号の周期で１フレーム（画面）の画像データであるフレームデータを出力するセンサである。DVSは、画素の輝度変化をイベントとして、イベントが発生したタイミングに応じて非同期に、イベントの発生を表すイベントデータを出力するセンサである。

　なお、本実施の形態では、センサ５１１が、同期型のイメージセンサまたは非同期型のDVSのいずれか一方または両方を備えるセンサデバイスであるとして説明するが、センサ５１１は、イメージセンサに限定されず、その他のセンサデバイスであってもよい。センサ５１１の例としては、例えばIoT(Internet of Things)センサとして用いられるような、加速度センサ、ジャイロセンサ、磁気センサ、臭気センサ、気圧センサ、温度センサ、湿度センサ、風速センサ、光センサ（RGBセンサ、IRセンサなど）、GPSセンサなどが挙げられる。

　エッジデバイス（Edge Device）５１２は、外部デバイスとしてのセンサ５１１を接続するデータ処理装置であり、例えばサーバ装置で構成される。エッジデバイス５１２は、センサ５１１から供給されるセンサデータを処理するアプリケーションを実行できるアプリケーションプラットフォーム（Application Platform）５３１を実装している。例えば、センサ５１１でキャプチャされたイメージデータを解析する処理等を行うアプリケーションが、アプリケーションプラットフォーム５３１上で実行される。アプリケーションプラットフォーム５３１は、その上で実行される複数のアプリケーションを管理する機能も有している。

　センサ５１１は、エッジデバイス５１２の外部デバイスとしてエッジデバイス５１２と接続される場合もあれば、エッジデバイス５１２の一部として一体に組み込まれている場合もある。以下では、センサ５１１とエッジデバイス５１２を、まとめて、センサ／エッジ５１３と称して説明する。

　クラウド５２１は、複数のノードと、それらを接続するネットワークで構成される。ネットワークは、例えば、インターネット、公衆電話回線網、所謂4G回線や5G回線等の無線移動体用の広域通信網、WAN（Wide Area Network）、LAN（Local Area Network）、Bluetooth（登録商標）規格に準拠した通信を行う無線通信網、NFC（Near Field Communication）等の近距離無線通信の通信路、赤外線通信の通信路、HDMI（登録商標）（High-Definition Multimedia Interface）やUSB（Universal Serial Bus）等の規格に準拠した有線通信の通信網等、任意の通信規格の通信網や通信路で構成される。クラウド５２１を構成する各ノードは、例えば、センサデバイス、ルータ、モデム、ハブ、ブリッジ、スイッチングハブ、基地局制御装置、交換機、サーバなどのネットワーク接続装置で構成される。ノードとしてのネットワーク接続装置が、以下で説明するアプリケーションプラットフォーム５３２、ネットワークモニタ５３３、アプリケーションプラットフォーム５３４、ネットワークモニタ５３５、オーケストレータ５３６、または、アプリケーションリポジトリ５３７として機能する。

　クラウド５２１には、センサデータをネットワークに注入するセンサ／エッジ５１３に近いエッジ側に配置されたエッジクラウド（Edge Cloud）５２２と、それ以外のコアネットワークに配置されたセンタークラウド（Center Cloud）５２３とが含まれる。エッジクラウド５２２は、例えば、ネットワークが携帯電話通信網である場合は基地局などで構成される。

　エッジクラウド５２２は、センサ５１１から供給されるセンサデータを処理するアプリケーションを実行できるアプリケーションプラットフォーム５３２を実装している。アプリケーションプラットフォーム５３２は、センサ／エッジ５１３のアプリケーションプラットフォーム５３１とネットワーク５３８で接続される。エッジクラウド５２２は、ネットワーク５３８の状態をモニターするネットワークモニタ（Network Monitor）５３３を有している。

　センタークラウド５２３も、センサ５１１から供給されるセンサデータを処理するアプリケーションを実行できるアプリケーションプラットフォーム５３４を実装している。アプリケーションプラットフォーム５３４は、エッジクラウド５２２のアプリケーションプラットフォーム５３２とネットワーク５３９で接続される。センタークラウド５２３は、ネットワーク５３９の状態をモニターするネットワークモニタ５３５を有している。

　オーケストレータ（Orchestrator）５３６は、アプリケーションリポジトリ５３７へアクセスし、所定のサービスを提供するアプリケーションの属性や実行イメージ（実行ファイル）を取得する。アプリケーションの属性には、例えば、計算リソース、メモリ、GPU（Graphics Processing Unit）等のハードウェアアクセラレータなど、そのアプリケーションに必要な実行環境についての情報が含まれる。

　オーケストレータ５３６は、サービス要求条件に応じて、アプリケーションを実行させる最適な場所を決定する。具体的には、オーケストレータ５３６は、アプリケーションを、センサ／エッジ５１３のアプリケーションプラットフォーム５３１、エッジクラウド５２２のアプリケーションプラットフォーム５３２、または、センタークラウド５２３のアプリケーションプラットフォーム５３４のいずれに配置するのが最適であるかを決定する。オーケストレータ５３６は、アプリケーションの実行場所として決定したアプリケーションプラットフォームに、アプリケーションの実行環境を確保し、アプリケーションを実行させる。

　アプリケーションリポジトリ（Application Repository）５３７は、所定のサービスを提供するアプリケーションの属性や実行イメージ（実行ファイル）を、サービスごとに記憶する。アプリケーションリポジトリ５３７は、実行イメージそのものを取得するのではなく、実行イメージの格納場所を示す参照アドレス等を記憶してもよい。

　以上のように構成される図１のデータ処理システム５００において、オーケストレータ５３６は、提供されるサービスの要求条件に応じて、アプリケーションを実行させる最適な場所を決定して、アプリケーションを実行させる。これにより、ネットワーク内のトラフィックを削減するとともに、データ処理するアプリケーションの処理負荷を低減させる。

　オーケストレータ５３６は、図２に示されるように、センサネットワークサービスオペレータ５４１から供給されるマニフェストをもとに、アプリケーションの最適な配置を決定する。マニフェストには、アプリケーションの配置決定のための評価軸、例えば、アプリケーション配置に際して重要視される項目や、重要視される項目の順序などが、最適配置方針として記述されている。

　例えば、ネットワーク転送遅延（処理遅延を含む）、ネットワークのトラフィック総量、アプリケーションの処理速度、実行コスト（計算コスト）、ストレージコスト、データ発生位置、のどれを優先的に抑えたいかについての情報が、最適配置方針としてマニフェストに記述される。

　また例えば、要求されたサービスに対応するアプリケーション処理の前に前処理を実行して、アプリケーションの処理負荷軽減を重視するか否かについての情報が、最適配置方針としてマニフェストに記述される。

　また例えば、センサデータの再利用性を重視するか否かについての情報が、最適配置方針としてマニフェストに記述される。センサデータの再利用性とは、例えば、複数のアプリケーションが共有してセンサデータを利用できることや、センサデータをオフラインで（別タイミングで）再度利用できることの度合いを表す。

＜２．アプリケーション配置制御のフローチャート＞
　図３のフローチャートを参照して、アプリケーションの最適配置を決定するアプリケーション配置制御について説明する。

　なお、この処理の開始前には、オーケストレータ５３６がアプリケーションリポジトリ５３７へアクセスし、実行予定のアプリケーションに必要な実行環境についての情報が取得済みであるとする。

　初めに、センサ５１１は、ステップＳ１０１において、“Capture Data”によりセンサデータの生成を検出し、それをトリガにして、ステップＳ１０２において、“Request App Instantiation”を実行する。“Request App Instantiation”では、アプリケーションの最適な配置での起動を依頼する“App Requirements”が、センサ５１１からオーケストレータ５３６へ送信される。アプリケーションが行う処理は、例えば、センサ５１１で得られた画像の解析処理や、画像中のオブジェクトを認識する処理などとすることができる。

　ステップＳ１０３において、オーケストレータ５３６は、“Evaluate & Determine Target App Platform”を実行する。すなわち、オーケストレータ５３６は、センサネットワークサービスオペレータ５４１から供給されたマニフェストに基づいて、アプリケーションを実行する最適なアプリケーションプラットフォームを、センサ／エッジ５１３上、エッジクラウド５２２上、または、センタークラウド５２３上のなかから探索し、決定する。この際、オーケストレータ５３６は、エッジクラウド５２２のネットワークモニタ５３３から、アプリケーションプラットフォーム５３１と５３２との間のネットワーク５３８のトラフィックの状態を取得し、ネットワークモニタ５３５から、アプリケーションプラットフォーム５３２と５３４との間のネットワーク５３９のトラフィックの状態を取得した上で、最適なアプリケーションプラットフォームを決定する。ここでは、エッジクラウド５２２上のアプリケーションプラットフォーム５３２が、最適な実行場所であると決定されたとする。

　オーケストレータ５３６は、ステップＳ１０４において、エッジクラウド５２２上のアプリケーションプラットフォーム５３２に対して、“Request App Resource Reservation”を送信し、アプリケーションに必要な実行環境を、アプリケーションプラットフォーム５３２に確保させる。アプリケーションプラットフォーム５３２は、“Request App Resource Reservation”にしたがい、アプリケーションに必要な実行環境を確保する。

　オーケストレータ５３６は、ステップＳ１０５において、エッジクラウド５２２上のアプリケーションプラットフォーム５３２に対して、“Request App Instantiation”を実行する。すなわち、オーケストレータ５３６は、アプリケーションの起動を依頼する“App Requirements”を、アプリケーションプラットフォーム５３２に送信する。

　エッジクラウド５２２上のアプリケーションプラットフォーム５３２は、ステップＳ１０６において、アプリケーションを起動、実行する。アプリケーションプラットフォーム５３２で起動されたアプリケーションは、ステップＳ１０７において、センサ５１１に対して“Inform App Ready”を送信し、アプリケーションが起動されたこと、換言すれば、処理の準備ができたことを通知する。

　“Inform App Ready”を受信したセンサ５１１は、ステップＳ１０８において、“Send Data”、すなわち、センサデータを、エッジクラウド５２２上のアプリケーションプラットフォーム５３２のアプリケーションへ、ネットワーク５３８を介して送信する。

　アプリケーションプラットフォーム５３２のアプリケーションは、ステップＳ１０９において、センサ５１１から送信されてきたセンサデータを取得し、所定のデータ処理を実行する（“Process Data”）。

　ステップＳ１０８におけるセンサデータの送信と、ステップＳ１０９におけるセンサデータのデータ処理は、センサ５１１でセンサデータが生成される間、継続して実行される。その間、オーケストレータ５３６は、ステップＳ１１０において、アプリケーションの実行状態、および、センサ／エッジ５１３とエッジクラウド５２２のアプリケーションプラットフォーム間のネットワーク５３８の状態を確認する。

　そして、ステップＳ１１１において、オーケストレータ５３６は、現在のアプリケーションの実行場所が最適であるか、換言すれば、ステップＳ１０３で決定したアプリケーションの最適配置の判断に変更がないかを判定する。ステップＳ１１１で、アプリケーションの最適配置の判断に変更がないと判定された場合、エッジクラウド５２２上のアプリケーションプラットフォーム５３２でのアプリケーションの実行が継続される。

　一方、アプリケーションの実行状態やネットワーク５３８の状態に変化が発生し、ステップＳ１１１で、オーケストレータ５３６が、現在のアプリケーションの実行場所が最適ではないと判定した場合、処理がステップＳ１１２へ進められる。

　ステップＳ１１２において、オーケストレータ５３６は、“Evaluate & Determine Target App Platform”を実行する。すなわち、オーケストレータ５３６は、センサネットワークサービスオペレータ５４１から供給されたマニフェストに基づいて、アプリケーションを実行する最適なアプリケーションプラットフォームを、再度、探索して決定する。ここでは、センタークラウド５２３上のアプリケーションプラットフォーム５３４が、最適な実行場所であると決定されたとする。

　オーケストレータ５３６は、ステップＳ１１３において、センタークラウド５２３上のアプリケーションプラットフォーム５３４に対して、“Request App Resource Reservation”を送信し、アプリケーションに必要な実行環境を、アプリケーションプラットフォーム５３４に確保させる。アプリケーションプラットフォーム５３４は、“Request App Resource Reservation”にしたがい、アプリケーションに必要な実行環境を確保する。

　オーケストレータ５３６は、ステップＳ１１４において、センタークラウド５２３上のアプリケーションプラットフォーム５３４に対して、“Request App Instantiation”を実行する。すなわち、オーケストレータ５３６は、アプリケーションの起動を依頼する“App Requirements”を、アプリケーションプラットフォーム５３４に送信する。ここで、オーケストレータ５３６は、エッジクラウド５２２上のアプリケーションプラットフォーム５３２で実行されていたアプリケーションの状態情報を、センタークラウド５２３上のアプリケーションプラットフォーム５３４のアプリケーションにコピーして同期させることができる。

　センタークラウド５２３上のアプリケーションプラットフォーム５３４は、ステップＳ１１５において、アプリケーションを起動、実行する。アプリケーションプラットフォーム５３４で起動されたアプリケーションは、ステップＳ１１６において、センサ５１１に対して“Inform App Ready”を送信し、アプリケーションが起動されたこと、換言すれば、処理の準備ができたことを通知する。

　“Inform App Ready”を受信したセンサ５１１は、ステップＳ１１７において、“Capture & Send Data”、すなわち、センサデータの生成を検出し、検出したセンサデータを、センタークラウド５２３上のアプリケーションプラットフォーム５３４のアプリケーションへ、ネットワーク５３８および５３９を介して送信する。

　アプリケーションプラットフォーム５３４のアプリケーションは、ステップＳ１１８において、センサ５１１から送信されてきたセンサデータを取得し、所定のデータ処理を実行する（“Process Data”）。

　ステップＳ１１７におけるセンサデータの送信と、ステップＳ１１８におけるセンサデータのデータ処理は、センサ５１１でセンサデータが生成される間、継続して実行される。

　以下同様に、ステップＳ１１０ないしＳ１１３の処理、すなわち、現在のアプリケーションの実行場所が最適であるかどうかを判定し、最適ではないと判定された場合に、最適なアプリケーションプラットフォームを、再度探索して、最適な配置でアプリケーションを実行する処理が継続される。オーケストレータ５３６は、ネットワークに参加するセンサ／エッジ５１３の増大や、センサ５１１で生成されるセンサデータの増大が発生した場合でも、ネットワーク全体のトラフィックや処理負荷の状態を監視し、負荷に追従したネットワーク制御(障害回復およびメンテナンスを含む。)を行うことができる。

＜３．最適配置の評価軸と配置方針＞
　上述したように、オーケストレータ５３６は、“Evaluate & Determine Target App Platform”の処理において、センサネットワークサービスオペレータ５４１から供給されたマニフェストに基づいて、アプリケーションを実行するのに最適なアプリケーションプラットフォームの場所を決定する。

　以下では、マニフェストに記載された、アプリケーションの配置決定のための評価軸の例と、その評価軸におけるアプリケーションの配置方針について、具体的に説明する。なお、以下の説明では、センサ／エッジ５１３上、エッジクラウド５２２上、または、センタークラウド５２３上の各アプリケーションプラットフォーム５３１、５３２、および５３４を、簡単のため、プラットフォーム５３１、５３２、および５３４と称して説明する。

＜本アプリケーションの配置方針＞
　図４は、アプリケーションを、センサ／エッジ５１３上、エッジクラウド５２２上、または、センタークラウド５２３上の各プラットフォームに配置した例を示している。

　具体的には、図４に示される配置（１）は、アプリケーションを、センサ／エッジ５１３上のプラットフォーム５３１に配置して実行する配置例を示している。配置（２）は、アプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置して実行する配置例を示している。配置（３）は、アプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。

　図４において、“Application”は、センサ５１１で得られた画像の解析処理や、画像中のオブジェクトを認識する処理など、要求されたサービスに対応する処理（以下、本処理と称する。）を実行するアプリケーションの配置場所を示している。“Capture & Send Data”は、センサ５１１による図３のステップＳ１０１およびＳ１０８と同様の、センサデータの生成を検出してアプリケーションへ送信する処理を示している。“Process Data”は、図３のステップＳ１０９やＳ１１８と同様の、センサ５１１から送信されてきたセンサデータを取得して本処理を実行する処理を示している。

　最適配置方針として、ネットワーク転送遅延による処理遅延をできるだけ小さくすることがマニフェストに記述されている場合について考える。ネットワーク転送遅延による処理遅延は、センサ５１１に近い方ほど小さくなる。換言すれば、センサ／エッジ５１３上のプラットフォーム５３１、エッジクラウド５２２上のプラットフォーム５３２、センタークラウド５２３上のプラットフォーム５３４の順に、転送遅延が大きくなる。

　したがって、ネットワーク転送遅延による処理遅延をできるだけ小さくしたい場合、オーケストレータ５３６は、配置（１）を最優先にし、配置（１）、配置（２）、配置（３）の優先順でアプリケーションを配置する。

　最適配置方針として、ネットワークのトラフィックの総量をできるだけ小さくすることがマニフェストに記述されている場合について考える。ネットワークのトラフィックの総量は、センサ５１１に近い方ほど小さくなる。換言すれば、センサ／エッジ５１３上のプラットフォーム５３１、エッジクラウド５２２上のプラットフォーム５３２、センタークラウド５２３上のプラットフォーム５３４の順に、ネットワークトラフィックの総量が大きくなる。

　したがって、ネットワークのトラフィックの総量をできるだけ小さくしたい場合、オーケストレータ５３６は、配置（１）を最優先にし、配置（１）、配置（２）、配置（３）の優先順でアプリケーションを配置する。

　ネットワーク転送遅延による処理遅延と、ネットワークトラフィックの総量の両方をできるだけ小さくできれば、他の要件は無視できることが、最適配置方針としてマニフェストに記述されている場合にも、オーケストレータ５３６は、配置（１）を最優先にし、配置（１）、配置（２）、配置（３）の優先順でアプリケーションを配置することができる。

　最適配置方針として、アプリケーションの処理速度をできるだけ速くすることがマニフェストに記述されている場合について考える。アプリケーションの処理速度は、アプリケーションの実行環境の違いによっても異なるが、センサ／エッジ５１３上のプラットフォーム５３１、エッジクラウド５２２上のプラットフォーム５３２、センタークラウド５２３上のプラットフォーム５３４の順に大きくなる。

　したがって、ネットワークインタフェースから渡された後のアプリケーション処理速度をできるだけ速くしたいという要件の下では、オーケストレータ５３６は、配置（３）を最優先にし、配置（３）、配置（２）、配置（１）の優先順でアプリケーションを配置する。

　最適配置方針として、アプリケーションを実行するのに必要なコストであるアプリケーションの実行コストをできるだけ小さくすることがマニフェストに記述されている場合について考える。アプリケーションの実行コストは、アプリケーションの実行環境の違いによっても異なるが、センタークラウド５２３に近い方が計算資源が豊富となるため安くなる。すなわち、実行コストは、センサ／エッジ５１３上のプラットフォーム５３１、エッジクラウド５２２上のプラットフォーム５３２、センタークラウド５２３上のプラットフォーム５３４の順に低くなる。

　したがって、アプリケーションの実行コストをできるだけ小さくしたいという要件の下では、オーケストレータ５３６は、配置（３）を最優先にし、配置（３）、配置（２）、配置（１）の優先順でアプリケーションを配置する。

　センサデータを一時的または永続的にストレージに格納しておき、多目的に利用する場合や、経路上のネットワークが不安定な場合に一時的にキャッシュしておいてから転送するストアアンドフォワードを行う場合などでは、センサデータを記憶するストレージが必要となる。ストレージを確保することにもコストがかかる。最適配置方針として、ストレージコストをできるだけ低くすることがマニフェストに記述されている場合について考える。ストレージコストも、センタークラウド５２３に近い方が計算資源が豊富となるため安くなるため、センサ／エッジ５１３上のプラットフォーム５３１、エッジクラウド５２２上のプラットフォーム５３２、センタークラウド５２３上のプラットフォーム５３４の順に低くなる。

　したがって、ストレージコストをできるだけ低くしたいという要件の下では、オーケストレータ５３６は、配置（３）を最優先にし、配置（３）、配置（２）、配置（１）の優先順でアプリケーションを配置する。

　アプリケーション処理速度をできるだけ速く、アプリケーションの実行コストをできるだけ小さく、または、ストレージコストをできるだけ低く、の２つ以上を満たせば、他の要件は無視できることが、最適配置方針としてマニフェストに記述されている場合にも、オーケストレータ５３６は、配置（３）を最優先にし、配置（３）、配置（２）、配置（１）の優先順でアプリケーションを配置することができる。

＜前処理がある場合のアプリケーションの配置方針＞
　図４で説明したアプリケーションの配置方針は、配置するアプリケーションを、本処理を実行する１つのアプリケーションのみとした場合の例であった。

　次に、本処理の前の前処理として非圧縮のセンサデータを圧縮する処理（以下、圧縮処理と称する。）を実行するアプリケーションと、本処理を実行するアプリケーションの２つのアプリケーションを配置する場合の配置方針について説明する。

　図５は、２つのアプリケーションを、センサ／エッジ５１３上、エッジクラウド５２２上、または、センタークラウド５２３上の各プラットフォームに配置した例を示している。

　図５において、“Application”は、本処理を実行するアプリケーションの配置場所を示している。“Application(Compressor)”は、圧縮処理を実行するアプリケーションの配置場所を示している。“Capture & Send Data”は、センサ５１１がセンサデータの生成を検出してアプリケーションへ送信する処理を示している。“Application(Compressor)”が配置されたプラットフォームの“Process & Send Data”は、圧縮処理を実行するアプリケーションが、圧縮処理を実行して、本処理を実行するアプリケーションへ送信する処理を示している。“Process Data”は、圧縮処理後のセンサデータを取得して本処理を実行する処理を示している。

　図５に示される配置（１１）は、圧縮処理を行うアプリケーションを、センサ／エッジ５１３上のプラットフォーム５３１に配置し、本処理を行うアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置して実行する配置例を示している。配置（１２）は、圧縮処理を行うアプリケーションを、センサ／エッジ５１３上のプラットフォーム５３１に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。配置（１３）は、圧縮処理を行うアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。

　図５において、センサデータの転送を示す矢印の太さは、圧縮処理の有無による帯域幅の違いを示しており、非圧縮データの方が、圧縮データよりも広い帯域が必要となる。また、圧縮処理を行う場合には、非圧縮の場合と比べて、ネットワークへ転送する前の遅延が生じる。

　配置（１１）は、配置（１２）および配置（１３）と比較して、ネットワーク転送遅延による処理遅延およびネットワークトラフィックについては、より小さくなるが、アプリケーション処理速度はより遅く、実行コストはより高く、ストレージコストはより高くなる。

　配置（１２）は、配置（１１）と比較して、ネットワーク転送遅延による処理遅延はより大きく、ネットワークトラフィックはより増加するが、アプリケーション処理速度はより速く、実行コストはより低く、ストレージコストはより低くなる。また、配置（１２）は、配置（１３）と比較して、ネットワーク転送遅延による処理遅延はより小さく、ネットワークトラフィックはより低くなるが、アプリケーション処理速度はより遅く、実行コストはより高く、ストレージコストはより高くなる。

　配置（１３）は、配置（１１）および配置（１２）と比較して、ネットワーク転送遅延による処理遅延はより大きく、ネットワークトラフィックはより増加するが、アプリケーション処理速度はより速く、実行コストはより低く、ストレージコストはより低くなる。

　以上より、本処理を実行するアプリケーションと、本処理の前の前処理として圧縮処理を実行するアプリケーションの２つのアプリケーションを配置する場合、ネットワーク転送遅延による処理遅延、および／または、ネットワークトラフィックをより小さくしたいという要件の下では、オーケストレータ５３６は、配置（１１）を最優先にし、配置（１１）、配置（１２）、配置（１３）の優先順でアプリケーションを配置する。また、アプリケーション処理速度をより速く、実行コストをより低く、ストレージコストをより低くしたいという要件の下では、オーケストレータ５３６は、配置（１３）を最優先にし、配置（１３）、配置（１２）、配置（１１）の優先順でアプリケーションを配置する。

＜個別化処理がある場合のアプリケーションの配置方針＞
　次に、本処理の前の前処理として高度なAI(artificial intelligence)処理等により本処理の内容に合わせて個別化された処理（以下、個別化処理と称する。）を実行するアプリケーションと、本処理を実行するアプリケーションの２つのアプリケーションを配置する場合の配置方針について説明する。

　図６は、２つのアプリケーションを、センサ／エッジ５１３上、エッジクラウド５２２上、または、センタークラウド５２３上の各プラットフォームに配置した例を示している。

　図６において、“Application”は、本処理を実行するアプリケーションの配置場所を示している。“Application(Post Processor)”は、個別化処理を実行するアプリケーションの配置場所を示している。“Capture & Send Data”は、センサ５１１がセンサデータの生成を検出してアプリケーションへ送信する処理を示している。“Application(Post Processor)”が配置されたプラットフォームの“Process & Send Data”は、個別化処理を実行するアプリケーションが、個別化処理を実行して、本処理を実行するアプリケーションへ送信する処理を示している。“Process Data”は、個別化処理後のセンサデータを取得して本処理を実行する処理を示している。

　本処理の内容に合わせた個別化処理は、センサデータの特徴量を抽出する特徴量抽出処理や、センサデータの特徴を認識する特徴認識処理、例えば、画像内のオブジェクトを認識して、オブジェクトの場所または形状を出力する処理などとすることができる。個別化処理は、図５で説明した前処理である圧縮処理よりもはるかに大きな圧縮効果を期待できるが、ネットワーク転送前の遅延が大きくなる。

　図６に示される配置（２１）は、個別化処理を行うアプリケーションを、センサ／エッジ５１３上のプラットフォーム５３１に配置し、本処理を行うアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置して実行する配置例を示している。配置（２２）は、個別化処理を行うアプリケーションを、センサ／エッジ５１３上のプラットフォーム５３１に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。配置（２３）は、個別化処理を行うアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。

　図６において、センサデータの転送を示す矢印の太さは、個別化処理の有無による帯域幅の違いを示しており、個別化処理データの方が、圧縮データおよび非圧縮データよりも狭い帯域で伝送可能となる。

　配置（２１）は、配置（２２）および配置（２３）と比較して、ネットワーク転送遅延による処理遅延およびネットワークトラフィックについては、より小さくなるが、アプリケーション処理速度はより遅く、実行コストはより高く、ストレージコストはより高くなる。

　配置（２２）は、配置（２１）と比較して、ネットワーク転送遅延による処理遅延はより大きく、ネットワークトラフィックはより増加するが、アプリケーション処理速度はより速く、実行コストはより低く、ストレージコストはより低くなる。また、配置（２２）は、配置（２３）と比較して、ネットワーク転送遅延による処理遅延はより小さく、ネットワークトラフィックはより低くなるが、アプリケーション処理速度はより遅く、実行コストはより高く、ストレージコストはより高くなる。

　配置（２３）は、配置（２１）および配置（２２）と比較して、ネットワーク転送遅延による処理遅延はより大きく、ネットワークトラフィックはより増加するが、アプリケーション処理速度はより速く、実行コストはより低く、ストレージコストはより低くなる。

　以上より、本処理を実行するアプリケーションと、本処理の前の前処理として個別化処理を実行するアプリケーションの２つのアプリケーションを配置する場合、ネットワーク転送遅延による処理遅延、および／または、ネットワークトラフィックをより小さくしたいという要件の下では、オーケストレータ５３６は、配置（２１）を最優先にし、配置（２１）、配置（２２）、配置（２３）の優先順でアプリケーションを配置する。また、アプリケーション処理速度をより速く、実行コストをより低く、ストレージコストをより低くしたいという要件の下では、オーケストレータ５３６は、配置（２３）を最優先にし、配置（２３）、配置（２２）、配置（２１）の優先順でアプリケーションを配置する。

　図７は、前処理として圧縮処理を行う図５のアプリケーション配置例と、前処理として個別化処理を行う図６のアプリケーション配置例を、図６を上、図５を下に配置して並べた図である。

　配置（２１）と配置（１１）どうし、配置（２２）と配置（１２）どうし、または、配置（２３）と配置（１３）どうしの、前処理を実行するアプリケーションと本処理を実行するアプリケーションの配置が同じものどうしを比較する。

　配置（２１）は、配置（１１）と比べて、ネットワークトラフィックをより小さくすることができる。同様に、配置（２２）は、配置（１２）と比べて、ネットワークトラフィックをより小さくすることができ、配置（２３）は、配置（１３）と比べて、ネットワークトラフィックをより小さくすることができる。

　以上より、前処理として個別化処理を行うアプリケーションを導入すると、前処理として圧縮処理を行うアプリケーションを導入する場合と比べて、よりネットワークトラフィックの低減効果を期待できると言える。なお、例えば配置（２３）と配置（１１）との比較のような、アプリケーションの配置が異なるものどうしについては単純に比較することができない。

＜個別化処理を多段配置した場合のアプリケーションの配置方針＞
　図８および図９は、本処理の前の前処理として個別化処理を実行するアプリケーションを配置する図６の配置例のバリエーション例を示している。

　図８に示される配置（３１）のように、個別化処理を行うアプリケーションを、本処理を行うアプリケーションの前段に複数配置するアプリケーション配置を採用することができる。具体的には、配置（３１）では、第１の個別化処理を行うアプリケーションが、センサ／エッジ５１３上のプラットフォーム５３１に配置され、第２の個別化処理を行うアプリケーションが、エッジクラウド５２２上のプラットフォーム５３２に配置され、本処理を行うアプリケーションが、センタークラウド５２３上のプラットフォーム５３４に配置されている。

　個別化処理を行うアプリケーションの多段配置は、より抽象度の高い個別化処理(AI処理)を段階的に行うことができ、アプリケーションの個別の要件に応じてより最適化したデータを、最終的に本処理を行うアプリケーションに届けることができる。ただし、段階的な個別化処理の実行により、処理遅延は大きくなる。一点鎖線の矢印は、細実線の矢印よりもネットワークトラフィックが小さいことを示している。

　個別化処理を行うアプリケーションを多段に配置する例としては、次のようなケースがある。

・複雑な軌跡を持つオブジェクトを特定するケース
　センサ／エッジ５１３上のプラットフォーム５３１のアプリケーションが、オブジェクト(ROI)抽出を行い、エッジクラウド５２２上のプラットフォーム５３２のアプリケーションが、複数オブジェクトの軌跡トラッキングを行い、センタークラウド５２３上のプラットフォーム５３４のアプリケーションが、オブジェクトの内容理解と対象オブジェクトの特定を行う。

・観測対象のオブジェクトの種類を特定してその軌跡推定を行うケース
　センサ／エッジ５１３上のプラットフォーム５３１のアプリケーションが、オブジェクト(ROI)抽出を行い、エッジクラウド５２２上のプラットフォーム５３２のアプリケーションが、オブジェクト内容理解と対象オブジェクトの特定および特定オブジェクトの軌跡トラッキングを行い、センタークラウド５２３上のプラットフォーム５３４のアプリケーションが、対象オブジェクトの軌跡推定を行う。

　このように、アプリケーションの個別の要件に合わせて、個別化の種類、抽象度のレベルを決定し、かつ、その処理の複雑度に応じた計算コスト等を考慮に入れて、アプリケーションを、複数のプラットフォームに最適に配置することができる。

　図９は、オブジェクト検知、オブジェクト内容理解/分類、オブジェクト軌跡トラッキング、および、軌跡推定の順番で処理が行われるケースで、アプリケーションを多段配置と一段配置で配置した例を示している。

　図９において、“Object Detection”は、オブジェクト検知の処理を行うことを示しており、“Object Classification”は、オブジェクト内容理解および分類の処理を行うことを示している。“Object Tracking”は、オブジェクト軌跡トラッキングの処理を行うことを示しており、“Motion Estimation”は、軌跡推定の処理を行うことを示している。

　配置（３１１）は、オブジェクト検知、オブジェクト内容理解/分類、および、オブジェクト軌跡トラッキングを、センサ／エッジ５１３上のプラットフォーム５３１に配置した個別化処理を行うアプリケーションが実行し、軌跡推定を、センタークラウド５２３上のプラットフォーム５３４に配置した本処理を行うアプリケーションが実行する配置例を示している。

　配置（３１２）は、オブジェクト検知を、センサ／エッジ５１３上のプラットフォーム５３１に配置した個別化処理を行うアプリケーションが実行し、オブジェクト内容理解/分類、および、オブジェクト軌跡トラッキングを、エッジクラウド５２２上のプラットフォーム５３２に配置した個別化処理を行うアプリケーションが実行し、軌跡推定を、センタークラウド５２３上のプラットフォーム５３４に配置した本処理を行うアプリケーションが実行する配置例を示している。

　配置（３１３）は、オブジェクト検知、オブジェクト内容理解/分類、オブジェクト軌跡トラッキング、および、軌跡推定の全てを、センタークラウド５２３上のプラットフォーム５３４に配置した本処理を行うアプリケーションが実行する配置例を示している。配置（３１３）は、図４の配置（３）と同じである。

　ネットワークのトラフィックの総量は、矢印の太さで示されるように、配置（３１１）、配置（３１２）、配置（３１３）の順に大きくなる。一点鎖線の矢印は、細実線の矢印よりもネットワークトラフィックが小さいことを示している。

　ネットワークのトラフィックの総量をできるだけ小さくすることが、最適配置方針としてマニフェストに記述されている場合、オーケストレータ５３６は、配置（３１１）を最優先にし、配置（３１１）、配置（３１２）、配置（３１３）の優先順でアプリケーションを配置する。

　アプリケーション処理速度をより速く、実行コストをより低く、ストレージコストをより低くすることが、最適配置方針としてマニフェストに記述されている場合、オーケストレータ５３６は、配置（３１３）を最優先にし、配置（３１３）、配置（３１２）、配置（３１１）の優先順でアプリケーションを配置する。

　なお、オブジェクト検知、オブジェクト内容理解/分類、オブジェクト軌跡トラッキング、および、軌跡推定の４つの処理を、複数の個別化処理を行うアプリケーションで分散して実行させる配置例は、上述した配置（３１２）の配置例以外も取り得ることは言うまでもない。

＜再利用性を重視する場合のアプリケーションの配置方針＞
　次に、図１０を参照して、再利用性を重視する場合のアプリケーションの配置方針について説明する。

　センサデータの再利用性を重視する場合があり得る。すなわち、センサ５１１が生成したセンサデータを、複数のアプリケーションで共有して利用したり、センサデータ生成時から一定時間経過後の別タイミングで、オフラインでセンサデータを利用できることを優先したい場合がある。

　センサデータの再利用性を考慮しない場合、生成されたセンサデータは、そのデータを利用するアプリケーションまで届ければよいので、図１０に示される配置（４１）のように、P2P(Peer to Peer)で、センサ／エッジ５１３上、エッジクラウド５２２上、または、センタークラウド５２３上のいずれかに配置されたアプリケーションへ転送される。図１０の配置（４１）は、図４に示した配置（１）ないし（３）と同一である。

　これに対して、センサデータの再利用性を重視する場合、図１０に示される配置（４２）のように、本処理の前の前処理として、センサデータを一時的または永続的にキャッシュ（記憶）するアプリケーションが配置される。配置（４２）は、センサデータを一時的または永続的にキャッシュするアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。

　図１０において、“Application”は、本処理を実行するアプリケーションの配置場所を示している。“Application(Broker)”は、センサデータを一時的または永続的にキャッシュするアプリケーションの配置場所を示している。配置（４２）では、センサ／エッジ５１３から送信されたセンサデータが、エッジクラウド５２２上のプラットフォーム５３２に配置されたアプリケーションへ転送される。エッジクラウド５２２上のアプリケーションは、取得したセンサデータを一時的または永続的にキャッシュするとともに、センタークラウド５２３上のプラットフォーム５３４に配置された３つのアプリケーションに送信する。センタークラウド５２３上の３つのアプリケーションが実行する本処理は、同一の処理でもよいし、異なる処理でもよい。同一の処理を実行する場合には、例えば、時間がかかるが低コストで実行できるアプリケーションと、高コストで高速に実行できるアプリケーションなど、処理の性能が異なる場合がある。

　以上より、センサデータの再利用性を重視する（再利用性を上げる）という要件の下では、オーケストレータ５３６は、配置（４２）を最優先にし、配置（４２）、配置（４１）の優先順でアプリケーションを配置する。

　さらに、センサデータの再利用性を重視することを前提として、図５および図６に示したような圧縮処理や個別化処理をさらに行うことにより、ネットワークトラフィックを最小化または低減することもあり得る。

　図１１は、センサデータの再利用性と、圧縮処理または個別化処理を併用した場合のアプリケーションの配置例を示している。

　具体的には、図１１に示される配置（５１）は、センサデータを一時的または永続的にキャッシュするアプリケーションと、圧縮処理を行うアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。エッジクラウド５２２上のプラットフォーム５３２では、センサデータをキャッシュするアプリケーションの後段に、圧縮処理を行うアプリケーションが配置される。

　配置（５２）は、センサデータを一時的または永続的にキャッシュするアプリケーションと、個別化処理を行うアプリケーションを、エッジクラウド５２２上のプラットフォーム５３２に配置し、本処理を行うアプリケーションを、センタークラウド５２３上のプラットフォーム５３４に配置して実行する配置例を示している。エッジクラウド５２２上のプラットフォーム５３２では、センサデータをキャッシュするアプリケーションの後段に、個別化処理を行うアプリケーションが配置される。

　図１１の配置（５１）および配置（５２）では、圧縮処理を行うアプリケーションまたは個別化処理を行うアプリケーションが、センタークラウド５２３上のプラットフォーム５３４に配置された３つのアプリケーションそれぞれに対して設けられている。これらの圧縮処理または個別化処理を行う３つのアプリケーションは、アプリケーションの要件に応じて、異なる圧縮処理または個別化処理を行う。仮に、同一の圧縮処理または個別化処理を実行すればよい場合には、これらの前処理を行うアプリケーションは１つとすることができる。

　図７を参照して説明したように、ネットワークのトラフィックの総量は、圧縮処理よりも個別化処理を行う方が小さくすることができる。したがって、矢印の太さで示されるように、配置（５２）は、配置（５１）と比べて、ネットワークトラフィックをより小さくすることができる。

　以上より、センサデータの再利用性を重視する（再利用性を上げる）という要件の下で、さらに、ネットワークトラフィックをより低減させる場合には、オーケストレータ５３６は、配置（５２）を最優先にし、配置（５２）、配置（５１）の優先順でアプリケーションを配置する。

＜評価軸とアプリケーションの配置方針のまとめ＞
　図１２は、図４ないし図１１で説明した、アプリケーションを配置する際の評価軸と、その場合のアプリケーション配置の優先順位（配置方針）をまとめたテーブルである。評価軸としては、ネットワーク転送遅延による処理遅延、ネットワークのトラフィック、アプリケーションの処理速度、アプリケーションの実行コスト、ストレージコスト、センサデータの再利用性、要求されたサービスに対応する本処理を実行する前に前処理を実行するか、が含まれる。なお、これらの評価軸と優先順位との組は、全てが含まれなくてもよく、少なくとも１つが含まれていればよい。アプリケーション配置の優先順位は、アプリケーション配置場所としての、センサ／エッジ５１３、エッジクラウド５２２、および、センタークラウド５２３の優先順位である。

　図１２で示される情報が、マニフェストとして、センサネットワークサービスオペレータ５４１からオーケストレータ５３６へ供給される。オーケストレータ５３６は、供給されたマニフェストに基づいて、さまざまなトレードオフを考慮し、アプリケーションの最適配置を行う。

　すなわち、オーケストレータ５３６は、図３を参照して説明したアプリケーション配置制御の“Evaluate & Determine Target App Platform”の処理において、図１２の配置方針に基づいて、アプリケーションを実行する最適なアプリケーションプラットフォームの場所を決定する。オーケストレータ５３６は、例えば、センサデータのデータ処理を所定のプラットフォームに局所化したり、センサ／エッジ５１３、エッジクラウド５２２、またはセンタークラウド５２３の２つ以上に多段配置したり、圧縮処理や個別化処理を行ってから転送することにより、ネットワーク内のトラフィックを削減するとともに、データ処理するアプリケーションの処理負荷を低減させる。

＜４．クラウドコンピューティングの構成例＞
　上述したデータ処理システムおよびアプリケーション配置制御方法を含む本明細書に記載の方法およびシステムは、コンピュータソフトウェア、ファームウェア、ハードウェア、または、それらの組み合わせもしくはサブセットを含むコンピュータプログラミングまたはエンジニアリング技術を用いて実現することができる。

　図１３は、本明細書に記載の各種の実施の形態を実現することができるコンピュータのブロック図を示している。

　本開示は、システム、方法、および／または、コンピュータプログラムとして実現することができる。コンピュータプログラムは、コンピュータ読み取り可能な記憶媒体を含むことができ、コンピュータ読み取り可能な記憶媒体には、本実施形態の態様を１または複数のプロセッサに実行させるコンピュータ読み取り可能なプログラム命令が記録されている。

　コンピュータ読み取り可能な記憶媒体は、命令実行デバイス（プロセッサ）で使用するための命令を格納することができる有形のデバイスとすることができる。コンピュータ読み取り可能な記憶媒体は、例えば、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置、または、それらの装置の任意の適切な組み合わせとすることができるが、それらに限定されない。コンピュータ読み取り可能な記憶媒体のより具体的な例には、以下のそれぞれ（および適切な組み合わせ）が含まれる：フレキシブルディスク、ハードディスク、SSD（solid state drive）、RAM(random access memory)、ROM（read only memory）、EPROM（erasable and programmable read only memory）or Flash(フラッシュメモリ)、SRAM(static random access memory)、コンパクトディスク（CDまたはCD-ROM）、DVD（digital versatile disc）、カード型またはスティック型のメモリ。本開示で使用されるようなコンピュータ読み取り可能な記憶媒体は、電波または他の自由に伝播する電磁波、導波管または他の伝送媒体（例えば、光ファイバーケーブルを通る光パルス）を介して伝播する電磁波、または、ワイヤを介して送信される電気信号、などの一時的な信号自体であると解釈されるものではない。

　本開示のコンピュータ読み取り可能なプログラム命令は、コンピュータ読み取り可能な記憶媒体から、適切なコンピューティングデバイスまたはプロセッシングデバイスにダウンロードされたり、例えばインターネットなどのグローバルネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、および／または、ワイヤレスネットワークを介して、外部のコンピュータまたは外部の記憶装置にダウンロードされ得る。ネットワークには、銅伝送線、光通信ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、および／または、エッジサーバなどがある。コンピューティングデバイスまたはプロセッシングデバイス内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからのコンピュータ読み取り可能なプログラム命令を受信して、そのコンピュータ読み取り可能なプログラム命令を転送して、コンピューティングデバイスまたはプロセッシングデバイス内のコンピュータ読み取り可能な記憶媒体に記憶することができる。

　本開示の処理を実行するコンピュータ読み取り可能なプログラム命令には、機械語命令、および／または、マイクロコードが含まれ、それらは、アッセンブリ言語、Basic, Fortran, Java, Python, R, C, C++, C#、もしくは類似のプログラム言語を含む１または複数のグログラム言語の任意の組み合わせで記述されたソースコードからコンパイルまたは解釈される。コンピュータ読み取り可能なプログラム命令は、ユーザのパーソナルコンピュータ、ノートブックコンピュータ、タブレット、または、スマートフォン上で完全に実行することができ、遠隔のコンピュータもしくはコンピュータサーバ、または、これらのコンピューティングデバイスの任意の組み合わせ上でも完全に実行することができる。遠隔のコンピュータまたはコンピュータサーバは、ユーザのデバイス、または、ローカルエリアネットワーク、ワイドエリアネットワーク、グローバルネットワーク（例えばインターネット）などのコンピュータネットワークを介したデバイスと接続されてもよい。本開示の態様を実現するために、例えば、プログラマブルロジック回路、FPGA(field-programmable gate arrays)、PLA(programmable logic arrays)を含む電気回路が、電子回路を構成またはカスタマイズするコンピュータ読み取り可能なプログラム命令からの情報を使用して、コンピュータ読み取り可能なプログラム命令を実行することができる実施の形態もある。

　本開示の態様は、本開示の実施形態による方法、装置（システム）、およびコンピュータプログラムのフロー図およびブロック図を参照して本明細書で説明される。フロー図およびブロック図の各ブロック、ならびに、フロー図およびブロック図におけるブロックの組み合わせがコンピュータ読み取り可能なプログラム命令によって実現できることは当業者には理解されるであろう。

　本開示に記載されたシステムおよび方法を実行することができるコンピュータ読み取り可能なプログラム命令は、装置を製造するための汎用コンピュータ、専用コンピュータ、または他のプログラム可能装置の１または複数のプロセッサ（および／またはプロセッサ内の１または複数のコア）で利用される。コンピュータまたは他のプログラム可能装置のプロセッサを介してプログラム命令が実行されることにより、本開示のフロー図およびブロック図で記載された機能を実現するためのシステムが作成される。これらのコンピュータ読み取り可能なプログラム命令はまた、コンピュータ、プログラマブル装置、および／または他のデバイスに特定の方法で機能するように指示することができるコンピュータ読み取り可能な記憶媒体に格納され得る。したがって、命令が格納されたコンピュータ読み取り可能な記憶媒体は、本開示のフロー図およびブロック図で特定された機能の態様を実現する命令が含まれる製造物品である。

　コンピュータ読み取り可能なプログラム命令はまた、コンピュータ、他のプログラマブル装置、または他のデバイスにロードされて、コンピュータ、他のプログラマブル装置または他のデバイス上で一連の操作ステップを実行し、コンピュータの処理結果を生成する。プログラム命令が、コンピュータ、他のプログラマブル装置、または他のデバイス上で実行されることにより、本開示のフロー図およびブロック図で特定された機能が実現される。

　図１３は、１または複数のコンピュータやサーバなどがネットワークを介して接続されたネットワークシステム８００の機能ブロック図である。なお、図１３の実施の形態で示されているハードウェアおよびソフトウェア環境は、本開示によるソフトウェアおよび／または方法を実現するためのプラットフォームを提供する一例として示されている。

　図１３に示すように、ネットワークシステム８００は、コンピュータ８０５、ネットワーク８１０、リモートコンピュータ８１５、ウェブサーバ８２０、クラウドストレージサーバ８２５、およびコンピュータサーバ８３０を含むことができるが、これに限られない。ある実施の形態では、図１３に示される１または複数の機能ブロックのうちの複数のインスタンスが使用される。

　図１３には、コンピュータ８０５のより詳細な構成が図示されている。なお、コンピュータ８０５内に示されている機能ブロックは、例示的な機能を確立するために図示されており、全てを図示するものではない。また、リモートコンピュータ８１５、ウェブサーバ８２０、クラウドストレージサーバ８２５、およびコンピュータサーバ８３０の詳細な構成は図示されていないが、これらは、コンピュータ８０５について示されている機能ブロックと同様の構成を含むことができる。

　コンピュータ８０５としては、パーソナルコンピュータ（PC）、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ネットブックコンピュータ、携帯情報端末（PDA）、スマートフォン、または、ネットワーク８１０上の他のデバイスと通信可能な他のプログラム可能な任意の電子デバイスを用いることができる。

　そして、コンピュータ８０５は、プロセッサ８３５、バス８３７、メモリ８４０、不揮発性ストレージ８４５、ネットワークインタフェース８５０、周辺機器インタフェース８５５、および、ディスプレイインターフェース８６５を備えて構成される。これらの機能の各々は、ある実施の形態では、個々の電子サブシステム（集積回路チップまたはチップと関連デバイスの組み合わせ）として実装され、他の実施形態では、いくつかの機能が組み合わせられて単一チップ（システムオンチップまたはSoC（System on Chip））として実装されてもよい。

　プロセッサ８３５は、例えば、Intel Corporation, Advanced Micro Devices, Inc.(AMD), Arm Holdings(Arm), Apple Computerなどにより設計および／または製造されるような、１または複数のシングルまたはマルチチップのマイクロプロセッサとすることができる。マイクロプロセッサの例としては、Intel Corporation製のCeleron, Pentium, Core i3, Core i5やCore i7、AMD製のOpteron, Phenom, Athlon, TurionやRyzen、Arm製のCortex-A, Cortex-RやCortex-Mが挙げられる。

　バス８３７は、例えば、ISA,PCI,PCI Express(PCI-e),AGPなどの、独自仕様または業界標準の高速パラレルまたはシリアル周辺相互接続バスを採用することができる。

　メモリ８４０および不揮発性ストレージ８４５は、コンピュータが読み取り可能なストレージ媒体である。メモリ８４０は、DRAM（Dynamic Random Access Memory）やSRAM（Static RAM）などの任意の適切な揮発性ストレージデバイスを採用することができる。不揮発性ストレージ８４５は、フレキシブルディスク、ハードディスク、SSD（Solid State Drive）、ROM（Read Only Memory）、EPROM（Erasable and Programmable Read Only Memory）、フラッシュメモリ、コンパクトディスク（CDまたはCD-ROM）、DVD（Digital Versatile Disc）、カード型メモリ、またはスティック型メモリのうち、１つ以上を採用することができる。

　また、プログラム８４８は、機械読み取り可能命令および／またはデータの集合である。この集合は、不揮発性ストレージ８４５に格納され、本開示で詳細に説明したり、図面に記載した特定のソフトウェア機能を作成、管理、および制御するために使用される。なお、メモリ８４０が不揮発性ストレージ８４５よりも非常に高速である構成では、プログラム８４８を、プロセッサ８３５により実行される前に、不揮発性ストレージ８４５からメモリ８４０に転送することができる。

　コンピュータ８０５は、ネットワークインタフェース８５０を介して、ネットワーク８１０を介した他のコンピュータとの通信および相互作用をすることができる。ネットワーク８１０は、例えば、LAN（Local Area Network）、インターネットなどのWAN（Wide Area Network）、または、LANおよびWANの組み合わせで、有線、無線、または光ファイバー接続が含まれた構成を採用することができる。一般に、ネットワーク８１０は、２つ以上のコンピュータと関連デバイス間の通信をサポートする接続およびプロトコルの任意の組み合わせからなる。

　周辺機器インタフェース８５５は、コンピュータ８０５にローカルに接続され得る他のデバイスとのデータの入出力を行うことができる。例えば、周辺機器インタフェース８５５は、外部デバイス８６０への接続を提供する。外部デバイス８６０には、キーボード、マウス、キーパッド、タッチスクリーン、および/または、その他の適切な入力デバイスが用いられる。外部デバイス８６０は、例えば、サムドライブ、ポータブル光学ディスクまたは磁気ディスク、およびメモリカードなどのポータブルコンピュータ可読記憶媒体も含み得る。本開示の実施の形態を実現するソフトウェアおよびデータ、例えば、プログラム８４８は、そのようなポータブルコンピュータ可読記憶媒体に記憶されてもよい。そのような実施形態では、ソフトウェアは、不揮発性ストレージ８４５上にロードされてもよいし、代わりに、周辺機器インタフェース８５５を介してメモリ８４０上に直接ロードされてもよい。周辺機器インタフェース８５５は、外部デバイス８６０との接続に、RS-232またはUSB（Universal Serial Bus）などの業界標準を使用してもよい。

　ディスプレイインターフェース８６５は、コンピュータ８０５をディスプレイ８７０に接続することができ、ディスプレイ８７０を使用して、コマンドラインまたはグラフィカルユーザインターフェースを、コンピュータ８０５のユーザに提示する形態もある。ディスプレイインターフェース８６５は、VGA（Video Graphics Array）や、DVI（Digital Visual Interface）、DisplayPort、HDMI（High-Definition Multimedia Interface）（登録商標）などの業界標準または専用の接続の１つまたは複数を使用して、ディスプレイ８７０と接続することができる。

　上述のように、ネットワークインタフェース８５０は、他のコンピュータやストレージシステム、または、コンピュータ８０５の外部のデバイスとの通信を提供する。本明細書で説明するソフトウェアプログラムおよびデータは、例えば、リモートコンピュータ８１５、ウェブサーバ８２０、クラウドストレージサーバ８２５、およびコンピュータサーバ８３０から、不揮発性ストレージ８４５へ、ネットワークインタフェース８５０およびネットワーク８１０を介してダウンロードすることができる。さらに、本開示のシステムおよび方法は、ネットワークインタフェース８５０およびネットワーク８１０を介してコンピュータ８０５と接続された１または複数のコンピュータにより実行することができる。例えば、ある実施の形態では、本開示のシステムおよび方法が、リモートコンピュータ８１５、コンピュータサーバ８３０、または、ネットワーク８１０上の相互接続された複数のコンピュータの組み合わせによって実行される。

　本開示のシステムおよび方法の実施の形態で採用されるデータ、データセット、および／または、データベースは、リモートコンピュータ８１５、ウェブサーバ８２０、クラウドストレージサーバ８２５、および、コンピュータサーバ８３０からダウンロードして、格納することができる。

＜５．DVSデータを用いた超解像ストリーム＞
　上述したデータ処理システム５００は、DVS(Dynamic Vision Sensor)を用いた画像処理システムに適用し得る。

　DVSは、画素の輝度変化をイベントとして検出し、イベントが発生したタイミングで、イベントの発生を表すイベントデータを出力する。

　一般的なイメージセンサが、垂直同期信号に同期して撮像を行い、一定周期で１フレーム（画面）の画像データを出力するのに対して、DVSは、イベントが発生したタイミングで、非同期にイベントデータを出力する。画素の値は、例えば、＋変化、－変化、または、変化なし、のような３値を取る。DVSは、変化した画素のみについて画素の位置座標と時間情報を組み合わせて出力するため、高効率で高速、低遅延なデータ出力が可能である。

　以下においては、区別を容易にするため、通常の同期型のイメージセンサを、イメージセンサと称するとともに、イメージセンサが出力するフレーム単位のデータをイメージデータと称する。また、非同期にイベントを検出するイベントセンサをDVSと称するとともに、DVSが出力するデータをイベントデータと称する。

　DVSのイベントデータは、例えば、通常のフレームベースのイメージセンサの画像と組み合わせて超解像画像を生成する処理に利用することができる。

　同期型のイメージセンサと非同期型のDVSとを組み合わせた処理としては、同期型のイメージセンサで得られた動画像に、非同期型のDVSによるイベント出力を適用することにより、時間解像度を高めた超解像動画像を生成する技術が提案されている（例えば、非特許文献「Liyuan Pan, Richard Hartley, Cedric Scheerlinck, Miaomiao Liu, Xin Yu, Yuchao Dai, High Frame Rate Video Reconstruction based on an Event Camera, Extension of our CVPR2019 (Oral) paper, インターネット＜https://arxiv.org/pdf/1903.06531.pdf＞」）。

　図１４は、DVSのイベントデータを利用して、時間分解能を高めた超解像画像を生成する例を示している。

　イメージセンサは、例えば３０fpsや６０fpsのような、DVSと比較して長周期となる一定のフレームレートで画像を生成、出力する。イメージセンサが出力する、一定のフレームレートで撮像された画像をフレーム画像と称する。図１４の例では、時刻T0においてフレーム画像P0が出力され、時刻T1においてフレーム画像P1が出力されている。

　DVSは、イベントが発生したランダムなタイミングで、イベントを検出し、画像を生成、出力する。DVSがランダムに出力する画像を、イベント画像と称する。図１４の例では、時刻T0においてイベント画像E0が出力され、時刻T1においてイベント画像E3が出力される他、時刻T0と時刻T1との間の時刻T0aと時刻T0bにおいて、イベント画像E1とE2が出力されている。

　超解像画像を生成する画像処理装置は、例えば、時刻T0におけるフレーム画像P0と、時刻T0と時刻T0aとの輝度変化を表すイベント画像E1に基づいて、時刻T0aにおける超解像画像F1を生成、出力する。また、画像処理装置は、例えば、時刻T0におけるフレーム画像P0および時刻T0aにおける超解像画像F1と、時刻T0 aと時刻T0bとの輝度変化を表すイベント画像E2に基づいて、時刻T0bにおける超解像画像F2を生成、出力する。

　画像処理装置は、以上のように、イメージセンサが出力する動画像の画像ストリームであるイメージストリームと、DVSが出力する動画像の画像ストリームであるイベントストリームとを用いて超解像処理を行うことにより、時間方向の分解能を高めた超解像動画像の画像ストリームである超解像イメージストリームを生成することができる。

　なお、図１４の例は、超解像処理により、超解像画像として、時間方向の分解能を向上させた画像を生成する例であるが、例えば、ダイナミックレンジを拡大した高ダイナミックレンジ画像や、空間解像度を向上させた画像を、超解像画像として生成するものでもよい。

　超解像画像を用いることにより、現状のイメージセンサでは捉えることができない画像の特徴を検出できる可能性が拡大する。

　しかしながら、時間解像度を高めた超解像動画像を、ネットワークを介して多数の画像処理装置へ送信する場合、ネットワークのトラフィックを圧迫することが懸念される。

　そこで、以下では、図１のデータ処理システム５００を、上述した超解像処理を行う画像解析ネットワークシステムに適用した実施の形態について説明する。図１のデータ処理システム５００におけるセンサ５１１が、図１５の画像解析ネットワークシステム１におけるセンサデバイス１１または解析装置１２に対応し、図１のデータ処理システム５００において本処理を行うアプリケーションが、図３０において、超解像処理を実行して超解像イメージストリームを生成するアプリケーション（超解像処理ノード１４C）に対応する。例えば、評価軸としてネットワークトラフィックをできるだけ小さくし、解析装置１２により近いノードの優先順位を高くすることがマニフェストに記載される場合を想定する。あるいはまた、マニフェストを参照せずに、評価軸と優先順位が予め決定されているとしてもよい。超解像処理を実行するアプリケーションを最適配置することにより、超解像の画像ストリームを効率的にネットワーク伝送することができる。

＜６．超解像画像を用いた画像解析ネットワークシステム＞
　図１５は、本技術を適用した画像処理システムの一実施の形態である画像解析ネットワークシステムの構成例を示している。

　図１５の画像解析ネットワークシステム１は、上述した超解像処理によって生成される超解像画像を用いた画像解析処理を行うシステムである。画像解析ネットワークシステム１では、センサデバイス１１と複数の解析装置１２（１２A乃至１２C）とが、ネットワーク１３を介して接続される。

　センサデバイス１１は、イメージセンサとDVSを有しており、超解像処理を行う元データとなるイメージデータとイベントデータを生成する。

　解析装置１２は、例えば、ディープラーニングなどの機械学習を用いたAIエンジンを備え、イメージデータとイベントデータから生成された超解像画像を用いた画像解析処理を行う画像処理装置である。

　ネットワーク１３は、例えば、インターネット、公衆電話回線網、所謂4G回線や5G回線等の無線移動体用の広域通信網、WAN（Wide Area Network）、LAN（Local Area Network）、Bluetooth（登録商標）規格に準拠した通信を行う無線通信網、NFC（Near Field Communication）等の近距離無線通信の通信路、赤外線通信の通信路、HDMI（登録商標）（High-Definition Multimedia Interface）やUSB（Universal Serial Bus）等の規格に準拠した有線通信の通信網等、任意の通信規格の通信網や通信路である。

　ネットワーク１３には、センサデバイス１１と複数の解析装置１２の他、複数のノード１４（１４ａ乃至ノード１４ｉ）が存在する。各ノード１４は、例えば、センサデバイス、ルータ、モデム、ハブ、ブリッジ、スイッチングハブ、基地局制御装置、サーバなどのネットワーク接続装置であり、データの出力元から、宛先となる装置へ、データを転送する機能を少なくとも有する。本実施の形態において、データの出力元は、センサデバイス１１であり、出力されるデータは、センサデータであるイメージデータもしくはイベントデータ、または、超解像処理により生成された超解像画像である。センサデバイス１１から出力されたデータの宛先となる装置は、超解像画像を用いた画像解析処理を行う各解析装置１２である。

　なお、以下において、データの出力元であるセンサデバイス１１から、宛先装置である各解析装置１２までのデータ伝送経路の所定のノード１４を起点としたとき、データの取得先であるセンサデバイス１１側の経路を上流、データの出力先である解析装置１２側の経路を下流と呼ぶことがある。

　図１５では、紙面の制約上、ノード１４の個数が、ノード１４ａからノード１４ｉまでの９個であり、解析装置１２の個数が、解析装置１２A乃至１２Cの３個の例が示されているが、解析装置１２およびノード１４の個数は、これに限られず、任意である。

＜超解像画像の解析アプリケーション例＞
　図１６および図１７を参照して、図１５の画像解析ネットワークシステム１のアプリケーション適用例について説明する。

　図１６は、画像解析ネットワークシステム１を適用した第１のアプリケーションの参考画像例である。

　第１のアプリケーションとしての画像解析ネットワークシステム１は、速度違反のバイク(移動体)を検知し、それに乗っている人物を特定して追跡、通報するシステムである。

　センサデバイス１１は、例えば、高速道路等に配置され、通過するバイクや自動車等の移動体を捉えた３０fpsや６０fpsなどの長周期のイメージデータと、高速、低遅延なイベントデータとを出力する。

　複数の解析装置１２は全国各地に散らばって配置されており、各解析装置１２は、様々な人物の特徴量をアプリケーションにより収集してデータベース化している。解析装置１２は、センサデバイス１１が出力したイメージデータとイベントデータとから生成された超解像画像F11内の注目領域ROI-1乃至ROI-4に含まれる人物の特徴を認識して、人物を特定して通報する。

　人間の身体のパーツの細かな動かし方には個人差がある。DVSは、検索対象人物の顔の特徴量など、従来、人物特定に使われてきた特徴量ばかりでなく、人間の目を超えたAIエンジンにのみ解析可能な、DVSにしか検知することのできない、身体の各部の細かな動きの特徴を検出することができる。

　したがって、各解析装置１２は、フレーム単位のイメージデータのみから判定するより、DVSによるイベントデータを用いて生成された超解像画像を用いて認識処理することにより、精度高く人物を特定することができる。

　また、上記のような人物特定は即座に行われる必要があり、全国各地で分散稼働する解析装置１２に対して解析すべきデータを同時に共有させて解析することにより、リアルタイム性を担保した画像解析処理が可能となる。

　したがって、画像解析ネットワークシステム１では、全国に散らばった様々な人物の特徴量データベースを持つ人の目を超えた動作特徴解析可能なAIエンジン群により人物認識処理を行い、該当人物のリアルタイム判定が可能となる。

　図１７は、画像解析ネットワークシステム１を適用した第２のアプリケーションの参考画像例である。

　第２のアプリケーションとしての画像解析ネットワークシステム１は、抗議デモにおいて暴徒化した人物の危険行動を予測し、危険人物を同定し、機動隊への防御指示等をリアルタイムに行うシステムである。

　センサデバイス１１は、例えば、都市部の道路や歩道等に配置され、抗議デモのデモ隊を捉えた３０ｆｐｓや６０ｆｐｓなどの長周期のイメージデータと、高速、低遅延なイベントデータとを出力する。

　各解析装置１２は、フレーム単位のイメージデータと、DVSによるイベントデータを用いて生成された超解像画像を用いて認識処理することにより、人物の行動（危険行動）を予測し、危険人物を同定する。例えば、超解像画像F12内の注目領域ROI-11乃至ROI-15に含まれる人物が、解析装置１２により危険人物として同定され、機動隊へ通知される。DVSによるイベントデータを用いて生成された超解像画像を用いて、人物を認識する認識処理を行うことにより、フレーム単位のイメージデータでは検知できない人間の身体の細かな動きを認識することができ、危険行動予測および危険人物同定を高精度に行うことができる。

　今後は、ありとあらゆるセンサデバイス１１が世の中に普及していくため、センサデバイス１１が検知した様々な種類のデータが物理的に離れた場所に分散して、蓄積されていく可能性がある。また、ある目的でとったデータが、他の目的や、さまざまな用途で使われていくことも予想される。例えば、農業管理用にとったデータが気象予報用途に使われたり、ライフログ的にとったデータが犯罪者捜査などに使われたりすることも考えられる。これらのデータは分散管理されるため、それらのデータをもとに解析する解析装置１２も分散配置されて稼働する可能性が高い。

　センサデバイス１１が検知した様々な種類のデータは、高速に解析装置１２に転送され、解析装置１２がリアルタイム性を担保して解析処理を行うことが望まれる。

　従って、イメージセンサやDVSからのデータを、このような分散された解析装置１２に配送して解析させるような場合に、ネットワーク１３内を無駄なデータが流れないようにしなければならない。センサデバイス１１から各解析装置１２までのネットワーク１３の経路上で、できるだけ必要最小限のデータに絞って流さなければならない。

　すなわち、センサデバイス１１で得られたデータを、ネットワーク１３内に分散された各解析装置１２へ無駄なく(必要最小限に)配送して、各解析装置１２に解析させるような仕組みが必要となる。

＜７．ストリーム配信方法の例＞
　センサデバイス１１から各解析装置１２へ、無駄なネットワークトラフィックを抑えて、超解像イメージストリーム（超解像画像の画像データ）を転送する仕組みを検討すると、図１８乃至図２４で示される方法が考えられる。

　まず、解析装置１２が行う解析処理の処理速度を向上させ、リアルタイム性を担保する場合、分散配置された複数の解析装置１２それぞれには、イメージデータまたは超解像画像で検出されたすべての解析対象を処理させるのではなく、注目領域ROIごとに処理を分けて、注目領域ROIごとの超解像イメージストリーム（以下、ROI超解像イメージストリームと称する。）を配信して、解析処理を行わせることが好ましい。

　例えば、図１８に示されるように、センサデバイス１１が、注目領域ROI-1のROI超解像イメージストリームを生成し、ネットワーク１３を介して、担当する各解析装置１２へ配信する。

　ここで、センサデバイス１１は、すべての解析装置１２の解析能力に対応するために、高分解能の注目領域ROI-1のROI超解像イメージストリームを生成し、各解析装置１２へマルチキャスト配信したとする。

　しかしながら、注目領域ROI-1の解析を担当する解析装置１２の解析能力が、そこまで高くなく、必要以上の分解能（本例では、時間分解能）のROI超解像イメージストリームである場合には、分解能が高いほど、イメージストリームが占有する帯域は大きくなるため、トラフィックを圧迫する要因となる。

　例えば、配信されるROI超解像イメージストリームの分解能に応じて、ネットワーク１３を占有する帯域が、広帯域（高分解能）、中帯域（中分解能）、狭帯域（低分解能）の３種類に分類されるとすると、センサデバイス１１が、広帯域のROI超解像イメージストリームをマルチキャスト配信し、解析装置１２Aにとって必要十分な超解像ストリームの帯域が中帯域であり、解析装置１２Bにとって必要十分な超解像ストリームの帯域が狭帯域である場合には、センサデバイス１１は、必要以上の広帯域のROI超解像イメージストリームを配信し、ネットワーク１３のトラフィックを圧迫することになる。

　実際には、図１９に示されるように、イメージデータまたは超解像画像で検出された複数の注目領域ROIそれぞれについて、必要以上の広帯域のROI超解像イメージストリームが配信されることになるので、トラフィックはさらに圧迫される。

　必要以上の広帯域のROI超解像イメージストリームが配信されてしまうことに対処するためには、分解能について各々の解析装置１２の要件を予め上流側に通知しておき、図２０に示されるように、センサデバイス１１が、各解析装置１２の分解能に応じたROI超解像イメージストリームを生成し、配信することが考えられる。

　図２０は、解析装置１２Aに対しては、解析装置１２Aにとって必要十分な中帯域の超解像ストリームを生成し、解析装置１２Bに対しては、解析装置１２Bにとって必要十分な狭帯域の超解像ストリームを生成する様子を示している。

　また、生成したROI超解像イメージストリームをマルチキャスト配信するのではなく、図２１に示されるように、ポイントツーポイントで、必要十分な帯域の超解像ストリームを配信することが望ましい。

　図２１は、センサデバイス１１が、解析装置１２Aにとって必要十分な中帯域のROI超解像イメージストリームを生成して、ポイントツーポイントで解析装置１２Aに配信し、解析装置１２Bおよび１２Cに対しては、必要十分な狭帯域のROI超解像イメージストリームを生成して、ポイントツーポイントで解析装置１２Bおよび１２Cに配信する様子を示している。

　しかしながら、ポイントツーポイントの配信では、解析装置１２の台数が非常に多くなると、ポイントツーポイントストリーミングの負荷が大きくなってしまう。また、解析装置１２各々の分解能要件に合わせて上流側でストリーム生成するのは難しいため、何らかの最適化が必要となる。

　例えば、図２２に示されるように、センサデバイス１１が、中帯域と狭帯域それぞれのROI超解像イメージストリームを生成して、それぞれの分解能を必要とする解析装置１２へ、マルチキャスト配信する方法が考えられる。図２２の例では、中帯域のROI超解像イメージストリームが解析装置１２Aに配信され、狭帯域のROI超解像イメージストリームが、解析装置１２Bおよび１２Cにマルチキャスト配信されている。

　あるいはまた、図２３に示されるように、センサデバイス１１から、ネットワーク１３の途中のノード１４までは、最大帯域（広帯域）のROI超解像イメージストリームをマルチキャスト配信し、途中のノード１４において、それより下流の配信先の解析装置１２の分解能要件に合わせて分解能を変更したROI超解像イメージストリームを生成し、各解析装置１２へマルチキャスト配信する方法が考えられる。図２２の例では、途中のノード１４において、広帯域のROI超解像イメージストリームから、中帯域と狭帯域のROI超解像イメージストリームが生成され、中帯域のROI超解像イメージストリームが、解析装置１２Aに配信され、狭帯域のROI超解像イメージストリームが、解析装置１２Bおよび１２Cにマルチキャスト配信されている。

　上記のいずれの方法を採用した場合でも、ネットワーク１３の上流側から、ROI超解像イメージストリームが流れるため、図２４のように、多数のセンサデバイス１１が存在し、かつ、それぞれのセンサデバイス１１が撮像した画像に多数の注目領域ROIが設定されるような場合、ネットワーク１３におけるトラフィックの圧迫は避けられない。

　以上のように、センサデバイス１１が撮像した画像に多数の解析対象物が含まれ、それらに対して注目領域ROIが設定され、ネットワーク１３に分散配置された多数の解析装置１２が、所定の時間内に画像解析を行うために、解析処理を同時実行するようなケースでは、注目領域ROI毎の超解像処理された時間分解能が高いイメージストリーム（ROI超解像ストリーム）を、ネットワーク１３を介して多数の解析装置１２へ配信しなければならず、注目領域ROIが多ければ多いほど、ネットワーク１３のトラフィックを圧迫してしまう。

　また、センサデバイス１１、または、センサデバイス１１と最初に接続されるサーバ等のノード１４が、ROI超解像ストリームを生成する場合、配信先の解析装置１２毎の解析能力を把握できていなければ、必要以上に高分解能なイメージストリームを配信してしまう可能性があり、その結果、ネットワーク１３のトラフィックが圧迫される。

＜８．画像解析ネットワークシステムが行うストリーム配信方法の例＞
　そこで、図１５の画像解析ネットワークシステム１は、上述したような注目領域ROI毎のROI超解像ストリームの配信も可能であるが、ネットワーク１３のトラフィックを抑制し、効率的に伝送するため、図２５に示されるような、ROI超解像ストリームの配信を行う。

　図２５は、図１５の画像解析ネットワークシステム１が行う、ROI超解像ストリームの配信の概念図を示している。

　画像解析ネットワークシステム１は、センサデバイス１１から複数の解析装置１２までのネットワーク１３内にある複数のノード１４のなかから、解析装置１２に近い下流のノード１４で、イメージストリームおよびイベントストリームからROI超解像ストリームを生成するようにして、解析装置１２へ配信する。ROI超解像ストリームを生成する下流のノード１４までは、センサデバイス１１が生成したイメージストリームおよびイベントストリームが、そのまま伝送される。イメージストリームおよびイベントストリームからROI超解像ストリームを生成するノード１４（後述する超解像処理ノード１４C）は、少なくともセンサデバイス１１よりも解析装置１２に近いノード１４とされる。

　図２６は、図２５のROI超解像ストリームの配信の概念図をさらに詳細に示した図である。

　イメージセンサが撮像したフレーム画像に含まれる複数の注目領域ROI-1乃至ROI-ｎそれぞれについてのイメージストリームとイベントストリームが、ネットワーク１３の伝送経路の解析装置１２に近い下流側、例えば、解析装置１２と最初に接続されるノード１４まで伝送される。解析装置１２と最初に接続されるノード１４は、取得したイメージストリームおよびイベントストリームからROI超解像ストリームを生成し、解析装置１２へ送信する。

　イメージストリームは、長周期のフレーム画像からなるストリームであり、また、イベントストリームは、イベントが発生した画素（アドレス）のみの３値のデータであるため、イメージストリームおよびイベントストリームは、いずれも、ROI超解像ストリームと比較して転送負荷の軽いストリームである。

　イメージストリームは、イメージセンサが撮像したフレーム画像から注目領域ROI単位で抽出した注目領域ROI毎のストリームでもよいし、イメージセンサが撮像したフレーム画像そのまま（以下、全体イメージと称する。）のストリームでもよい。本実施の形態では、全体イメージのイメージストリームを伝送することとする。

　ROI超解像ストリームを生成するノード１４以外の、それより上流側の各ノード１４は、イメージストリームおよびイベントストリームを中継する。すなわち、各ノード１４は、上流側から伝送されてくるイメージストリームおよびイベントストリームを受信し、下流側のノード１４へ送信する。また、各ノード１４は、受信したイメージストリームおよびイベントストリームをキャッシュ（記憶）し、下流側に新たな解析装置１２が追加され、他の経路が追加された場合に、必要に応じて、キャッシュしたイメージストリームおよびイベントストリームを送信可能とする。

　また、イメージストリームおよびイベントストリームを中継する各ノード１４は、下流側の配信先の解析装置１２の時間分解能の能力に応じて、必要に応じてイベントストリームを間引いて、下流側のノード１４へ送信することもできる。なお、以下では、解析装置１２の時間分解能の能力を、解析装置１２において必要十分な時間分解能の要件ということで、時間分解能要件とも称する。

　図２７は、複数の解析装置１２それぞれの時間分解能要件に応じて、伝送経路のノード１４においてイベントストリームが間引かれて伝送される例を示している。

　解析装置１２の時間分解能は、例えば、一定期間に解析装置１２が解析処理可能な超解像画像の枚数に相当し、超解像処理では、イベントが発生する毎に超解像画像が生成されるので、イベントが発生する頻度に対応する。したがって、解析装置１２の時間分解能は、イベントストリームのイベント頻度（イベント密度）に対応する。

　図２７の例では、解析装置１２の時間分解能要件をイベント頻度で表し、各解析装置１２の時間分解能要件が、矩形の枠で囲んだ数字で表されている。具体的には、解析装置１２Aの時間分解能は「１」であり、解析装置１２Bの時間分解能は「２」であり、解析装置１２Cの時間分解能は「４」であり、解析装置１２Dの時間分解能は「１」である。

　センサデバイス１１が生成したイベントストリームの時間分解能は、「４」である。ネットワーク１３の各ノード１４は、下流側にイベントストリームを伝送する際、下流の経路に接続される解析装置１２の時間分解能要件（イベント頻度）の最大値に合わせて、イベントストリームを間引いて、下流側のノード１４へ送信する。

　例えば、解析装置１２Aへ伝送される所定の注目領域ROIのイベントストリームの時間分解能は、センサデバイス１１から「４→４→２→１」となる。また、解析装置１２Bへ伝送される所定の注目領域ROIのイベントストリームの時間分解能は、センサデバイス１１から「４→４→２→２」となる。解析装置１２Cへ伝送される所定の注目領域ROIのイベントストリームの時間分解能は、センサデバイス１１から「４→４→４→４」となる。また、解析装置１２Dへ伝送される所定の注目領域ROIのイベントストリームの時間分解能は、センサデバイス１１から「４→４→４→１」となる。

　このように、時間分解能要件（イベント頻度）の最大値に合わせて、イベントストリームを間引いて、下流側のノード１４へ送信することにより、ネットワークトラフィックを最適化し、軽減させることができる。

　イベントストリームを間引く処理は、図４０および図４１を参照して後述するように、例えば、時間方向に隣接するイベントを積算（合成）することで行うことができる。

　なお、ROI超解像ストリームを生成するノード１４は、下流側の経路に接続されている解析装置１２の数や注目領域ROIの数などによっては、解析装置１２と最初に接続されるエッジのノード１４ではなく、図２８に示されるように、その１つ前のノード１４や、２つ前のノード１４でROI超解像ストリームを生成した方が、全体としてのネットワークトラフィックを低減できる場合がある。この場合、ROI超解像ストリームを生成するノード１４より下流のノード１４は、ROI超解像ストリームを中継およびキャッシュするノードとなる。

　図２９は、イメージセンサが撮像したフレーム画像に含まれる複数の注目領域ROIに着目して、各注目領域ROIのストリームの伝送経路を示した図である。

　なお、図２９は、図が煩雑になるのを防ぐため、注目領域の個数は、注目領域ROI-1乃至ROI-4の４個とされている。

　注目領域ROI-1乃至ROI-4それぞれのイベントストリームが伝送される経路を、注目領域ROIごとにみると、下流側の経路に接続されている解析装置１２が解析処理を担当する注目領域ROIごとに、イベントストリームがマルチキャストで配信される。すなわち、すべての解析装置１２に、各注目領域ROIのイベントストリームがマルチキャスト配信されるのではなく、解析処理を担当する解析装置１２のみに、処理対象の注目領域ROIのイベントストリームがマルチキャスト配信される。これにより、ネットワーク１３の経路に、不要なイベントストリームが伝送されることがなく、ネットワークトラフィックが最適化され、軽減される。

　イメージストリームについては、全体イメージのイメージストリームを伝送する場合には、解析装置１２と接続されるすべての経路のノード１４にマルチキャスト配信されるが、注目領域ROI毎のイメージストリームを伝送する場合には、イベントストリームと同様に、解析処理を担当する解析装置１２のみに、処理対象の注目領域ROIのイメージストリームがマルチキャスト配信される。

　以上、図２５乃至図２９を参照して説明したように、図１５の画像解析ネットワークシステム１は、解析装置１２に近いネットワーク１３の下流側のノード１４で超解像ストリームを生成する。これにより、超解像ストリームを生成するネットワーク１３のノード１４までは、転送負荷の軽いイメージストリームとイベントストリームで伝送することができるので、トラフィックを軽減させることができる。すなわち、超解像の画像ストリームを効率的にネットワーク伝送することができる。

　また、画像解析ネットワークシステム１は、全ての注目領域ROIで一律のフレームレートでストリームを伝送させるのではなく、個々の注目領域ROIごとに、解析装置１２の時間分解能要件に応じて、必要十分なイベント頻度に応じた最適な可変フレームレートで伝送させる。これにより、伝送経路のトラフィックを軽減することができ、ストリームを中継するノード１４のキャッシュ量も最適化することができる。また、超解像処理を行うノード１４も必要以上の超解像処理をセーブすることができ、CPU(GPU)性能を効率的に利用することができる。

＜９．画像解析ネットワークシステムのブロック図＞
　図３０は、図２５乃至図２９を参照して説明したストリーム配信方法を実現する図１５の画像解析ネットワークシステム１の構成例を示すブロック図である。

　画像解析ネットワークシステム１は、センサデバイス１１、ブローカーノード１４A、中継処理ノード１４B,超解像処理ノード１４C、オーケストレータ１４D、および、解析装置１２を含んで構成される。

　図３０では、センサデバイス１１から所定の１つの解析装置１２へROI超解像ストリームが配信される経路に関連する構成例が示されている。したがって、図３０の解析装置１２は、例えば、図２５に示した３台の解析装置１２A乃至１２Cの所定の１台に対応する。

　ブローカーノード１４A、中継処理ノード１４B、超解像処理ノード１４C、および、オーケストレータ１４Dは、図１５のネットワーク１３内のいずれかのノード１４であり、ネットワーク１３内の各ノード１４は、それが実行する機能によって、ブローカーノード１４A、中継処理ノード１４B、超解像処理ノード１４C、または、オーケストレータ１４Dのいずれかに割り当てられる。

　ブローカーノード１４Aは、ネットワーク１３においてセンサデバイス１１と最初に接続されるネットワーク１３内のノード１４（エッジノード）であり、図１５では、例えばノード１４ａである。

　中継処理ノード１４Bは、図２６で説明した、イメージストリームおよびイベントストリームを中継およびキャッシュするノードであり、図１５では、例えばノード１４cやノード１４ｅである。

　なお、中継処理ノード１４Bは、ブローカーノード１４Aと超解像処理ノード１４Cとの間に、複数介在することが一般的であるが、図３０では、１つとして説明する。

　超解像処理ノード１４Cは、上流側のノード１４（中継処理ノード１４B）から伝送されてきたイメージストリームとイベントストリームを用いて超解像画像を生成する超解像処理を実行するノードであり、図１５では、例えば、ノード１４ｇやノード１４ｈである。超解像処理ノード１４Cは、ネットワーク１３において解析装置１２と最初に接続されるネットワーク１３内のノード１４（エッジノード）とされることが多いが、ノード１４の処理能力やネットワーク１３を流れるストリーム全体の帯域等を考慮して、エッジノードよりも上流側のノード１４とされる場合もある。

　オーケストレータ１４Dは、ネットワーク１３の経路に流れるストリームの帯域等を監視し、超解像処理を実行するノード１４（超解像処理ノード１４C）を決定するノードであり、図１５では、例えば、ノード１４ｉである。図３０の各構成は、超解像処理ノード１４Cが決定された状態の構成を示している。

　センサデバイス１１は、イベント・イメージセンサ４１、オブジェクトROI抽出エンジン４２、ROIカタログジェネレータ４３、ROIイメージフィルタ４４、および、ROIイベントフィルタ４５を備える。

　ブローカーノード１４Aは、ROIサブスクリプションブローカ５１、ROIイメージブローカ５２、および、ROIイベントブローカ５３の各モジュールを備える。

　中継処理ノード１４Bは、ROIサブスクリプション中継モジュール６１、ROIイメージ中継モジュール６２、および、ROIイベント中継モジュール６３を備える。

　超解像処理ノード１４Cは、ROIサブスクリプション中継モジュール７１、および、超解像処理モジュール７２を備える。

　オーケストレータ１４Dは、オーケストレーションモジュール９１を備える。

　解析装置１２は、ROIサブスクライバ８１、および、解析モジュール８２の各モジュールを備える。

　センサデバイス１１のイベント・イメージセンサ４１は、DVS（イベントセンサ）とイメージセンサとを有する。DVSは、イベントが発生したランダムなタイミングで、イベント画像を生成し、イメージセンサは、例えば３０fpsや６０fpsのような、DVSと比較して長周期で、フレーム画像を生成する。生成されるイベント画像およびフレーム画像は、オブジェクトROI抽出エンジン４２、ROIイメージフィルタ４４、および、ROIイベントフィルタ４５に供給される。

　イベント・イメージセンサ４１は、DVSが最初のイベントを検出すると、イメージセンサに撮像を行わせ、生成したフレーム画像を、スナップショットとして、オブジェクトROI抽出エンジン４２へ供給する。

　オブジェクトROI抽出エンジン４２は、イベント・イメージセンサ４１からのスナップショットに基づいて、オブジェクトを認識する処理を実行し、認識したオブジェクト毎に注目領域ROIを割り当てる。そして、オブジェクトROI抽出エンジン４２は、オブジェクトを特定したときのスナップショットと、オブジェクト毎に割り当てた注目領域ROIを特定する情報（ROI特定情報）を、ROIカタログジェネレータ４３へ供給する。ROI特定情報には、例えば、オブジェクトの注目領域ROIを識別するROI-ID（ROI識別情報）と、オブジェクトの属性情報（オブジェクト属性情報）とが含まれる。オブジェクトの属性情報には、例えば、認識処理により検出されたオブジェクトの種類（人、車、物の名称など）、色、領域を示す座標などが含まれる。スナップショットとROI特定情報は、オブジェクトROI抽出エンジン４２から、ROIイメージフィルタ４４およびROIイベントフィルタ４５へも供給される。

　ROIカタログジェネレータ４３は、オブジェクトROI抽出エンジン４２から供給される、オブジェクトが含まれた画像であるスナップショットと、注目領域ROIを特定するROI特定情報とに基づいて、ROIカタログを生成し、ブローカーノード１４AのROIサブスクリプションブローカ５１に供給する。

　図３１は、オブジェクトROI抽出エンジン４２から供給されたスナップショットと、注目領域ROIの割り当ての例を示している。

　図３１のスナップショットSNPには、認識処理により検出されたオブジェクトOBJ１乃至OBJ3が含まれている。オブジェクトOBJ１乃至OBJ3は、例えば、色や車種の異なる車である。オブジェクトOBJ１乃至OBJ3には、ROI識別情報として、ROI-ID-1乃至ROI-ID-3が付与されている。

　ROIカタログジェネレータ４３は、オブジェクトOBJ１乃至OBJ3のそれぞれについて、注目領域ROI-ID-1乃至ROI-ID-3を、グローバルユニークに識別するグローバルROI-IDに変換する。グローバルROI-IDは、例えば、イベント・イメージセンサ４１を識別するセンサID（sensor-ID-n）と、ROI特定情報（ROI-ID-n）とからなるurn(uniform resource name)とされる(n=1,2,3,・・・)。イメージストリームが、注目領域ROIごとではなく、全体イメージのストリームである場合には、例えば、ROI特定情報（ROI-ID-n）のnを0としたROI-ID-0など、注目領域ROIを限定しないurnが付される。

　図３０の説明に戻り、ROIカタログジェネレータ４３は、スナップショットSNPと、オブジェクトOBJごとのグローバルROI-IDとオブジェクト属性情報とを含むROI特定情報を、ROIカタログとし、ROIサブスクリプションブローカ５１に供給する。このROIカタログは、ROIサブスクリプションブローカ５１、ROIサブスクリプション中継モジュール６１、および、ROIサブスクリプション中継モジュール７１を中継して、ROIサブスクライバ８１へ通知される。

　ROIイメージフィルタ４４は、オブジェクトROI抽出エンジン４２から供給されるスナップショットとオブジェクト毎のROI特定情報とに基づいて、イベント・イメージセンサ４１から供給されるフレーム画像をフィルタリングし、フィルタリング処理後のフレーム画像を、ブローカーノード１４AのROIイメージブローカ５２に供給する。

　ROIイベントフィルタ４５は、オブジェクトROI抽出エンジン４２から供給されるスナップショットとオブジェクト毎のROI特定情報とに基づいて、イベント・イメージセンサ４１から供給されるイベント画像をフィルタリングし、フィルタリング処理後のイベント画像を、ブローカーノード１４AのROIイベントブローカ５３に供給する。

　すなわち、ROIイベントフィルタ４５は、イベント・イメージセンサ４１から順次供給されるイベント画像が、ROI特定情報で特定される注目領域ROI単位となるようにフィルタリング（抽出）し、注目領域ROI毎のイベント画像を、イベントストリームとして、ROIイベントブローカ５３に供給する。

　これに対して、イメージストリームは、上述したように、注目領域ROI毎のイメージストリームか、または、全体イメージのイメージストリームのどちらでもよく、注目領域ROI毎の場合には、ROIイメージフィルタ４４は、注目領域ROI単位となるようにフィルタリング（抽出）するが、全体イメージのイメージストリームの場合には、イベント・イメージセンサ４１から順次供給されるフレーム画像をフィルタリングせずに、そのままイメージストリームとして、ROIイメージブローカ５２に供給する。

　なお、フレーム画像およびイベント画像に含まれるオブジェクトは動いたり、変化するため、ROIイメージフィルタ４４およびROIイベントフィルタ４５は、オブジェクトROI抽出エンジン４２と協調して、オブジェクトを追尾しながら、フィルタ処理を実行する。

　ブローカーノード１４AのROIサブスクリプションブローカ５１は、ROIカタログジェネレータ４３から供給されるROIカタログを、ROIサブスクリプション中継モジュール６１へ送信する。

　また、ROIサブスクリプションブローカ５１は、ROIサブスクリプション中継モジュール６１を介して、各解析装置１２のROIサブスクライバ８１から供給されるROIサブスクリプションリクエストを取得する。ROIサブスクリプションリクエストとは、各解析装置１２がサブスクライブする注目領域ROIのリクエストであり、サブスクライブするとは、本実施の形態では、超解像イメージストリームを連続的に取得することを表す。したがって、ROIサブスクリプションリクエストとは、換言すれば、解析装置１２が超解像イメージストリームを連続的に取得したい注目領域ROIの要求である。

　ROIサブスクリプションリクエストは、具体的には、図３２に示されるように、リクエストする注目領域ROIのグローバルROI-IDと、超解像要件とを含んで構成される。超解像要件は、解析装置１２が実行する認識処理に必要十分な超解像画像の分解能を示す情報である。本実施の形態では、超解像画像が時間分解能を向上させた画像としているので、例えば、イメージセンサが出力するフレーム画像の時間分解能であるフレームレート[fps]と、DVSがイベントを検出する際の輝度値の閾値に対応するイベント感度とで構成される。イベント感度は、例えば、イベント頻度（イベント密度）でもよい。

　ROIサブスクリプションブローカ５１は、オーケストレータ１４Dのオーケストレーションモジュール９１から、イメージストリームおよびイベントストリームの注目領域ROIごとの送信先および経路を取得し、ROIイメージブローカ５２とROIイベントブローカ５３に供給する。

　さらに、ROIサブスクリプションブローカ５１は、複数の解析装置１２それぞれから供給されるROIサブスクリプションリクエストの注目領域ROIごとの超解像要件に基づいて、イメージセンサのフレームレート（動作フレームレート）と、DVSのイベント感度（動作感度）とを決定する。決定されたフレームレートは、ROIイメージブローカ５２を介して、ROIイメージフィルタ４４およびイベント・イメージセンサ４１に供給され、イベント感度は、ROIイベントブローカ５３を介して、ROIイベントフィルタ４５およびイベント・イメージセンサ４１に供給される。

　ROIイメージブローカ５２は、ROIサブスクリプションブローカ５１から供給される、イメージストリームの注目領域ROIごとの送信先および経路に基づいて、ROIイメージフィルタ４４から供給されるイメージストリームを、所要の中継処理ノード１４BのROIイメージ中継モジュール６２に供給する。配信されるイメージストリームが、全体イメージのストリームである場合には、注目領域ROIに応じた送信先の選択は行われない。

　ROIイベントブローカ５３は、ROIサブスクリプションブローカ５１から供給される、イベントストリームの注目領域ROIごとの送信先および経路に基づいて、ROIイメージフィルタ４４から供給されるイベントストリームを、所要の中継処理ノード１４BのROIイベント中継モジュール６３に供給する。

　中継処理ノード１４BのROIサブスクリプション中継モジュール６１は、ROIカタログおよびROIサブスクリプションリクエストを中継する。すなわち、ROIサブスクリプション中継モジュール６１は、ROIサブスクリプションブローカ５１から供給されるROIカタログを取得して、超解像処理ノード１４CのROIサブスクリプション中継モジュール７１に供給する。また、ROIサブスクリプション中継モジュール６１は、ROIサブスクリプション中継モジュール７１から供給されるROIサブスクリプションリクエストを取得して、ROIサブスクリプションブローカ５１に供給する。中継処理ノード１４Bと超解像処理ノード１４Cとの間に、他の中継処理ノード１４Bが介在する場合には、他の中継処理ノード１４BのROIサブスクリプション中継モジュール６１を介して同様の動作を行う。

　ROIイメージ中継モジュール６２は、全体イメージまたは注目領域ROIのイメージストリームを中継する。すなわち、ROIイメージ中継モジュール６２は、ROIイメージブローカ５２から供給される、全体イメージまたは注目領域ROIのイメージストリームを取得し、超解像処理ノード１４Cの超解像処理モジュール７２に供給する。中継処理ノード１４Bと超解像処理ノード１４Cとの間に、他の中継処理ノード１４Bが介在する場合には、全体イメージまたは注目領域ROIのイメージストリームは、他の中継処理ノード１４BのROIイメージ中継モジュール６２に供給される。

　ROIイベント中継モジュール６３は、注目領域ROIのイベントストリームを中継する。すなわち、ROIイベント中継モジュール６３は、ROIイベントブローカ５３から供給される、注目領域ROIのイベントストリームを取得し、超解像処理ノード１４Cの超解像処理モジュール７２に供給する。中継処理ノード１４Bと超解像処理ノード１４Cとの間に、他の中継処理ノード１４Bが介在する場合には、注目領域ROIのイベントストリームは、他の中継処理ノード１４BのROIイベント中継モジュール６３に供給される。

　また、ROIイベント中継モジュール６３は、下流の経路の超解像要件に基づいて、注目領域ROIのイベントストリームを必要に応じて間引き合成し、イベント頻度を低くした低分解能の注目領域ROIのイベントストリームを生成し、超解像処理モジュール７２または他のROIイベント中継モジュール６３に供給する。

　超解像処理ノード１４CのROIサブスクリプション中継モジュール７１は、中継処理ノード１４BのROIサブスクリプション中継モジュール６１と同様に、ROIカタログとROIサブスクリプションリクエストを中継する。すなわち、ROIサブスクリプション中継モジュール７１は、ROIサブスクリプション中継モジュール６１から供給されるROIカタログを取得して、解析装置１２のROIサブスクライバ８１に供給する。また、ROIサブスクリプション中継モジュール７１は、ROIサブスクライバ８１から供給されるROIサブスクリプションリクエストを取得して、ROIサブスクリプション中継モジュール６１に供給する。

　超解像処理モジュール７２は、中継処理ノード１４BのROIイメージ中継モジュール６２から供給される全体イメージまたは注目領域ROIのイメージストリームと、ROIイベント中継モジュール６３から供給される注目領域ROIのイベントストリームとを用いて、超解像処理を実行する。超解像処理の生成方法は特に限定されない。例えば、上記の非特許文献１で用いられている方法を利用することができる。

　超解像処理モジュール７２は、超解像処理により得られた、注目領域ROIの超解像イメージストリーム（ROI超解像イメージストリーム）を、解析装置１２の解析モジュール８２に供給する。

　オーケストレータ１４Dのオーケストレーションモジュール９１は、各中継処理ノード１４BのROIサブスクリプション中継モジュール６１から、ROIカタログとROIサブスクリプションリクエストを取得する。すなわち、センサデバイス１１と、分散配置された多数の解析装置１２との間のネットワーク１３内の経路にある各中継処理ノード１４BのROIサブスクリプション中継モジュール６１から、ROIカタログとROIサブスクリプションリクエストが取得される。

　オーケストレーションモジュール９１は、ROIカタログとROIサブスクリプションリクエストから、各解析装置１２が解析処理を行う注目領域ROIに基づいて、センサデバイス１１から各解析装置１２までの経路を注目領域ROI毎に決定し、中継処理ノード１４BのROIサブスクリプション中継モジュール６１や、ブローカーノード１４AのROIサブスクリプションブローカ５１などに供給する。

　オーケストレーションモジュール９１は、センサデバイス１１からのROIカタログから推測されるストリーム帯域（イメージストリーム帯域および注目領域ROI毎のイベントストリーム帯域）と、各中継処理ノード１４BのROIサブスクリプション中継モジュール６１のROIサブスクリプションリクエストの情報に基づく、中継処理ノード１４B毎のストリーム帯域と、超解像処理が行われた後のROI超解像イメージストリームのストリーム帯域、超解像処理ノード１４Cに必要なリソース（演算処理能力およびキャッシュ容量など）とを総合的に判定し、できるだけ解析装置１２側に近い下流側の中継処理ノード１４Bを、超解像処理ノード１４Cに決定する。

　また、オーケストレーションモジュール９１は、ネットワーク１３を経由する各ストリームの伝送パスの帯域の総量ができるだけ小さくなるように、超解像処理ノード１４Cを決定する。

　オーケストレーションモジュール９１は、各ストリームの伝送が開始された後も、逐次ストリーミング状況を監視しながら、トラフィックが最適に維持されるように、超解像処理ノード１４Cを配置しなおす等の調整を行う。

　超解像処理ノード１４Cの配置の決定においては、オーケストレーションモジュール９１は、下流側の経路に接続されている解析装置１２の数や注目領域ROIの数などに基づいて、解析装置１２と最初に接続されるノード１４を超解像処理ノード１４Cとするか、それよりも上流側のノード１４を超解像処理ノード１４Cとするかを決定する。

　解析装置１２のROIサブスクライバ８１は、超解像処理ノード１４CのROIサブスクリプション中継モジュール７１を介して、センサデバイス１１のROIカタログジェネレータ４３から供給されるROIカタログを参照し、ROIサブスクリプションリクエストを生成する。具体的には、ROIサブスクライバ８１は、ROIカタログに基づいて、ROI超解像画像に含まれる１以上の注目領域ROIのうち、自身が認識処理する注目領域ROIを選択する。そして、ROIサブスクライバ８１は、選択した注目領域ROIのグローバルROI-IDと、超解像要件とを含むROIサブスクリプションリクエストを生成する。生成されたROIサブスクリプションリクエストは、超解像処理ノード１４C、および、中継処理ノード１４Bを介して、ROIサブスクリプションブローカ５１に通知される。

　解析モジュール８２は、ディープラーニングなどの機械学習を用いたAIエンジンを備え、超解像処理モジュール７２からROI超解像イメージストリームを取得し、注目領域ROIの超解像画像を解析する画像解析処理を行う。例えば、解析モジュール８２は、注目領域ROIの超解像画像に含まれるオブジェクトOBJの人物を同定（認識）したり、人物の行動（危険行動）を予測（判定）する処理などを行う。

　以上のように、センサデバイス１１と複数の解析装置１２との間のネットワーク１３の各ノード１４は、センサデバイス１１と複数の解析装置１２の配置に応じて、ブローカーノード１４A、中継処理ノード１４B、超解像処理ノード１４C、または、オーケストレータ１４Dのいずれかのノード機能が割り当てられ、それぞれの動作を実行する。

　各ノード１４が割り当てられたノード機能に必要なモジュールは、ネットワーク１３内のアプリケーションリポジトリから必要に応じて検索され、動的に取得される。

　各ノード１４は、他のノード１４から取得したデータを、ノード１４内の各モジュールで共有するとともに、内部に一定期間記憶（キャッシュ）し、新たにネットワーク１３に参加したノード１４からの要求に応じて、自身が記憶しているイメージストリーム、イベントストリーム、ROIカタログ、超解像要件等の各データを送信することができる。

　図３３は、超解像処理ノード１４Cが、解析装置１２と最初に接続されるノード１４ではなく、その１つ上流側のノード１４に配置された場合の、超解像処理ノード１４Cおよび解析装置１２と、その間の中継処理ノード１４B’の構成例を示している。

　超解像処理ノード１４Cが、ネットワーク１３のエッジのノード１４ではなく、それより上流側のノード１４に配置された場合、超解像処理ノード１４Cと解析装置１２の間の中継処理ノード１４B’は、ROIサブスクリプション中継モジュール６１と、ROI超解像ストリーム中継モジュール１０１とで構成される。

　すなわち、中継処理ノード１４B’では、中継処理ノード１４BのROIイメージ中継モジュール６２とROIイベント中継モジュール６３が、ROI超解像ストリーム中継モジュール１０１に置き換えられる。

　超解像処理ノード１４Cの超解像処理モジュール７２により、ROI超解像イメージストリームが生成されるので、イメージストリームおよびイベントストリームを中継するROIイメージ中継モジュール６２とROIイベント中継モジュール６３ではなく、ROI超解像イメージストリームを中継するROI超解像ストリーム中継モジュール１０１が配置される。

＜センサデバイスとブローカーノードの変形例＞
　図３４および図３５は、センサデバイス１１とブローカーノード１４Aのその他の構成例を示している。

　図３０に示した構成例では、センサデバイス１１が、イベント・イメージセンサ４１、オブジェクトROI抽出エンジン４２、ROIカタログジェネレータ４３、ROIイメージフィルタ４４、および、ROIイベントフィルタ４５を備えていたが、イベント・イメージセンサ４１以外のモジュールは、ブローカーノード１４Aに配置されてもよい。

　図３４は、オブジェクトROI抽出エンジン４２とROIカタログジェネレータ４３を、ブローカーノード１４Aに配置した構成例を示している。

　この場合、センサデバイス１１は、イベント・イメージセンサ４１、ROIイメージフィルタ４４、および、ROIイベントフィルタ４５を備える。ブローカーノード１４Aは、オブジェクトROI抽出エンジン４２、ROIカタログジェネレータ４３、ROIサブスクリプションブローカ５１、ROIイメージブローカ５２、および、ROIイベントブローカ５３の各モジュールを備える。

　図３５は、イベント・イメージセンサ４１以外の全てのモジュールを、ブローカーノード１４Aに配置した構成例を示している。

　この場合、センサデバイス１１は、イベント・イメージセンサ４１を備える。ブローカーノード１４Aは、オブジェクトROI抽出エンジン４２、ROIカタログジェネレータ４３、ROIイメージフィルタ４４、ROIイベントフィルタ４５、ROIサブスクリプションブローカ５１、ROIイメージブローカ５２、および、ROIイベントブローカ５３を備える。

　図３４および図３５の破線は、図３０におけるブローカーノード１４Aの構成を示している。

　図３０、図３４、および、図３５の各モジュール配置も、ネットワーク１３内のアプリケーションリポジトリから必要に応じて動的に取得されることで実現することができる。

＜１０．イメージストリームとROIイベントストリームの例＞
　図３６は、全体イメージのイメージストリームと注目領域ROI単位のイベントストリームをネットワーク伝送する例を示している。

　時刻T11、T12、およびT13は、長周期T（=T12-T11=T13-T12）に対応して、全体イメージのイメージデータが出力されるタイミングを表し、時刻T11にフレーム画像P11が出力され、時刻T12にフレーム画像P12が出力され、時刻T13にフレーム画像P13が出力されて、ネットワーク１３を伝送される。

　一方、イベント画像E11乃至E21は、時刻T11から時刻T13の間に発生された所定の注目領域ROIのイベント画像を示している。注目領域ROIに対応するオブジェクトOBJには動きが発生しており、イベント画像E11乃至E21の位置は、イベントが検出される毎に異なっている。

　時刻T11から時刻T12の期間のイベント画像E11乃至E16それぞれに対応した超解像画像を生成するためには、イベント画像E11乃至E16に対応する全領域１１１のイメージデータとイベントデータが必要となる。

　イベント画像E11乃至E16に対応する全領域１１１のイメージデータは、伝送されるイメージデータが全体イメージのイメージストリームであるので、伝送されるイメージデータに含まれている。

　イベントストリームは、注目領域ROI単位のストリームであるので、イベント画像E11乃至E16に対応する全領域１１１は、時刻T12になるまで確定できない。そこで、ROIイベントフィルタ４５は、オブジェクトROI抽出エンジン４２と協調して、オブジェクトOBJの動きを検出または予測し、移動後のオブジェクト領域に関連する過去のイベント画像も合わせて伝送する。

　例えば、図３６において破線で囲まれたイベント画像E11およびE12について説明すると、図３７に示されるように、イベント画像E12の領域が検出または予測された時点で、ROIイベントフィルタ４５は、イベント画像E12の領域に関連する過去のイベントの領域１２１のイベントデータも、イベント画像E12とともに伝送する。

　このような処理を逐次的に実行することで、イベント画像E11乃至E16に対応する全領域１１１のイベントデータを伝送することができ、超解像処理ノード１４Cにおいて超解像処理を行うことができる。

　時刻T12から時刻T13の期間のイベント画像E16乃至E21それぞれについても、オブジェクトOBJの動きが検出または予測され、移動後のオブジェクト領域に関連する過去のイベント画像が伝送されることで、イベント画像E16乃至E21に対応する全領域１１２のイベントデータが超解像処理ノード１４Cまで伝送される。

　図３８は、イメージストリームとイベントストリームのどちらについても注目領域ROI単位でネットワーク伝送する例を示している。

　図３８において、時刻T11から時刻T13の期間に検出されるイベント画像E11乃至E21は、図３６と同様である。

　イメージストリームを注目領域ROI単位でネットワーク伝送する場合、時刻T11から時刻T12の期間のイベント画像E11乃至E16それぞれに対応した超解像画像を生成するためには、イメージデータについても、イベントデータと同様に、イベント画像E11乃至E16に対応する全領域１１１に対応する部分画像Pr11が必要となる。

　しかしながら、イベント画像E11乃至E16に対応する全領域１１１は、時刻T12になるまで確定できない。そこで、ROIイベントフィルタ４５は、時刻T12となり、イベント画像E11乃至E16に対応する全領域１１１が確定した時点で、全領域１１１に対応する部分画像Pr11と、イベント画像E11乃至E16に対応する全領域１１１に対応するイベントデータを伝送する。この場合、注目領域ROI単位のイメージストリームとイベントストリームが、長周期T遅れで伝送される。

　時刻T12から時刻T13の期間のイベント画像E16乃至E21それぞれについても、時刻T13となり、イベント画像E16乃至E21に対応する全領域１１２が確定した時点で、全領域１１２に対応する部分画像Pr12と、イベント画像E16乃至E21に対応する全領域１１２に対応するイベントデータが伝送される。

　図３８の伝送方法は、若干転送が遅くなっても、イメージストリームの帯域を抑えたい場合に有用である。

　図３９は、図３６または図３８の伝送方法により超解像処理ノード１４Cまでイメージストリームとイベントストリームが伝送され、超解像処理ノード１４Cにおいて超解像処理が実行された後の、超解像処理ノード１４Cから出力されるROI超解像ストリームの例を示している。

　図３９では、図３６および図３８のイベント画像E11乃至E21の発生タイミングに応じて、超解像画像F11乃至F21が生成され、ROI超解像ストリームとして伝送されている。

＜１１．ROIイベントストリームの間引き合成処理＞
　次に、ROIイベント中継モジュール６３が行うイベントストリームの間引き合成について説明する。

　ROIイベント中継モジュール６３は、下流の経路の超解像要件に基づいて、注目領域ROIのイベントストリームを必要に応じて間引き合成し、合成後のイベントストリームを送信することができる。

　図４０は、DVSの所定の一画素のイベントデータの時系列データ（イベント列）を示している。

　DVSでは、例えば、各画素に入射された受光量の対数値に応じた電圧信号が、画素信号として検出される。そして、DVSは、画素信号が表す輝度変化が所定の閾値Thを超えて明るく変化した場合に、正方向の輝度変化を表す“＋１”を出力し、所定の閾値Thを超えて暗く変化した場合に、負方向の輝度変化を表す“－１”を出力する。

　図４０の例において、DVSが出力した合成前のイベント列EV1では、時刻ｔ１において、“＋１”が出力され、時刻ｔ２において、“＋１”が出力され、時刻ｔ３において、“－１”が出力され、時刻ｔ４において、“－１”が出力され、時刻ｔ５において、“＋１”が出力され、時刻ｔ６において、“＋１”が出力されている。時刻ｔ１、ｔ２、ｔ３、・・・・ｔ６どうしの間隔は、図４０に示されるように一定ではない。

　イベントデータは、例えば、AER(Address-Event Representation)形式と呼ばれる以下の形式で表される。
　　e = (x, y, ts, p) 　　・・・・・・・・（１）

　式（１）において、ｘ，ｙは、輝度変化が発生した画素の座標を表し、tsは、輝度変化が発生した時刻に相当するタイムスタンプを表し、ｐは、輝度変化の極性（正方向または負方向）を表す。

　DVSが出力したイベント列EV1を、例えば、イベント頻度を１／２に間引き合成した場合、間引き合成後のイベント列EV2は、図４０に示されるようになる。

　ROIイベント中継モジュール６３は、例えば、時間方向に隣接する２つのイベントデータを積算することにより、間引き合成前のイベント列EV1から、間引き合成後のイベント列EV2を生成する。

　間引き合成後のイベントデータは、式（１）のAER形式を拡張した次の拡張AER形式で表すことができる。
　　ce = (x, y, ts, p, n) 　　・・・・・・・・（２）

　式（２）において、ｎは、度数を表し、例えば、時刻ｔ２のイベントデータでは、ｎ＝２となる。

　拡張AER形式において、度数ｎを１とすると、間引き合成前のイベント列EV1も表現可能である。

　なお、間引き合成の方法は、時間方向に隣接する複数のイベントデータを積算する以外の方法を採用してもよい。

　図４１は、所定の注目領域ROIのイベントストリームの間引き合成前と間引き合成後の例を示している。

　時刻T41乃至T42における間引き合成前のイベントストリームは、例えば、イベント画像E41乃至E52で構成される。

　時刻T41乃至T42における間引き合成後のイベントストリームは、例えば、イベント画像E41’,E43’,E46’,E49’,E52’で構成される。

　時刻T41乃至T42において、イメージストリームは、時刻T41におけるフレーム画像P41と、時刻T42におけるフレーム画像P42で構成される。

＜１２．画像解析ネットワークシステムの処理の流れ＞
　次に、図４２のフローチャートを参照して、画像解析ネットワークシステム１による超解像画像解析処理の装置間の流れについて説明する。

　なお、図４２の超解像画像解析処理が開始される前には、解析装置１２のROIサブスクライバ８１が、中継処理ノード１４BのROIサブスクリプション中継モジュール６１を介して、ブローカーノード１４AのROIサブスクリプションブローカ５１が発行するROIカタログを取得するためのROIカタログ用のマルチキャストに参加する処理が行われている。

　初めに、ステップＳ１において、センサデバイス１１は、イベントを検出するとスナップショットを取得する。具体的には、センサデバイス１１のDVSがイベントを検出すると、オブジェクトROI抽出エンジン４２を起動させるとともに、イメージセンサに撮像を行わせる。そして、イメージセンサが撮像したフレーム画像が、スナップショットとしてオブジェクトROI抽出エンジン４２に供給される。

　ステップＳ２において、センサデバイス１１は、取得したスナップショットに基づいてオブジェクトを認識する処理を実行し、認識したオブジェクト毎に注目領域ROIを割り当てる。さらに、センサデバイス１１は、スナップショットと、注目領域ROIを特定するROI特定情報とに基づいて、ROIカタログを生成し、解析装置１２へ通知する。ROIカタログは、ブローカーノード１４A、１以上の中継処理ノード１４Bを経由して、解析装置１２まで伝送される。

　解析装置１２は、ステップＳ３において、センサデバイス１１から通知されたROIカタログを取得して参照し、自身が認識処理する注目領域ROIを選択する。そして、解析装置１２は、選択した注目領域ROIのROIサブスクリプションリクエストを生成し、１以上の中継処理ノード１４Bを経由して、ブローカーノード１４Aへ通知する。ここで、ROIサブスクリプションリクエストは、自身が認識処理する注目領域ROIの超解像イメージストリームを連続的に取得したいことの要求である。ROIサブスクリプションリクエストには、選択した注目領域ROIのグローバルROI-IDと、超解像要件とが含まれる。

　オーケストレータ１４Dは、ステップＳ４において、各中継処理ノード１４Bが中継する、ROIカタログとROIサブスクリプションリクエストを取得する。オーケストレータ１４Dは、ROIカタログから推測されるストリーム帯域と、各中継処理ノード１４Bにおいて超解像処理が行われた後のROI超解像イメージストリームのストリーム帯域等に基づいて、できるだけ解析装置１２側に近い下流側の中継処理ノード１４Bを、超解像処理ノード１４Cに決定し、通知する。

　ステップＳ５において、超解像処理ノード１４Cであることが通知された中継処理ノード１４Bは、超解像処理ノード１４Cに必要なモジュール、具体的には、超解像処理モジュール７２をネットワーク１３内のアプリケーションリポジトリから取得する。

　ステップＳ４およびＳ５の処理以降、センサデバイス１１と解析装置１２との間のネットワーク１３内の所定の１つのノード１４であって、できるだけ解析装置１２側に近い下流側の中継処理ノード１４Bが、超解像処理ノード１４Cとして動作する。

　一方、ブローカーノード１４Aは、ステップＳ６において、複数の解析装置１２それぞれから供給されるROIサブスクリプションリクエストに含まれる、注目領域ROIごとの超解像要件に基づいて、イメージセンサのフレームレートと、DVSのイベント感度とを決定し、センサデバイス１１へ通知する。

　ステップＳ４およびＳ５とステップＳ６の処理は並行して実行することができる。

　ステップＳ７において、センサデバイス１１は、長周期のフレームレートで撮像を行い、その結果生成される全体イメージのイメージストリームを超解像処理ノード１４C宛に送信するとともに、認識したオブジェクト毎のイベントを検出して、注目領域ROI毎のイベントストリームを超解像処理ノード１４C宛に送信する。フレーム画像およびイベント画像に含まれるオブジェクトは、動きに応じてトラッキングされる。

　全体イメージのイメージストリームおよび注目領域ROI毎のイベントストリームは、ブローカーノード１４Aと、１以上の中継処理ノード１４Bとを経由して、超解像処理ノード１４Cまで転送される。

　ステップＳ８において、途中経路の所定の中継処理ノード１４Bは、下流の経路の超解像要件に基づいて、注目領域ROIのイベントストリームを必要に応じて間引き合成し、イベント頻度を低くした低分解能の注目領域ROIのイベントストリームを生成して、次の中継処理ノード１４Bまたは超解像処理ノード１４Cへ転送する。

　ステップＳ９において、超解像処理ノード１４Cは、全体イメージのイメージストリームと注目領域ROIのイベントストリームとを用いて、超解像処理を実行し、注目領域ROIの超解像イメージストリーム（ROI超解像イメージストリーム）を生成する。生成されたROI超解像イメージストリームは、解析装置１２宛に送信される。

　超解像処理ノード１４Cが、解析装置１２と接続されたネットワーク１３内のエッジのノード１４ではなく、超解像処理ノード１４Cと解析装置１２との間に中継処理ノード１４B’が介在する場合には、ROI超解像イメージストリームが、中継処理ノード１４B’から解析装置１２へ転送される。

　ステップＳ１０において、解析装置１２は、ROI超解像イメージストリームを取得し、注目領域ROIの超解像画像を解析する画像解析処理を行う。例えば、解析装置１２は、注目領域ROIの超解像画像に含まれるオブジェクトOBJの人物を同定（認識）したり、人物の行動（危険行動）を予測（判定）する処理などを行う。

　画像解析ネットワークシステム１の各装置は、以上のように超解像画像解析処理を実行する。これにより、超解像の画像ストリームを効率的にネットワーク伝送することができる。

　なお、解析装置１２が画像解析処理を実行した後の流れについては省略するが、例えば、解析結果を収集する所定のデータサーバ等へ、解析結果が送信される。

　次に、図４３乃至図４５のフローチャートを参照して、画像解析ネットワークシステム１のモジュール単位の、より詳細な超解像画像解析処理の流れについて説明する。

　初めに、図４３のステップＳ２１において、センサデバイス１１のイベント・イメージセンサ４１がイベントを検出すると、オブジェクトROI抽出エンジン４２を起動させる。

　続いて、ステップＳ２２において、イベント・イメージセンサ４１は、撮像を行い、その結果得られたフレーム画像を、スナップショットとしてオブジェクトROI抽出エンジン４２に供給する。

　ステップＳ２３において、オブジェクトROI抽出エンジン４２は、イベント・イメージセンサ４１からのスナップショットに基づいて、オブジェクトを認識する処理を実行し、認識したオブジェクト毎に注目領域ROIを割り当てる。そして、オブジェクトROI抽出エンジン４２は、オブジェクトを特定したときのスナップショットと、オブジェクト毎に割り当てた注目領域ROIを特定するROI特定情報を、ROIカタログジェネレータ４３へ通知する。

　ステップＳ２４において、ROIカタログジェネレータ４３は、オブジェクトROI抽出エンジン４２から供給されたスナップショットとROI特定情報とに基づいて、ROIカタログを生成し、ブローカーノード１４AのROIサブスクリプションブローカ５１に通知する。ROIカタログは、スナップショットと、オブジェクトごとのROI特定情報とで構成され、ROI特定情報は、グローバルROI-IDとオブジェクト属性情報とを含む。ROIサブスクリプションブローカ５１へ通知されたROIカタログは、１以上の中継処理ノード１４BのROIサブスクリプション中継モジュール６１を経由して、各解析装置１２のROIサブスクライバ８１へ供給される。

　ステップＳ２５において、各解析装置１２のROIサブスクライバ８１は、センサデバイス１１のROIカタログジェネレータ４３から供給されたROIカタログに基づいて、１以上の注目領域ROIのうち、自身が認識処理する注目領域ROIを選択する。そして、ROIサブスクライバ８１は、選択した注目領域ROIのグローバルROI-IDと、超解像要件とを含むROIサブスクリプションリクエストを生成する。生成されたROIサブスクリプションリクエストは、１以上の中継処理ノード１４BのROIサブスクリプション中継モジュール６１を経由して、ブローカーノード１４AのROIサブスクリプションブローカ５１へ通知される。

　図４４のステップＳ４１において、オーケストレータ１４Dのオーケストレーションモジュール９１は、各中継処理ノード１４BのROIサブスクリプション中継モジュール６１が伝送する、ROIカタログとROIサブスクリプションリクエストを取得する。そして、オーケストレーションモジュール９１は、各解析装置１２が解析処理を行う注目領域ROIに基づいて、注目領域ROI毎のセンサデバイス１１から各解析装置１２までの経路と、超解像処理を実行する超解像処理ノード１４Cを決定する。センサデバイス１１から各解析装置１２までの経路に存在する超解像処理ノード１４Cに決定された中継処理ノード１４Bは、超解像処理モジュール７２をネットワーク１３内のアプリケーションリポジトリから取得する。決定された経路は、中継処理ノード１４BのROIサブスクリプション中継モジュール６１や、ブローカーノード１４AのROIサブスクリプションブローカ５１へ通知される。決定された経路は、中継処理ノード１４Bにおいて、ROIサブスクリプション中継モジュール６１から、ROIイメージ中継モジュール６２およびROIイベント中継モジュール６３にも通知され、ブローカーノード１４Aにおいて、ROIサブスクリプションブローカ５１からROIイメージブローカ５２およびROIイベントブローカ５３にも通知される。

　続いて、ステップＳ４２において、ROIサブスクリプションブローカ５１は、複数の解析装置１２それぞれのROIサブスクライバ８１から通知されたROIサブスクリプションリクエストに含まれる注目領域ROIごとの超解像要件に基づいて、イメージセンサのフレームレートを決定し、ROIイメージブローカ５２を介して、センサデバイス１１のROIイメージフィルタ４４およびイベント・イメージセンサ４１へ通知する。

　続いて、ステップＳ４３において、ROIサブスクリプションブローカ５１は、ROIサブスクリプションリクエストに含まれる注目領域ROIごとの超解像要件に基づいて、DVSのイベント感度を決定し、ROIイベントブローカ５３を介して、センサデバイス１１のROIイベントフィルタ４５およびイベント・イメージセンサ４１へ通知する。

　ステップＳ４４において、センサデバイス１１のイベント・イメージセンサ４１は、長周期による撮像を行ってフレーム画像を生成し、その全体イメージのフレーム画像を、ROIイメージフィルタ４４に供給する。

　ステップＳ４５において、ROIイメージフィルタ４４は、イベント・イメージセンサ４１から供給された全体イメージのフレーム画像を、必要に応じてフィルタリングし、ブローカーノード１４AのROIイメージブローカ５２に供給する。

　すなわち、イメージストリームは、全体イメージで送信される場合と、注目領域ROI単位で送信される場合とがあり、注目領域ROI単位で送信される場合に、ROIイメージフィルタ４４は、オブジェクトROI抽出エンジン４２から供給されたスナップショットとオブジェクト毎のROI特定情報とに基づいて、全体イメージのフレーム画像を注目領域ROI単位にフィルタリングし、フィルタリング処理後の注目領域画像を、ブローカーノード１４AのROIイメージブローカ５２に供給する。全体イメージで送信される場合には、フィルタリングされない全体イメージのフレーム画像が、ブローカーノード１４AのROIイメージブローカ５２に供給される。

　ステップＳ４６において、イベント・イメージセンサ４１は、イベントを検出してイベント画像を生成し、ROIイベントフィルタ４５に供給する。

　ROIイベントフィルタ４５は、ステップＳ４７において、オブジェクトROI抽出エンジン４２から供給されたスナップショットとオブジェクト毎のROI特定情報とに基づいて、イベント・イメージセンサ４１から供給されたイベント画像をフィルタリングし、フィルタリング処理後のイベント画像を、ブローカーノード１４AのROIイベントブローカ５３に供給する。

　フレーム画像に対するステップＳ４４およびＳ４５の処理と、イベント画像に対するステップＳ４６およびＳ４７の処理は、並行して実行することができる。

　フレーム画像は、一定周期（長周期）で順次生成され、イメージストリームとして、ROIイメージブローカ５２に供給される。イベント画像は、イベントの検出毎に順次生成され、イベントストリームとして、ROIイベントブローカ５３に供給される。

　次に、図４５のステップＳ６１において、ROIイベントブローカ５３は、注目領域ROIごとの経路に基づいて、ROIイメージフィルタ４４から供給されたイベントストリームを、中継処理ノード１４BのROIイベント中継モジュール６３に転送する。

　ROIイベント中継モジュール６３は、ステップＳ６２において、注目領域ROIのイベントストリームを中継する。また、ROIイベント中継モジュール６３は、下流の経路の超解像要件に基づいて、注目領域ROIのイベントストリームを必要に応じて間引き合成し、イベント頻度を低くした低分解能の注目領域ROIのイベントストリームを生成し、超解像処理モジュール７２に供給する。

　ステップＳ６３において、ROIイメージブローカ５２は、注目領域ROIごとの経路に基づいて、ROIイメージフィルタ４４から供給されたイメージストリームを、中継処理ノード１４BのROIイメージ中継モジュール６２に供給する。ROIイメージ中継モジュール６２は、送信されてきた全体イメージまたは注目領域ROIのイメージストリームをさらに中継して、超解像処理モジュール７２に転送する。

　ステップＳ６４において、超解像処理モジュール７２は、中継処理ノード１４BのROIイメージ中継モジュール６２から供給された全体イメージまたは注目領域ROIのイメージストリームと、ROIイベント中継モジュール６３から供給された注目領域ROIのイベントストリームとを用いて、超解像処理を実行する。そして、超解像処理モジュール７２は、超解像処理により得られた、注目領域ROIの超解像イメージストリーム（ROI超解像イメージストリーム）を、解析装置１２の解析モジュール８２に供給する。

　ステップＳ６５において、解析モジュール８２は、超解像処理モジュール７２からROI超解像イメージストリームを取得し、注目領域ROIの超解像画像を解析する画像解析処理を行う。例えば、解析モジュール８２は、注目領域ROIの超解像画像に含まれるオブジェクトOBJの人物を同定（認識）したり、人物の行動（危険行動）を予測（判定）する処理などを行う。

　画像解析ネットワークシステム１の各モジュールは、以上のように超解像画像解析処理を実行する。これにより、超解像の画像ストリームを効率的にネットワーク伝送することができる。

＜１３．ストリームの伝送フォーマットの例＞
　次に、図４６を参照しながら、マルチキャストで配信されるイメージストリームとイベントストリームの伝送フォーマットについて説明する。

　注目領域ROI単位にマルチキャストで配信されるイメージストリームとイベントストリームは、イメージストリームチャネルとイベントストリームチャネルの２つのトランスポートチャネルからなる。

　図４６は、イメージストリームチャネルとイベントストリームチャネルのフォーマットを示す図である。

　イメージストリームチャネルは、注目領域ROIごとのイメージデータを伝送する場合には、注目領域ROIの数に応じた複数のチャネルとなるが、全体イメージのイメージデータを伝送する場合には、１つのチャネルとなる。

　イメージストリームチャネルは、各時刻に対応した複数のイメージパケット群で構成され、各イメージパケット群は、１以上のイメージパケットからなる。イベントストリームチャネルは、各時刻に対応した複数のイベントパケット群で構成され、各イベントパケット群は、１以上のイベントパケットからなる。

　イメージパケットは、イメージパケットヘッダと、イメージパケットペイロードとからなる。イメージパケットヘッダは、グローバルROI-ID、Packet Sequence Number、および、Capture Timeを含む。イメージパケットペイロードには、全体イメージまたは注目領域ROIのイメージデータが分割されて、所定のイメージフォーマットで格納される。Packet Sequence Numberは、パケットペイロード単位で割り当てられた、チャネルで一意な番号であり、十分な長さで周期的にゼロリセットされる。

　イベントパケットは、イベントパケットヘッダと、イベントパケットペイロードとからなる。イベントパケットヘッダは、グローバルROI-ID、Packet Sequence Number、および、Reference Capture Timeを含む。Reference Capture Timeは、参照されるイメージパケットのCapture Timeを表す。

　ここで、イメージストリームチャネルに、全体イメージのイメージデータが格納される場合には、複数のイベントストリームチャネルそれぞれが参照するイメージストリームが共有されるので、異なるイベントストリームチャネルで転送されるイベントパケットのReference Image Capture Timeには、共有先の全体イメージストリームを示すグローバルROI-IDが付記される。

　図４７は、イベントパケットペイロードのフォーマットを示す図である。

　イベントパケットペイロードには、例えば、上述した式（１）の“e”で表されるAER形式、または、式（２）の“ce”で表される拡張AER形式で、複数のイベントデータが格納される。

　なお、イベントパケットペイロードに格納されるイベントデータの形式は、AER形式または拡張AER形式に限定されず、その他の形式であってもよい。例えば、イベントフレームやTime Surface等と呼ばれる形式で格納してもよい。イベントパケットペイロードには、イベントデータの形式を識別するイベントデータフォーマット識別子(一意なURL)とともに、そのイベントデータフォーマット識別子が表す形式でエンコードされたイベントデータを格納してもよい。また、イベントデータフォーマット識別子は、イベントパケットヘッダに格納してもよい。

　また、グローバルROI-IDに対応するイメージストリームチャネル、または、イベントストリームチャネルのセッション(仮想的なパス)が下位レイヤで確立される場合には、パケットごとのグローバルROI-IDを省略することもできる。例えば、グローバルROI-IDをIPマルチキャストアドレスに対応させたり、グローバルROI-IDを下位レイヤのラベル(MPLS（Multi Protocol Label Switching)のラベルやGMPLS(Generalized MPLS)におけるλ(波長)等）に対応させることもできる。

　ROIサブスクリプションブローカ５１は、イメージストリームチャネルとイベントストリームチャネルの経路を確立する際に、転送要件に沿って必要なQoSクラスでネットワーク１３上のリソースをリザーブする。例えば、超解像要件に合わせて形成される中継処理ノード１４B間のマルチキャストツリーの各リンクの帯域要件に合わせて必要帯域を確保する。

　ROIサブスクリプションブローカ５１は、イメージストリームチャネルとイベントストリームチャネルの関連するパケット群が超解像処理されるタイミングが合うように同期されて転送されるように制御する。マルチキャストされるネットワーク１３のチャネルリソースの総量に制限がある場合は、ROIサブスクリプションブローカ５１は、注目領域ROI毎のサブスクリプションリクエストの大小に合わせて、注目領域ROIに優先度を割り当て、優先度の高いものから、QoSクラスが高品質(低遅延、低エラーレート、広帯域等)となるように割り当てる。

　また、ベストエフォートな転送になる場合には、ROIサブスクリプションブローカ５１は、相互に関連するパケット群が相対的に同期して超解像処理ノード１４Cに到着するように、経路上の中継処理ノード１４Bがパケット間の転送時間調整を行えるようにする。例えば、最初の時刻T(k)までにCapture-Time=T(n)を持つイメージパケット群が到着し、次の時刻T(k+1)までにReference-Image-Capture-Time =T(n)を持つのすべてのイベントパケット群が到着し、次の時刻T(k+2)までにCapture-Time=T(n+1)を持つイメージパケット群が到着し、時刻T(k+3)までにReference-Image-Capture-Time =T(n+1)を持つすべてのイベントパケット群が到着するというように、すなわち、到着時刻順序が、”Capture-Time=T(n)を持つ最後のイメージパケット” < ”Reference-Image-Capture-Time =T(n)を持つ最後のイベントパケット” < ”Capture-Time=T(n+1)を持つ最後のイメージパケット” < ”Reference-Image-Capture-Time =T(n+1)を持つ最後のイベントパケット”となるように、経路上の中継処理ノード１４Bが転送時間調整を行えるようにする。

　超解像処理ノード１４Cの超解像処理モジュール７２と、解析装置１２の解析モジュール８２との間で伝送されるROI超解像イメージストリームは、図４６のイメージストリームチャネルにより伝送され、ROI超解像処理された注目領域ROIの超解像画像のイメージデータが分割されて、イメージパケットのイメージパケットペイロードに格納されて転送される。

＜１４．コンピュータ構成例＞
　上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているマイクロコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

　図４８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。

　コンピュータにおいて、CPU（Central Processing Unit）３０１，ROM（Read Only Memory）３０２，RAM（Random Access Memory）３０３は、バス３０４により相互に接続されている。

　バス３０４には、さらに、入出力インタフェース３０５が接続されている。入出力インタフェース３０５には、入力部３０６、出力部３０７、記憶部３０８、通信部３０９、及びドライブ３１０が接続されている。

　入力部３０６は、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部３０７は、ディスプレイ、スピーカ、出力端子などよりなる。記憶部３０８は、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部３０９は、ネットワークインタフェースなどよりなる。ドライブ３１０は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブル記録媒体３１１を駆動する。

　以上のように構成されるコンピュータでは、CPU３０１が、例えば、記憶部３０８に記憶されているプログラムを、入出力インタフェース３０５及びバス３０４を介して、RAM３０３にロードして実行することにより、上述した一連の処理が行われる。RAM３０３にはまた、CPU３０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

　コンピュータ（CPU３０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体３１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

　コンピュータでは、プログラムは、リムーバブル記録媒体３１１をドライブ３１０に装着することにより、入出力インタフェース３０５を介して、記憶部３０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部３０９で受信し、記憶部３０８にインストールすることができる。その他、プログラムは、ROM３０２や記憶部３０８に、あらかじめインストールしておくことができる。

　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

　なお、本明細書において、フローチャートに記述されたステップは、記載された順序に沿って時系列的に行われる場合はもちろん、必ずしも時系列的に処理されなくとも、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで実行されてもよい。

　なお、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

　本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

　例えば、上述した実施の形態の全てまたは一部を組み合わせた形態を採用することができる。

　例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、本明細書に記載されたもの以外の効果があってもよい。

　なお、本技術は、以下の構成を取ることができる。
＜１＞
　ネットワーク接続装置が、
　センサデバイスから複数の画像処理装置までのネットワーク内の経路にある装置のなかから、前記センサデバイスが生成した画像に含まれる注目領域単位の前記画像を超解像処理することにより前記注目領域の超解像画像を生成する超解像処理ノードを決定する
　ネットワークの制御方法。
＜２＞
　前記超解像処理ノードは、前記センサデバイスが生成した一定周期のフレーム画像と、ランダムに発生するイベント画像から、前記注目領域の超解像画像を生成する
　前記＜１＞に記載のネットワークの制御方法。
＜３＞
　前記センサデバイスから前記超解像処理ノードまでは、前記フレーム画像のストリームデータと、前記イベント画像のストリームデータが伝送され、
　前記超解像処理ノードから前記画像処理装置までは、前記注目領域の超解像画像のストリームデータが伝送される
　前記＜２＞に記載のネットワークの制御方法。
＜４＞
　前記ネットワーク内の経路にある各装置は、下流の経路の要件に基づいて前記イベント画像をフィルタリングし、フィルタリング後の前記イベント画像のストリームデータを供給する
　前記＜３＞に記載のネットワークの制御方法。
＜５＞
　前記ネットワーク内の経路にある各装置は、中継するデータをキャッシュする
　前記＜１＞ないし＜４＞のいずれかに記載のネットワークの制御方法。
＜６＞
　前記ネットワーク接続装置は、前記複数の画像処理装置それぞれが要求する前記注目領域の超解像画像に基づいて、前記超解像処理ノードを決定する
　前記＜１＞ないし＜５＞のいずれかに記載のネットワークの制御方法。
＜７＞
　前記ネットワーク接続装置は、前記画像に含まれる前記注目領域を特定する注目領域特定情報から推測されるストリーム帯域と、前記複数の画像処理装置それぞれが要求する前記注目領域の情報に基づく中継処理ノードのストリーム帯域と、前記超解像処理が行われた後の前記超解像画像のストリーム帯域とに基づいて、前記超解像処理ノードを決定する
　前記＜１＞ないし＜６＞のいずれかに記載のネットワークの制御方法。
＜８＞
　前記ネットワーク接続装置は、前記画像処理装置の数と、前記画像に含まれる前記注目領域の数とに基づいて、前記超解像処理ノードを決定する
　前記＜１＞ないし＜７＞のいずれかに記載のネットワークの制御方法。
＜９＞
　前記ネットワーク接続装置は、少なくとも前記センサデバイスよりも前記画像処理装置に近い装置を、前記超解像処理ノードに決定する
　前記＜１＞ないし＜８＞のいずれかに記載のネットワークの制御方法。
＜１０＞
　前記超解像処理ノードは、前記画像処理装置と最初に接続される前記ネットワーク内の装置である
　前記＜１＞ないし＜９＞のいずれかに記載のネットワークの制御方法。
＜１１＞
　前記画像処理装置は、前記センサデバイスに、処理対象の前記注目領域と、自身の処理に必要十分な超解像要件とを要求する
　前記＜１＞ないし＜１０＞のいずれかに記載のネットワークの制御方法。
＜１２＞
　前記超解像要件は、前記センサデバイスが生成するフレーム画像のフレームレートと、前記センサデバイスが生成するイベント画像のイベント感度とで構成される
　前記＜１＞ないし＜１１＞のいずれかに記載のネットワークの制御方法。
＜１３＞
　前記超解像処理ノードに決定された前記装置は、前記ネットワーク内のリポジトリから、前記超解像処理を行うモジュールを取得する
　前記＜１＞ないし＜１２＞のいずれかに記載のネットワークの制御方法。
＜１４＞
　前記センサデバイスは、イメージセンサと、イベントセンサとを含む
　前記＜１＞ないし＜１３＞のいずれかに記載のネットワークの制御方法。
＜１５＞
　センサデバイスから複数の画像処理装置までのネットワーク内の経路にある装置のなかから、前記センサデバイスが生成した画像に含まれる注目領域単位の前記画像を超解像処理することにより前記注目領域の超解像画像を生成する超解像処理ノードを決定するモジュールを備える
　画像処理システム。

　なお、本開示は、以下の構成を取ることができる。
＜１＞
　ネットワーク接続装置が、
　センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定する
　ネットワークの制御方法。
＜２＞
　前記ネットワーク接続装置は、前記マニフェストに記載された、前記アプリケーションを配置する際の評価軸と、その場合のアプリケーション配置の優先順位に基づいて決定する
　前記＜１＞に記載のネットワークの制御方法。
＜３＞
　前記マニフェストは、前記評価軸として、ネットワーク転送遅延による処理遅延を含む
　前記＜２＞に記載のネットワークの制御方法。
＜４＞
　前記マニフェストは、前記評価軸として、前記ネットワークのトラフィックを含む
　前記＜２＞または＜３＞に記載のネットワークの制御方法。
＜５＞
　前記マニフェストは、前記評価軸として、前記アプリケーションの処理速度を含む
　前記＜２＞ないし＜４＞のいずれかに記載のネットワークの制御方法。
＜６＞
　前記マニフェストは、前記評価軸として、前記アプリケーションの実行コストを含む
　前記＜２＞ないし＜５＞のいずれかに記載のネットワークの制御方法。
＜７＞
　前記マニフェストは、前記評価軸として、ストレージコストを含む
　前記＜２＞ないし＜６＞のいずれかに記載のネットワークの制御方法。
＜８＞
　前記マニフェストは、前記評価軸として、前記センサデータの再利用性を含む
　前記＜２＞ないし＜７＞のいずれかに記載のネットワークの制御方法。
＜９＞
　前記マニフェストは、前記評価軸として、要求されたサービスに対応する本処理を実行する前に前処理を実行するかを含む
　前記＜２＞ないし＜８＞のいずれかに記載のネットワークの制御方法。
＜１０＞
　前記ネットワーク接続装置は、前記アプリケーションとして、要求されたサービスに対応する本処理を実行するアプリケーションと、前記本処理の前処理を実行するアプリケーションの最適な場所を決定する
　前記＜１＞ないし＜９＞のいずれかに記載のネットワークの制御方法。
＜１１＞
　前記前処理は、非圧縮の前記センサデータを圧縮する処理である
　前記＜１０＞に記載のネットワークの制御方法。
＜１２＞
　前記前処理は、前記本処理の内容に合わせて個別化された処理である
　前記＜１０＞に記載のネットワークの制御方法。
＜１３＞
　前記ネットワーク接続装置は、前記前処理を実行するアプリケーションを、前記本処理を実行するアプリケーションの前段に複数配置する
　前記＜１０＞ないし＜１２＞のいずれかに記載のネットワークの制御方法。
＜１４＞
　前記アプリケーション配置の優先順位は、アプリケーション配置場所としての、前記センサデバイス、エッジクラウド、および、センタークラウドの優先順位である
　前記＜２＞ないし＜１３＞のいずれかに記載のネットワークの制御方法。
＜１５＞
　前記ネットワーク接続装置は、前記センサデバイスから複数の画像処理装置までのネットワーク内の経路にある装置のなかから、前記センサデバイスが生成した画像に含まれる注目領域単位の前記画像を超解像処理することにより前記注目領域の超解像画像を生成するアプリケーションを実行させる最適な場所を決定する
　前記＜１＞ないし＜１４＞のいずれかに記載のネットワークの制御方法。
＜１６＞
　センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定するオーケストレータ
　を備えるデータ処理システム。

　１　画像解析ネットワークシステム，　１１　センサデバイス，　１２　解析装置，　１３　ネットワーク，　１４A　ブローカーノード，　１４B　中継処理ノード，　１４C　超解像処理ノード，　１４D　オーケストレータ，　１４　ノード，　４１　イベント・イメージセンサ，　４２　オブジェクトROI抽出エンジン，　４３　ROIカタログジェネレータ，　４４　ROIイメージフィルタ，　４５　ROIイベントフィルタ，　５１　ROIサブスクリプションブローカ，　５２　ROIイメージブローカ，　５３　ROIイベントブローカ，　６１　ROIサブスクリプション中継モジュール，　６２　ROIイメージ中継モジュール，　６３　ROIイベント中継モジュール，　７１　ROIサブスクリプション中継モジュール，　７２　超解像処理モジュール，　８１　ROIサブスクライバ，　８２　解析モジュール，　９１　オーケストレーションモジュール，　１０１　ROI超解像ストリーム中継モジュール，　３０１　CPU，　３０２　ROM，　３０３　RAM，　３０６　入力部，　３０７　出力部，　３０８　記憶部，　３０９　通信部，　３１０　ドライブ，　５００　データ処理システム，　５１１　センサ，　５１２　エッジデバイス，　５１３　センサ／エッジ，　５２１　クラウド，　５２２　エッジクラウド，　５２３　センタークラウド，　５３１，５３２　アプリケーションプラットフォーム，　５３３　ネットワークモニタ，　５３４　アプリケーションプラットフォーム，　５３５　ネットワークモニタ，　５３６　オーケストレータ，　５３７　アプリケーションリポジトリ，　５３８，５３９　ネットワーク，　８００　ネットワークシステム，　８０５　コンピュータ，　８１０　ネットワーク，　８１５　リモートコンピュータ，　８２０　ウェブサーバ，　８２５　クラウドストレージサーバ，　８３０　コンピュータサーバ，　８３５　プロセッサ，　８４０　メモリ，　８４５　不揮発性ストレージ，　８４８　プログラム，　８６０　外部デバイス

Claims

　ネットワーク接続装置が、
　センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定する
　ネットワークの制御方法。
　前記ネットワーク接続装置は、前記マニフェストに記載された、前記アプリケーションを配置する際の評価軸と、その場合のアプリケーション配置の優先順位に基づいて決定する
　請求項１に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、ネットワーク転送遅延による処理遅延を含む
　請求項２に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、前記ネットワークのトラフィックを含む
　請求項２に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、前記アプリケーションの処理速度を含む
　請求項２に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、前記アプリケーションの実行コストを含む
　請求項２に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、ストレージコストを含む
　請求項２に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、前記センサデータの再利用性を含む
　請求項２に記載のネットワークの制御方法。
　前記マニフェストは、前記評価軸として、要求されたサービスに対応する本処理を実行する前に前処理を実行するかを含む
　請求項２に記載のネットワークの制御方法。
　前記ネットワーク接続装置は、前記アプリケーションとして、要求されたサービスに対応する本処理を実行するアプリケーションと、前記本処理の前処理を実行するアプリケーションの最適な場所を決定する
　請求項１に記載のネットワークの制御方法。
　前記前処理は、非圧縮の前記センサデータを圧縮する処理である
　請求項１０に記載のネットワークの制御方法。
　前記前処理は、前記本処理の内容に合わせて個別化された処理である
　請求項１０に記載のネットワークの制御方法。
　前記ネットワーク接続装置は、前記前処理を実行するアプリケーションを、前記本処理を実行するアプリケーションの前段に複数配置する
　請求項１０に記載のネットワークの制御方法。
　前記アプリケーション配置の優先順位は、アプリケーション配置場所としての、前記センサデバイス、エッジクラウド、および、センタークラウドの優先順位である
　請求項２に記載のネットワークの制御方法。
　前記ネットワーク接続装置は、前記センサデバイスから複数の画像処理装置までのネットワーク内の経路にある装置のなかから、前記センサデバイスが生成した画像に含まれる注目領域単位の前記画像を超解像処理することにより前記注目領域の超解像画像を生成するアプリケーションを実行させる最適な場所を決定する
　請求項１に記載のネットワークの制御方法。
　センサデバイスと、それに接続されたネットワーク内の経路にある装置のなかから、前記センサデバイスで生成されたセンサデータを処理するアプリケーションを実行させる最適な場所を、マニフェストに基づいて決定するオーケストレータ
　を備えるデータ処理システム。