JP7764866B2 - データ処理装置および方法、並びに、データ処理システム - Google Patents

Description

本技術は、データ処理装置および方法、並びに、データ処理システムに関し、特に、ネットワークリソースを動的に確保することができるようにしたデータ処理装置および方法、並びに、データ処理システムに関する。

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

DVSが生成するイベントデータは、時間粒度が極めて細かいデータとなっている。DVSから生成された大量のデータを、見境なくネットワークに注入すると、ネットワークのキャパシティに制限がある場合にはネットワークが破綻し、本当に必要なデータが正しく処理できない可能性がある。反対に、大量のデータに備え、常にネットワーク内に過剰な計算リソースを確保しておく場合には、過剰なコストが発生する。

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

近年、IoTデバイスと、IoTデバイスから取得したセンシングデータのAI(人工知能)等を用いた利活用が進んでいる。DVS利用の有り無しに関わらず、リソース枯渇や無駄なエネルギー消費が大きな問題となる可能性があるため、ネットワークリソースを必要な時に逐次動的に確保できるような方法が求められる。

本技術は、このような状況に鑑みてなされたものであり、ネットワークリソースを動的に確保することができるようにするものである。

本技術の第１の側面のデータ処理装置は、イメージセンサのIフレーム生成のタイミングにともない、前記イメージセンサから転送されるイメージデータのオブジェクト認識処理に必要なリソースをネットワーク上に確保する管理モジュールを備える。

本技術の第１の側面のデータ処理方法は、データ処理装置が、イメージセンサのIフレーム生成のタイミングにともない、前記イメージセンサから転送されるイメージデータのオブジェクト認識処理に必要なリソースをネットワーク上に確保する。

本技術の第１の側面においては、イメージセンサのIフレーム生成のタイミングにともない、前記イメージセンサから転送されるイメージデータのオブジェクト認識処理に必要なリソースがネットワーク上に確保される。

本技術の第２の側面のデータ処理システムは、イメージセンサにより生成されたイメージデータをネットワークへ転送するクライアントデバイスと、前記イメージセンサのIフレーム生成のタイミングにともない、前記イメージデータのオブジェクト認識処理に必要なリソースを前記ネットワーク上に確保する管理モジュールとを備える。

本技術の第２の側面においては、イメージセンサにより生成されたイメージデータがネットワークへ転送され、前記イメージセンサのIフレーム生成のタイミングにともない、前記イメージデータのオブジェクト認識処理に必要なリソースが前記ネットワーク上に確保される。

ネットワークには、少なくとも２つの装置と、ある装置から、他の装置に対して、情報の伝達をできるようにした仕組みとが含まれる。ネットワークは、計算および記憶を行うアプリケーションリソースと、データの転送を行うためのネットワーク/トランスポートリソースとを含む。ネットワークを介して通信する装置は、独立した装置どうしであっても良いし、１つの装置を構成している内部ブロックどうしであっても良い。

管理モジュールは、コンピュータにプログラムを実行させることにより実現することができる。プログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。

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

本技術の一実施の形態であるデータ処理システムの構成例を示すブロック図である。 オブジェクト認識処理の典型的な処理の流れを説明する図である。 DVSとFBSそれぞれによるイメージデータとイベントデータの生成を説明する図である。 DVSによる物体検出を説明する図である。 DVSを実装していない場合のデータ処理フロー図である。 DVSを実装している場合のデータ処理フロー図である。 図５のDVS実装有りと図６のDVS実装無しのオブジェクト認識処理を比較した処理フロー図である。 本技術の他の実施の形態であるデータ処理システムの構成例を示すブロック図である。 ユーザ装置の詳細構成例を示すブロック図である。 リソースマネージャの詳細構成例を示すブロック図である。 ObjDetectionEASの詳細構成例を示すブロック図である。 DVSを実装している場合のデータ処理フロー図である。 DVSを実装していない場合のデータ処理フロー図である。 リソースマネージャが管理するリソースの構成例を示す図である。 DVSを実装していない場合のアプリケーションリソースのライフサイクル管理を説明する図である。 DVSを実装している場合のアプリケーションリソースのライフサイクル管理を説明する図である。 5Gネットワークのネットワーク/トランスポートの構成例を示す図である。 5Gネットワークである場合のネットワーク/トランスポートリソースのライフサイクル管理を説明する図である。 IOWNネットワークのネットワーク/トランスポートの構成例を示す図である。 IOWNネットワークである場合のネットワーク/トランスポートリソースのライフサイクル管理を説明する図である。 トラッキング処理を行うアプリケーションを追加したデータ処理システムの構成例を示すブロック図である。 トラッキング処理を行うObjTrackingEASのリソース調整/最適化を含むデータ処理フロー図である。 ワークフローディスクリプションの構造例を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。

以下、添付図面を参照しながら、本技術を実施するための形態（以下、実施の形態という）について説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。説明は以下の順序で行う。
１．データ処理システムの構成例
２．データ処理フロー
３．エッジアプリケーションアーキテクチャによる構成
４．データ処理フロー
５．リソースマネージャによるリソース管理
６．トラッキング処理モジュールの追加構成例
７．まとめ
８．その他のユースケース例
９．コンピュータ構成例

＜１．データ処理システムの構成例＞
図１は、本技術の一実施の形態であるデータ処理システムの構成例を示すブロック図である。

図１のデータ処理システム１は、クライアントデバイス１１と、ネットワーク１２内に配置されたリソースマネージャ２１、オブジェクト認識アプリケーション２２、および、クラウドセンサアプリケーション２３とで構成される。

データ処理システム１は、クライアントデバイス１１が撮像した画像のデータ（イメージデータ）をネットワーク１２へ転送し、画像内のオブジェクトを認識するオブジェクト認識処理を、ネットワーク１２内で実行するシステムである。

ネットワーク１２には、複数のデータ処理装置と、それらを相互に接続可能とした所定の通信網とが含まれる。所定の通信網には、例えば、LAN（Local Area Network）、WAN（Wide Area Network）、インターネット、所謂4G回線や5G回線等の移動体通信網、IOWN Global Forum, Inc.が提唱するオールフォトニクスネットワークなどが挙げられる。データ処理装置は、例えば、センサデバイス、ルータ、モデム、ハブ、ブリッジ、スイッチングハブ、基地局制御装置、交換機、サーバ装置などで構成され、所定の通信網に接続するネットワーク接続機能と、ネットワークを介して取得したデータを処理するデータ処理機能とを有する。

リソースマネージャ２１、オブジェクト認識アプリケーション２２、および、クラウドセンサアプリケーション２３は、ネットワーク１２内の所定のデータ処理装置上で実行されるアプリケーション（モジュール）である。ネットワーク１２は、イメージデータをネットワーク１２へ注入するクライアントデバイス１１に近いエッジ環境（エッジ側クラウド）と、コアネットワーク側のクラウド（センター側クラウド）とを含む。オブジェクト認識アプリケーション２２は、所定の遅延要件を満たしてオブジェクト認識処理を実行する必要があるため、典型的にはエッジ環境で実行される。

クライアントデバイス１１は、DVS３１と、フレームベースドセンサ（FrameBasedSensor）３２とを含んで構成される。ただし、DVS３１は必須ではなく、省略される場合もある。以下では、クライアントデバイス１１がDVS３１を実装している場合と、DVS３１を実装していない場合の２通りについて説明する。DVS３１とフレームベースドセンサ３２の撮像範囲は同一に調整されている。

DVS３１は、光信号を光電変換して画素信号を出力する画素を有し、画素信号に基づき、光信号の時間的輝度変化をイベントデータとして出力するイベントセンサである。一般的なイメージセンサは、垂直同期信号に同期して撮影を行い、その垂直同期信号の周期でフレーム（画面）単位の画像データであるイメージデータを出力するが、DVS３１は、イベントが発生したタイミングにおいてのみイベントデータを出力するため、非同期型またはアドレス制御型のイメージセンサであるということができる。DVSは、Event Based Sensorなどとも呼ばれる。

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

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

式（１）において、ｘ，ｙは、輝度変化が発生した画素の座標を表す。イベントの時刻tは、イベントが発生したときの時刻を表すタイムスタンプであり、例えば、センサ内の所定のクロック信号に基づくカウンタのカウント値で表される。イベントが発生したタイミングに対応するタイムスタンプは、イベントどうしの間隔がイベントの発生時のまま維持されている限り、イベントが発生した（相対的な）時刻を表す時刻情報であるということができる。

極性pは、所定の閾値ｃを超える輝度変化（光量変化）がイベントとして発生した場合の輝度変化の方向を表し、輝度変化がプラス方向の変化（以下、ポジティブともいう。）か、または、マイナス方向の変化（以下、ネガティブともいう。）かを表す。イベントの極性pは、例えば、ポジティブのとき“＋１”で表され、ネガティブのとき“－１”で表される。

以上のように、DVS３１は、輝度変化を検出した画素の位置座標、極性、および、時間情報のみを出力する。DVS３１は、位置座標、極性、および、時間情報という正味の変化（差分）のみ生成して出力するため、データの情報量に冗長度がなく、μsecオーダの高時間分解能を有する。また、情報量が少ないため、フレーム単位のイメージデータを出力するイメージセンサよりも低消費電力であり、データを処理する場合にも、無駄な処理負荷がなく、処理時間を短縮できる。高速、低遅延なデータ出力が可能であるため、イベントの起こった正確な時刻を取得することができる。

フレームベースドセンサ３２は、上述した一般的なイメージセンサに相当し、垂直同期信号に同期して撮影を行い、その垂直同期信号の周期で動画像のイメージデータをフレーム単位で生成するセンサである。フレームベースドセンサ３２は、フレーム単位の画像データを生成するイメージセンサであれば、その種類は問わず、例えば、RGB光を受光してRGB画像を生成するイメージセンサや、IR光を受光してIR画像を生成するイメージセンサなどで構成することができる。以下では、簡単のため、フレームベースドセンサ３２をFBS３２と記述して説明する。

FBS３２は、撮像して得られた動画像のイメージデータを、複数フレームにまたがって圧縮を行うLongGOP圧縮方式によりエンコード（圧縮符号化）する。LongGOP圧縮方式のエンコーダには、例えば、MPEG-4 AVC、H.264などがある。エンコードされた動画像ストリームであるエンコードイメージストリームは、クライアントデバイス１１からオブジェクト認識アプリケーション２２へ転送される。

FBS３２は、GOP(Group Of Picture)を構成するIフレーム、Pフレーム、およびBフレームのうちのIフレームの生成を検知し、Iフレームが転送されるタイミングを示すIフレーム転送タイミング通知をリソースマネージャ２１へ送信する。Iフレームは一定周期で強制的に生成することも可能であるが、本実施の形態では、FBS３２のエンコーダが、シーンチェンジ検知パラメータに基づいて、動画像にシーンチェンジが検出された場合にIフレームを生成する。したがって、FBS３２は、動画像のシーンチェンジによるIフレーム生成にともなって、Iフレーム転送タイミング通知をリソースマネージャ２１へ送信する。

クライアントデバイス１１にDVS３１が実装されている場合、DVS３１は、上述したようにフレームベースのイメージデータでは検出できない時間粒度で輝度変化を観測できるため、FBS３２のイメージデータよりも早く、シーンチェンジに対応する撮像範囲内への物体（オブジェクト）の進入を検出することができる。DVS３１は、イベントデータに基づいて、撮像範囲内へ新たな物体の進入が検出された場合、物体の候補領域確定情報をリソースマネージャ２１へ送信する。物体の候補領域確定情報には、検出された新たな物体に対応して、新たに必要となる候補領域の数と、候補領域それぞれを特定する位置情報とが含まれる。

リソースマネージャ２１は、クライアントデバイス１１から、Iフレーム転送タイミング通知または物体の候補領域確定情報を取得すると、オブジェクト認識アプリケーション２２のリソースをネットワーク１２内に予約（確保）し、オブジェクト認識アプリケーション２２を実行させる。また、リソースマネージャ２１は、オブジェクト認識アプリケーション２２のリソース確保後、クラウドセンサアプリケーション２３から、確保したリソースの解放要求が通知された場合、オブジェクト認識アプリケーション２２のリソースを解放する。

オブジェクト認識アプリケーション２２は、エンコードイメージストリームのトランスポート処理、デコード処理、オブジェクト検出、および、オブジェクト認識処理を行う。トランスポート処理、デコード処理、オブジェクト検出、および、オブジェクト認識処理は、個別の処理モジュールで構成され、独立して起動実行が可能である。トランスポート処理モジュールは、FBS３２からのエンコードイメージストリームを取得する。デコード処理モジュールは、エンコードイメージストリームをデコードする。オブジェクト検出モジュールは、デコードされた動画像のオブジェクトを検出する。オブジェクト認識処理モジュールは、検出されたオブジェクトの分類を行う。各モジュールは、個別のアプリケーションであってもよい。オブジェクト認識アプリケーション２２は、オブジェクト認識処理の認識結果を、クラウドセンサアプリケーション２３へ通知する。

クラウドセンサアプリケーション２３は、オブジェクト認識アプリケーション２２で行われた動画像に対するオブジェクト認識処理の認識結果に基づいて、所定のアプリケーション処理を行う。クラウドセンサアプリケーション２３は、認識結果を用いた所定のアプリケーション処理の実行後、リソースマネージャ２１に対して、リソースの解放要求を通知する。

データ処理システム１は、以上のように、FBS３２で撮像された動画像のオブジェクトを認識するオブジェクト認識処理を、ネットワーク１２上のオブジェクト認識アプリケーション２２で実行する構成とされている。

オブジェクト認識処理は、負荷の高い処理であり、できるだけ不必要な処理が軽減されなければならない。FBS３２からのイメージデータを、常にベースバンドか、もしくはイントラ符号化データで送り、新しいオブジェクトが入ったか否かもわからずに、常時オブジェクト認識処理を稼働するシステムは、リソースが無駄となる。仮に、FBS３２に搭載されるエンコーダが、Iフレーム生成を一定周期で強制的に実行する場合に、Iフレーム生成にともなってオブジェクト認識処理を稼働した場合には、常時オブジェクト認識処理を稼働する場合と比べると、負荷は若干軽減されるものの、まだリソースの無駄が多い。

エッジ環境で稼働されるオブジェクト認識処理の遅延要件は、今後益々厳しくなることが予想される。リソース確保のための事前準備にかかる遅延をなくするため、必要十分なリソースを常時過剰に確保しておけばよいが、常時過剰に確保することによる、リソースの枯渇や、エネルギー消費が大きな問題となる可能性がある。そのため、できるだけ、リソースを必要な時に逐次動的に確保できるような方法が求められる。

データ処理システム１は、FBS３２の撮像範囲に新しいオブジェクト（物体）が入り、シーンチェンジが起こった場合にのみ、エンコードイメージストリームを転送するためのトランスポートリソース、オブジェクト認識処理の実行に必要な計算リソースや記憶リソース、等のリソースを必要十分な量だけ逐次動的に確保する。

図２は、オブジェクト認識処理の典型的な処理の流れを説明する図である。

オブジェクト認識処理は、画像中から物体の位置の特定し、物体のクラス分類を行う処理である。オブジェクト検出および分類処理としては、CNN(Convolutional Neural Network)をベースとする手法が提案されている。代表的な手法であるR-CNN(Regions with Convolutional Neural Networks)では、候補領域確定処理、特徴量抽出処理、および、オブジェクト分類処理が、その順番で実行される。候補領域確定処理は、領域提案部が、オブジェクト（物体）が含まれている可能性のある画像内の領域(候補領域)を検出する処理である。候補領域は、固定サイズの領域に変換される。特徴量抽出処理は、CNN特徴抽出部が、候補領域からCNN特徴量を抽出する処理である。オブジェクト分類処理は、SVM分類部が、抽出された特徴量をもとにオブジェクト分類を行う処理である。候補領域確定処理はオブジェクト検出処理に対応し、特徴量抽出処理およびオブジェクト分類処理がオブジェクト認識処理に対応する。一般に、特徴量抽出処理およびオブジェクト分類処理は、処理遅延を最小限にするために、候補領域ごとに並列に実行される。

オブジェクト認識処理は、以上のように候補領域ごとに並列に実行する必要があることから、新しいIフレームの画像にいくつの物体が新しく出現するかを事前に判定できれば、同時実行しなければならない認識器(推論エンジン)の処理リソースがどれだけ必要かについて正確に見積もれる可能性がある。

図３は、DVS３１とFBS３２が、それぞれ、イメージデータとイベントデータを時系列に生成する様子を示している。

FBS３２は、時刻ｔ１０、ｔ２０、ｔ３０、ｔ４０に、それぞれ、フレーム画像FR1、FR2、FR3、FR4を生成している。時刻ｔ１０、ｔ２０、ｔ３０、ｔ４０の時間間隔は、フレームキャプチャ周期に対応する。

DVS３１は、被写体の動き等に応じて生じた輝度変化を検出したタイミングで、イベントデータを生成している。時間軸上に示される棒線がイベントデータを表し、イベントデータが連続して発生しているタイミングでは、棒線が連結している。

FBS３２のエンコーダは、時刻ｔ１０のフレーム画像FR1をIフレームとしてエンコードする。エンコーダは、時刻ｔ２０のフレーム画像FR2を、時刻ｔ１０のIフレームからの動き補償予測により、Pフレームとしてエンコードする。時刻ｔ３０のフレーム画像FR3は、時刻ｔ１０のIフレームまたは時刻ｔ２０のPフレームからの動き補償予測によりPフレームとしてエンコードされる。時刻ｔ１０のフレーム画像FR1には、物体ａが写っており、時刻ｔ２０のフレーム画像FR2および時刻ｔ３０のフレーム画像FR3では、物体aが移動して写っている。

時刻ｔ４０のフレーム画像FR4には、物体aの他に、物体ｂおよび物体ｃが写っている。FBS３２のエンコーダは、新たな物体ｂおよび物体ｃの撮像範囲内への進入により、フレーム画像FR4においてシーンチェンジが発生したと検出し、Iフレームでエンコードする。すなわち、エンコーダは、フレーム画像FR4をPフレームでエンコードしようとして始めた直前のPフレームからの動き補償予測のブロックマッチング等の演算を中止し、Iフレームとしてエンコードするように切り替える。この検出処理のタイミングは、あくまでも、時刻ｔ４０のフレーム画像FR4がFBS３２内でキャプチャされた時点以降となる。

これに対して、DVS３１が生成するイベントデータに注目すると、イベントデータEVa1は、時刻ｔ１０のフレーム画像FR1に含まれる物体aの撮像範囲内への進入に伴って生成されたイベントデータである。イベントデータEVa2、EVa3、およびEva4それぞれは、物体aの撮像範囲内の移動に伴って生成されたイベントデータである。

時刻ｔ３０から時刻ｔ４０までのフレームキャプチャ周期内の所定の時刻ｔ３４において、物体aと異なる新たな物体ｂおよび物体ｃが撮像範囲内へ進入してきたとする。フレーム画像FR3’は、仮に、FBS３２が時刻ｔ３４に撮像した場合の画像を示している。DVS３１は、時刻ｔ３４に、物体ｂの撮像範囲内への進入に伴うイベントデータEVb1を生成し、物体ｃの撮像範囲内への進入に伴うイベントデータEVc1を生成する。

一般的なイメージデータのネットワーク転送においては、エンコーダが、時刻ｔ４０においてIフレームを検知し、Iフレームとしてのエンコード(フレーム内圧縮等)を行って、そのIフレームのイメージデータをネットワーク１２へ送信する。ネットワーク１２内のオブジェクト認識サーバは、時刻ｔ４０のIフレームを受信、デコードし、認識エンジンの処理(候補領域確定処理、オブジェクト分類処理等)を実行して初めて、新しいオブジェクトがあることを検出する。したがって、オブジェクト認識サーバでは、新しいオブジェクトがいくつ含まれているかについては、候補領域確定処理が行われるまでわからないため、各候補領域内の特徴量抽出ならびにオブジェクト分類処理等の計算リソースを事前に見積もることができない。一般に遅延要件が厳しい場合には、オブジェクト数に比例した同時並列処理が必要となる。

これに対して、データ処理システム１のクライアントデバイス１１は、DVS３１が実装されていない場合、FBS３２のエンコーダでのIフレーム生成を判定する閾値（シーンチェンジ検知の閾値）に基づくIフレーム生成判定結果をトラップし、エンコーダがIフレーム生成を開始する直前に、Iフレーム転送タイミング通知をリソースマネージャ２１へ送信する。リソースマネージャ２１は、オブジェクト認識アプリケーション２２のリソースを早期に確保し、オブジェクト認識アプリケーション２２が、オブジェクトの追加に対応したオブジェクト認識処理を即座に開始できるように準備する。ただし、この場合には、新しいオブジェクトがいくつ含まれるかについては事前にわからないため、オブジェクト毎の特徴量抽出ならびにオブジェクト分類処理等の計算リソースを事前に見積もることはできない。

図４は、図２の時刻ｔ３０から時刻４０までのフレームキャプチャ周期におけるDVS３１の物体検出を説明する図である。

DVS３１は、細かな粒度での時間分解能を持つデータが採れるため、FBS３２のフレームキャプチャ周期よりも、より小さな時間間隔で、オブジェクトの候補領域の時間遷移が判別できる。具体的には、クライアントデバイス１１にDVS３１が実装されている場合、DVS３１は、時刻ｔ３４の時点で、時刻ｔ３０で観測された物体aの移動とは異なる新たな物体ｂおよび物体ｃに対応する候補領域を検出することができる。これにより、前述のFBS３２のみの場合に比べて、必要な特徴量抽出処理からオブジェクト分類処理の計算リソースをより早く確保することが可能となる。すなわち、時刻ｔ３０から時刻４０までの間で、予め、ネットワーク１２のエッジ環境でどれほどのオブジェクト認識処理リソースが必要かを見積もり、確保することができるため、リソース確保処理を安全に、かつ、精度よく行うことができる。ここで、色を併用する高精度な認識処理にはイメージフレームが必要なため、エッジ環境でのオブジェクト認識処理は、FBS３２のシーンチェンジによるIフレームをもとに実行することを前提としており、あくまでもDVS３１は、FBS３２のIフレームの認識に必要なリソースを事前確保するための”併用”扱いとしている。

以上のように、クライアントデバイス１１にDVS３１が実装されている場合、DVS３１は、細かな時間粒度で新たな物体を検出し、事前に必要リソースを確保することができる。換言すれば、Iフレーム生成検知のタイミングで行う場合と比べて、候補領域確定処理を、より早く細かな時間粒度で行うことができる。このイベントデータにもとづく、クライアントデバイス１１における候補領域の判定処理に基づいて、CNN特徴量抽出処理ならびにオブジェクト分類処理を行うことにより、Iフレーム生成検知のみによるオブジェクト認識処理と比べて、より早いオブジェクト認識処理が可能となり、かつ、同時実行されなければならない認識器の処理リソース(数)も正確に見積もることができる。

＜２．データ処理フロー＞
＜DVSを実装していない場合＞
図５を参照して、クライアントデバイス１１がDVS３１を実装していない場合のオブジェクト認識のデータ処理フローを説明する。この処理とは別に、FBS３２による被写体の撮像は、継続的に実行されている。

初めに、ステップＳ１１において、クライアントデバイス１１のFBS３２は、撮像した動画像をLongGOP圧縮方式によりエンコードする。FBS３２は、エンコードの際、シーンチェンジが検出されると、Iフレームの生成を検知し、Iフレーム転送タイミング通知をリソースマネージャ２１へ送信する。

ステップＳ１２において、リソースマネージャ２１は、FBS３２からのIフレーム転送タイミング通知を受信する。リソースマネージャ２１は、トランスポート処理、デコード処理、および、オブジェクト検出に必要なリソースを確保し、オブジェクト認識アプリケーション２２のトランスポート処理モジュール、デコード処理モジュール、および、オブジェクト検出モジュールを実行させる。

ステップＳ１３において、FBS３２は、エンコードイメージストリームを、オブジェクト認識アプリケーション２２のトランスポート処理モジュールへアップリンク（送信）する。

ステップＳ１４において、オブジェクト認識アプリケーション２２は、エンコードイメージストリームの受信からオブジェクト認識までの一連の処理を実行する。具体的には、先に実行されたトランスポート処理モジュール、デコード処理モジュール、および、オブジェクト検出モジュールにより、エンコードイメージストリームの受信、デコード、および、オブジェクト検出が順次行われる。その後、オブジェクト検出の結果に基づいて、オブジェクト認識処理に必要なリソースの確保およびモジュールの実行がリソースマネージャ２１へ要求される。要求に応じて実行されたオブジェクト認識処理モジュールが、オブジェクト認識処理を実行し、その認識結果を、クラウドセンサアプリケーション２３へ通知する。

リソースマネージャ２１は、ステップＳ１５において、オブジェクト認識アプリケーション２２から、オブジェクト認識処理に必要なリソースの確保およびモジュール実行の要求が通知されると、そのリソースを確保してオブジェクト認識処理モジュールモジュールを実行させる。オブジェクト認識処理モジュールは、物体認識の候補領域数だけ並列に実行される。

ステップＳ１６において、クラウドセンサアプリケーション２３は、オブジェクト認識アプリケーション２２から送信されてきたオブジェクト認識処理の認識結果に基づいて、所定のアプリケーション処理を行う。所定のアプリケーション処理の実行後、クラウドセンサアプリケーション２３は、リソースマネージャ２１に対して、リソースの解放要求を通知する。

ステップＳ１７において、リソースマネージャ２１は、クラウドセンサアプリケーション２３からのリソースの解放要求を受信する。リソースマネージャ２１は、オブジェクト認識アプリケーション２２の各モジュールの実行を停止させ、リソースを解放する。トランスポート処理モジュール、デコード処理モジュール、オブジェクト検出モジュール、および、オブジェクト認識処理モジュールそれぞれの実行が停止され、それらのリソースが解放される。

＜DVSを実装している場合＞
次に、図６を参照して、クライアントデバイス１１がDVS３１を実装している場合のオブジェクト認識のデータ処理フローを説明する。この処理とは別に、DVS３１によるイベント検出と、FBS３２による被写体の撮像は、継続的に実行されている。

初めに、ステップＳ３１において、クライアントデバイス１１のDVS３１は、撮像範囲内へ進入してきた新たな物体を検出し、検出された物体の候補領域確定情報をリソースマネージャ２１へ通知する。

ステップＳ３２において、リソースマネージャ２１は、DVS３１からの物体の候補領域確定情報を受信し、候補領域の数に応じたオブジェクト認識処理に必要なリソースを確保し、オブジェクト認識アプリケーション２２のオブジェクト認識処理モジュールを実行させる。

ステップＳ３３において、クライアントデバイス１１のFBS３２は、撮像した動画像をLongGOP圧縮方式によりエンコードする。FBS３２は、エンコードの際、シーンチェンジが検出されると、Iフレームの生成を検知し、Iフレーム転送タイミング通知をリソースマネージャ２１へ送信する。

ステップＳ３４において、リソースマネージャ２１は、FBS３２からのIフレーム転送タイミング通知を受信する。リソースマネージャ２１は、トランスポート処理とデコード処理に必要なリソースを確保し、オブジェクト認識アプリケーション２２のトランスポート処理モジュールとデコード処理モジュールを実行させる。

ステップＳ３５において、FBS３２は、エンコードイメージストリームを、オブジェクト認識アプリケーション２２のトランスポート処理モジュールへアップリンク（送信）する。

ステップＳ３６において、オブジェクト認識アプリケーション２２は、エンコードイメージストリームの受信からオブジェクト認識までの一連の処理を実行する。上述したステップＳ３２の処理により、オブジェクト認識処理に必要なリソースの確保は既に行われている。確保されたリソースにより、オブジェクト認識処理である特徴量抽出処理とオブジェクト分類処理が、物体認識の候補領域数だけ並列に実行される。オブジェクト認識アプリケーション２２は、オブジェクト認識処理の認識結果を、クラウドセンサアプリケーション２３へ通知する。

ステップＳ３７において、クラウドセンサアプリケーション２３は、オブジェクト認識アプリケーション２２から送信されてきたオブジェクト認識処理の認識結果に基づいて、所定のアプリケーション処理を行う。所定のアプリケーション処理の実行後、クラウドセンサアプリケーション２３は、リソースマネージャ２１に対して、リソースの解放要求を通知する。

ステップＳ３８において、リソースマネージャ２１は、クラウドセンサアプリケーション２３からのリソースの解放要求を受信する。リソースマネージャ２１は、オブジェクト認識アプリケーション２２の各モジュールの実行を停止させ、リソースを解放する。トランスポート処理モジュール、デコード処理モジュール、および、オブジェクト認識処理モジュールそれぞれの実行が停止され、それらのリソースが解放される。

DVS３１が実装されていない場合の図５の処理と、DVS３１が実装されている場合の図６の処理とを比較すると、DVS３１が実装されている場合には、ステップＳ３１の処理が追加されている。それにともない、リソースマネージャ２１が各モジュールのリソースを確保、実行する処理が、Iフレーム転送タイミング通知を受信する前のステップＳ３２の処理と、Iフレーム転送タイミング通知を受信した後のステップＳ３４の処理とに分けて実行される。

＜DVS実装有りと無しの比較＞
図７は、オブジェクト認識処理の具体的処理である、候補領域確定処理、特徴量抽出処理、および、オブジェクト分類処理について、図５のDVS３１が実装されていない場合と、図６のDVS３１が実装されている場合とを比較した処理フローである。

図７の上段は、図５に示したDVS３１が実装されていない場合の詳細処理フローである。図７の下段は、図６に示したDVS３１が実装されている場合の詳細処理フローである。

DVS３１が実装されていない場合の処理では、ステップＳ５１において、FBS３２が、エンコードイメージストリームを、オブジェクト認識アプリケーション２２のトランスポート処理モジュールへアップリンク（送信）する。

ステップＳ５２において、オブジェクト認識アプリケーション２２のオブジェクト検出モジュールが、撮像範囲内へ進入してきた新たな物体を検出し、検出された物体の候補領域確定情報をリソースマネージャ２１へ通知する。

ステップＳ５３において、リソースマネージャ２１は、オブジェクト認識アプリケーション２２からの物体の候補領域確定情報を受信し、候補領域の数に応じたオブジェクト認識処理に必要なリソースを確保し、実行させる。これにより、特徴量抽出処理モジュールおよびオブジェクト分類処理モジュールのリソースが候補領域ごとに確保され、候補領域ごとの特徴量抽出処理モジュールおよびオブジェクト分類処理モジュールが実行される。

そして、ステップＳ５４において、特徴量抽出処理モジュールおよびオブジェクト分類処理モジュールが、候補領域ごとに特徴量抽出処理およびオブジェクト分類処理を実行する。オブジェクト分類処理の結果得られた認識結果は、クラウドセンサアプリケーション２３へ通知される。

一方、DVS３１が実装されている場合の処理では、ステップＳ７１において、DVS３１が、撮像範囲内へ進入してきた新たな物体を検出し、検出された物体の候補領域確定情報をリソースマネージャ２１へ通知する。

ステップＳ７２において、リソースマネージャ２１が、DVS３１からの物体の候補領域確定情報を受信し、候補領域の数に応じたオブジェクト認識処理に必要なリソースを確保し、実行させる。特徴量抽出処理モジュールおよびオブジェクト分類処理モジュールのリソースが候補領域ごとに確保され、候補領域ごとの特徴量抽出処理モジュールおよびオブジェクト分類処理モジュールが実行される。

ステップＳ７３において、FBS３２が、エンコードイメージストリームを、オブジェクト認識アプリケーション２２のトランスポート処理モジュールへアップリンク（送信）する。

ステップＳ７４において、特徴量抽出処理モジュールおよびオブジェクト分類処理モジュールが、候補領域ごとに特徴量抽出処理およびオブジェクト分類処理を実行する。オブジェクト分類処理の結果得られた認識結果は、クラウドセンサアプリケーション２３へ通知される。

図７の上段と下段を比較して明らかなように、DVS３１が実装されない場合には、ステップＳ５２としてオブジェクト認識アプリケーション２２で実行される処理が、DVS３１が実装される場合には、ステップＳ７１としてDVS３１で実行される。換言すれば、候補領域確定処理（と同等の処理）を行うオブジェクト検出モジュールのリソースを、ネットワーク１２上に確保する必要がない。また、DVS３１が実装される場合には、候補領域ごとの特徴量抽出処理およびオブジェクト分類処理のリソース確保を、FBS３２からエンコードイメージストリームを受信する前に実行することができるので、リソース確保に余裕を持たせることができ、リソース確保の信頼性を高めることができる。また、エンコードイメージストリームを受信する前に特徴量抽出処理およびオブジェクト分類処理のリソース確保ができるので、全体の処理遅延を低減することができる。

＜３．エッジアプリケーションアーキテクチャによる構成＞
＜データ処理システム＞
図８は、本技術の他の実施の形態であるデータ処理システムの構成例を示すブロック図である。

図８に示されるデータ処理システム１００は、上述したデータ処理システム１を、移動通信の標準化団体である3GPP（Third Generation Partnership Project）-SA6で標準化が行われているエッジアプリケーションのアーキテクチャ（3GPP TS 23.558 “Architecture for enabling Edge Applications (Release 17)”）で実現する場合の構成例である。

このデータ処理システム１００は、ユーザ装置１１１と、ネットワーク（クラウド）１１２内に配置されたリソースマネージャ（ResourceManager）１２１、ObjDetectionEAS１２２、および、クラウドセンサアプリケーション（CloudSensorApplication）１２３とで構成される。

ユーザ装置１１１は、DVS１３１、FBS(FrameBasedSensor)１３２、および、ObjDetectionEAC１３３を有する。なお、上述したデータ処理システム１と同様に、DVS１３１は、省略され得る。

エッジアプリケーションのアーキテクチャでは、EAC（EdgeAppClient）、および、EAS（EdgeAppServer）が定義されており、EASは、ユーザ装置（Use Equipment）のApplication Clientと対で設けられる。EACは、ユーザ装置上で所定のアプリケーションのクライアント機能を実行するアプリケーションであり、EASは、そのアプリケーションのServer機能をEdge環境(Edge Data Network)で実行するアプリケーションである。

ObjDetectionEAC１３３は、エッジアプリケーションアーキテクチャのEACで構成され、ObjDetectionEAS１２２は、エッジアプリケーションアーキテクチャのEASで構成される。リソースマネージャ１２１とクラウドセンサアプリケーション１２３は、本技術の実現のために新たに導入されたエンティティである。リソースマネージャ１２１は、Edge環境で実行するアプリケーションでもよいし、クラウドで実行するアプリケーションであってもよい。

ユーザ装置１１１のDVS１３１は、図１のDVS３１と同様に、FBS１３２と同じ撮像範囲の輝度変化をイベントとして検出し、イベントデータをObjDetectionEAC１３３に出力する。FBS１３２は、図１のFBS３２と同様に、フレームキャプチャ周期で動画像を撮像し、ベースバンドのイメージデータをObjDetectionEAC１３３に出力する。

ObjDetectionEAC１３３は、DVS１３１から供給されるイベントデータに基づいて、撮像範囲内へ進入してきた新たな物体を検出し、検出された物体の候補領域確定情報をリソースマネージャ１２１へ通知する。また、ObjDetectionEAC１３３は、FBS１３２で撮像された動画像をLongGOP圧縮方式によりエンコードし、その結果得られるエンコードイメージストリームをObjDetectionEAS１２２へ送信する。ObjDetectionEAC１３３は、エンコードの際、シーンチェンジにともなうIフレームの生成を検知し、Iフレーム転送タイミング通知をリソースマネージャ１２１へ送信する。

リソースマネージャ１２１は、ObjDetectionEAC１３３からのIフレーム転送タイミング通知に基づいて、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュールのリソース確保および実行を行う。また、リソースマネージャ１２１は、ObjDetectionEAC１３３またはObjDetectionEAS１２２のどちらか一方から通知される物体の候補領域確定情報に基づいて、ObjDetectionEAS１２２の特徴量抽出およびオブジェクト分類処理モジュールのリソース確保および実行を行う。さらに、リソースマネージャ１２１は、クラウドセンサアプリケーション１２３からリソースの解放要求が通知されると、ObjDetectionEAS１２２で実行中のトランスポートおよびデコード処理モジュール、特徴量抽出およびオブジェクト分類処理モジュール等の実行を停止させ、リソースを解放する。

ObjDetectionEAS１２２は、ObjDetectionEAC１３３から送信されてくるエンコードイメージストリームのトランスポート処理、デコード処理、および、オブジェクト認識処理（特徴量抽出処理およびオブジェクト分類処理）を行う。また、ユーザ装置１１１がDVS１３１を実装していない場合は、ObjDetectionEAS１２２は、デコード後のイメージデータに基づいてオブジェクト検出、言い換えれば、物体の候補領域確定処理も実行し、物体の候補領域確定情報を、リソースマネージャ１２１へ通知する。ObjDetectionEAS１２２は、オブジェクト認識処理の認識結果を、クラウドセンサアプリケーション１２３へ通知する。

クラウドセンサアプリケーション１２３は、ObjDetectionEAS１２２で行われた動画像に対するオブジェクト認識処理の認識結果に基づいて、所定のアプリケーション処理を行う。クラウドセンサアプリケーション１２３は、認識結果を用いた所定のアプリケーション処理の実行後、リソースマネージャ１２１に対して、リソースの解放要求を通知する。

＜ユーザ装置＞
図９は、ユーザ装置１１１の詳細構成例を示すブロック図である。

DVS１３１とFBS１３２についての説明は重複するので省略する。ユーザ装置１１１のObjDetectionEAC１３３には、DVS１３１からのイベントデータを処理するDVSデータ処理モジュール１５１と、FBS１３２からのイメージデータを処理するイメージフレームエンコーダモジュール１５２とが実装される。

DVSデータ処理モジュール１５１は、DVS１３１からのイベントデータを解析し、撮像範囲内に進入した新たな物体の候補領域を確定して、エッジ環境またはクラウド上で稼働するリソースマネージャ１２１に対して、物体の候補領域確定情報を通知する。

イメージフレームエンコーダモジュール１５２は、FBS１３２からのベースバンドのイメージデータをエンコードする。その際に、イメージフレームエンコーダモジュール１５２は、例えば、シーンチェンジ検知アルゴリズムによるIフレームの生成判定を行い、Iフレームを生成すると判定した場合には、Iフレームをエンコードする前に、Iフレーム転送タイミング通知をリソースマネージャ１２１へ送信する。また、イメージフレームエンコーダモジュール１５２は、ObjDetectionEAC１３３に対応するサーバ側装置であって、エッジ環境で稼働するObjDetectionEAS１２２に対して、エンコードイメージストリームを送信する。ObjDetectionEAS１２２からエンコードイメージストリームの転送停止が通知された場合には、エンコードイメージストリームの送信は停止される。

図１０は、リソースマネージャ１２１の詳細構成例を示すブロック図である。

リソースマネージャ１２１は、エッジ環境またはクラウド上で稼働し、ObjDetectionEAS１２２の計算および記憶のためのリソースを管理する。リソースマネージャ１２１には、トランスポート及びデコーダリソース管理モジュール１７１と、特徴量抽出及び分類処理リソース管理モジュール１７２とが実装される。なお、図１０では、「トランスポート及びデコーダリソース管理モジュール」を「トランスポート＆デコーダリソース管理モジュール」と記載し、「特徴量抽出及び分類処理リソース管理モジュール」を、「特徴量抽出＆分類処理リソース管理モジュール」と記載しており、「及び」が「＆」で表記されている。図１１以降についても同様の表記がある。

トランスポート及びデコーダリソース管理モジュール１７１は、ObjDetectionEAC１３３からのIフレーム転送タイミング通知を受信し、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１（図１１）のリソース確保および実行を行う。トランスポートおよびデコード処理モジュール１９１のリソースは、ObjDetectionEAC１３３からのエンコードイメージストリームのIフレームが転送されるタイミングに間に合うように確保される。また、トランスポート及びデコーダリソース管理モジュール１７１は、ユーザ装置１１１にDVS１３１が実装されていない場合には、ObjDetectionEAS１２２の候補領域確定処理モジュール１９２（図１１）のリソースの確保および実行も行う。

特徴量抽出及び分類処理リソース管理モジュール１７２は、物体の候補領域確定情報を受信する。物体の候補領域確定情報は、ユーザ装置１１１にDVS１３１が実装されている場合にはObjDetectionEAC１３３から通知され、DVS１３１が実装されていない場合にはObjDetectionEAS１２２から通知される。

DVS１３１が実装されている場合には、特徴量抽出及び分類処理リソース管理モジュール１７２は、ObjDetectionEAC１３３から通知された物体の候補領域確定情報に基づいて、特徴量抽出およびオブジェクト分類処理モジュール１９３（図１１）のリソース確保および実行を行う。また、特徴量抽出及び分類処理リソース管理モジュール１７２は、通知された物体の候補領域確定情報を、ObjDetectionEAS１２２へ転送する。

一方、DVS１３１が実装されていない場合には、特徴量抽出及び分類処理リソース管理モジュール１７２は、ObjDetectionEAS１２２からの物体の候補領域確定情報に基づいて、特徴量抽出およびオブジェクト分類処理モジュール１９３（図１１）のリソース確保および実行を行う。特徴量抽出およびオブジェクト分類処理モジュール１９３のリソースは、特徴量抽出処理およびオブジェクト分類処理を候補領域ごとに並列に実行するように確保される。

トランスポート及びデコーダリソース管理モジュール１７１は、クラウドセンサアプリケーション１２３からリソースの解放要求を受信すると、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１の実行を停止し、リソースを解放する。特徴量抽出及び分類処理リソース管理モジュール１７２は、クラウドセンサアプリケーション１２３からリソースの解放要求を受信すると、ObjDetectionEAS１２２の特徴量抽出およびオブジェクト分類処理モジュール１９３の実行を停止し、リソースを解放する。候補領域確定処理モジュール１９２も実行している場合には、特徴量抽出及び分類処理リソース管理モジュール１７２は、候補領域確定処理モジュール１９２の実行も停止し、リソースを解放する。

図１１は、ObjDetectionEAS１２２の詳細構成例を示すブロック図である。

ObjDetectionEAS１２２には、トランスポートおよびデコード処理モジュール１９１、候補領域確定処理モジュール１９２、および、特徴量抽出およびオブジェクト分類処理モジュール１９３が実装される。ObjDetectionEAS１２２の各モジュールは、上述したように、リソースマネージャ１２１によって実行が開始されたり、停止される。ObjDetectionEAS１２２は、エッジ環境で稼働する。

トランスポートおよびデコード処理モジュール１９１は、ObjDetectionEAC１３３からのエンコードイメージストリームを受信し、デコードする。デコードにより得られたベースバンドのイメージデータは、特徴量抽出およびオブジェクト分類処理モジュール１９３に供給され、DVS１３１が実装されていない場合には候補領域確定処理モジュール１９２にも供給される。トランスポートおよびデコード処理モジュール１９１は、自身の実行を停止する場合には、エンコードイメージストリームの転送停止を、ユーザ装置１１１のObjDetectionEAC１３３へ通知する。

候補領域確定処理モジュール１９２は、ユーザ装置１１１にDVS１３１が実装されていない場合にのみ起動実行され、DVS１３１が実装されている場合には起動実行されない。

候補領域確定処理モジュール１９２は、トランスポートおよびデコード処理モジュール１９１から供給されるベースバンドのイメージデータを用いて候補領域確定処理を行う。すなわち、候補領域確定処理モジュール１９２は、撮像画像内の新たな物体を検出し、検出された物体の候補領域確定情報を、特徴量抽出およびオブジェクト分類処理モジュール１９３へ通知する。物体の候補領域確定情報は、リソースマネージャ１２１の特徴量抽出及び分類処理リソース管理モジュール１７２にも通知される。

特徴量抽出およびオブジェクト分類処理モジュール１９３には、ユーザ装置１１１にDVS１３１が実装されていない場合には、候補領域確定処理モジュール１９２から、物体の候補領域確定情報が供給される。一方、DVS１３１が実装されている場合には、リソースマネージャ１２１の特徴量抽出及び分類処理リソース管理モジュール１７２から、物体の候補領域確定情報が供給される。

特徴量抽出およびオブジェクト分類処理モジュール１９３は、トランスポートおよびデコード処理モジュール１９１からのベースバンドのイメージデータと、特徴量抽出およびオブジェクト分類処理モジュール１９３またはリソースマネージャ１２１からの物体の候補領域確定情報とに基づいて、特徴量抽出処理およびオブジェクト分類処理を候補領域ごとに並列に実行する。特徴量抽出およびオブジェクト分類処理モジュール１９３は、オブジェクト分類処理の結果、すなわち、オブジェクト認識処理の認識結果を、クラウドセンサアプリケーション１２３へ通知する。

＜４．データ処理フロー＞
＜DVSを実装している場合＞
次に、図１２を参照して、ユーザ装置１１１がDVS３１を実装している場合のオブジェクト認識のデータ処理フローを説明する。この処理とは別に、DVS１３１によるイベント検出と、FBS１３２による被写体の撮像は、継続的に実行されている。

初めに、ステップＳ１０１において、DVSデータ処理モジュール１５１は、DVS１３１から供給されるイベントデータを解析し、撮像範囲内の物体を検出する。DVSデータ処理モジュール１５１は、物体の候補領域を確定して、物体の候補領域確定情報をリソースマネージャ１２１へ通知する。

ステップＳ１０２において、特徴量抽出及び分類処理リソース管理モジュール１７２は、物体の候補領域確定情報を受信し、その候補領域確定情報に基づいて特徴量抽出およびオブジェクト分類処理モジュール１９３のリソース確保および実行を行う。特徴量抽出およびオブジェクト分類処理モジュール１９３は、候補領域の数に応じて確保、実行される。続いてステップＳ１０３において、特徴量抽出及び分類処理リソース管理モジュール１７２は、DVSデータ処理モジュール１５１から通知された物体の候補領域確定情報を、ObjDetectionEAS１２２の特徴量抽出およびオブジェクト分類処理モジュール１９３へ通知（転送）する。

ステップＳ１０４において、イメージフレームエンコーダモジュール１５２は、FBS１３２から供給されるベースバンドのイメージデータをエンコードする。その際、イメージフレームエンコーダモジュール１５２は、シーンチェンジ検知アルゴリズムによるIフレームの生成判定を行う。イメージフレームエンコーダモジュール１５２は、Iフレームを生成すると判定した場合、Iフレームをエンコードする前に、Iフレーム転送タイミング通知を、リソースマネージャ１２１のトランスポート及びデコーダリソース管理モジュール１７１へ送信する。

ステップＳ１０５において、トランスポート及びデコーダリソース管理モジュール１７１は、イメージフレームエンコーダモジュール１５２からのIフレーム転送タイミング通知を受信し、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１のリソース確保および実行を行う。トランスポートおよびデコード処理モジュール１９１のリソースは、次のステップＳ１０６においてイメージフレームエンコーダモジュール１５２からエンコードイメージストリームのIフレームが転送される前に確保される。

ステップＳ１０６において、イメージフレームエンコーダモジュール１５２は、撮像したベースバンドのイメージデータをエンコードしたエンコードイメージストリームを、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１へアップリンク（送信）する。

ステップＳ１０７において、トランスポートおよびデコード処理モジュール１９１は、エンコードイメージストリームのトランスポート処理およびデコードを行う。これにより、イメージフレームエンコーダモジュール１５２から送信されてきたエンコードイメージストリームが受信、デコードされ、ベースバンドのイメージデータに変換される。ベースバンドのイメージデータは、特徴量抽出およびオブジェクト分類処理モジュール１９３へ供給される。

ステップＳ１０８において、特徴量抽出およびオブジェクト分類処理モジュール１９３は、トランスポートおよびデコード処理モジュール１９１からのベースバンドのイメージデータと、特徴量抽出及び分類処理リソース管理モジュール１７２からの物体の候補領域確定情報とに基づいて、特徴量抽出処理およびオブジェクト分類処理を候補領域ごとに並列に実行する。特徴量抽出およびオブジェクト分類処理モジュール１９３は、オブジェクト分類処理結果、すなわち、オブジェクト認識結果を、クラウドセンサアプリケーション１２３へ通知する。

ステップＳ１０９において、クラウドセンサアプリケーション１２３は、特徴量抽出およびオブジェクト分類処理モジュール１９３からのオブジェクト認識処理の認識結果に基づいて、所定のアプリケーション処理を行う。クラウドセンサアプリケーション１２３は、所定のアプリケーション処理の実行後、リソースマネージャ１２１に対して、リソースの解放要求を通知する。

ステップＳ１１０において、リソースマネージャ１２１は、クラウドセンサアプリケーション１２３からのリソース解放要求を受信し、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１と特徴量抽出およびオブジェクト分類処理モジュール１９３のリソースを解放する。より具体的には、トランスポート及びデコーダリソース管理モジュール１７１が、トランスポートおよびデコード処理モジュール１９１の実行を停止し、リソースを解放する。特徴量抽出及び分類処理リソース管理モジュール１７２が、特徴量抽出およびオブジェクト分類処理モジュール１９３の実行を停止し、リソースを解放する。

ステップＳ１１１において、トランスポートおよびデコード処理モジュール１９１は、自身の実行を停止する前に、イメージフレームエンコーダモジュール１５２に対して、エンコードイメージストリームの転送停止を通知する。

ユーザ装置１１１がDVS３１を実装している場合のオブジェクト認識のデータ処理は、以上のように実行される。

＜DVSを実装していない場合＞
次に、図１３を参照して、ユーザ装置１１１がDVS３１を実装していない場合のオブジェクト認識のデータ処理フローを説明する。この処理とは別に、FBS１３２による被写体の撮像は、継続的に実行されている。

初めに、ステップＳ１３１において、イメージフレームエンコーダモジュール１５２は、FBS１３２から供給されるベースバンドのイメージデータをエンコードする。その際、イメージフレームエンコーダモジュール１５２は、シーンチェンジ検知アルゴリズムによるIフレームの生成判定を行う。イメージフレームエンコーダモジュール１５２は、Iフレームを生成すると判定した場合、Iフレームをエンコードする前に、Iフレーム転送タイミング通知を、リソースマネージャ１２１のトランスポート及びデコーダリソース管理モジュール１７１へ送信する。

ステップＳ１３２において、トランスポート及びデコーダリソース管理モジュール１７１は、イメージフレームエンコーダモジュール１５２からのIフレーム転送タイミング通知を受信し、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１のリソース確保および実行を行う。トランスポートおよびデコード処理モジュール１９１のリソースは、後述するステップＳ１３４においてイメージフレームエンコーダモジュール１５２からエンコードイメージストリームのIフレームが転送される前に確保される。

ステップＳ１３３において、トランスポート及びデコーダリソース管理モジュール１７１は、候補領域確定処理モジュール１９２のリソース確保および実行を行う。

ステップＳ１３４において、イメージフレームエンコーダモジュール１５２は、撮像したベースバンドのイメージデータをエンコードしたエンコードイメージストリームを、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１へアップリンク（送信）する。

ステップＳ１３５において、トランスポートおよびデコード処理モジュール１９１は、エンコードイメージストリームのトランスポート処理およびデコードを行う。これにより、イメージフレームエンコーダモジュール１５２から送信されてきたエンコードイメージストリームが受信、デコードされ、ベースバンドのイメージデータに変換される。ベースバンドのイメージデータは、候補領域確定処理モジュール１９２と、特徴量抽出およびオブジェクト分類処理モジュール１９３へ供給される。

ステップＳ１３６において、候補領域確定処理モジュール１９２は、トランスポートおよびデコード処理モジュール１９１から供給されたベースバンドのイメージデータを用いて候補領域確定処理を行う。すなわち、候補領域確定処理モジュール１９２は、撮像画像内の物体を検出し、検出された物体の候補領域確定情報を、特徴量抽出およびオブジェクト分類処理モジュール１９３へ通知する。物体の候補領域確定情報は、リソースマネージャ１２１の特徴量抽出及び分類処理リソース管理モジュール１７２にも通知される。

ステップＳ１３７において、特徴量抽出及び分類処理リソース管理モジュール１７２は、候補領域確定処理モジュール１９２からの物体の候補領域確定情報に基づいて、特徴量抽出およびオブジェクト分類処理モジュール１９３のリソース確保および実行を行う。

ステップＳ１３８において、特徴量抽出およびオブジェクト分類処理モジュール１９３は、トランスポートおよびデコード処理モジュール１９１からのベースバンドのイメージデータと、候補領域確定処理モジュール１９２からの物体の候補領域確定情報とに基づいて、特徴量抽出処理およびオブジェクト分類処理を候補領域ごとに並列に実行する。特徴量抽出およびオブジェクト分類処理モジュール１９３は、オブジェクト分類処理結果、すなわち、オブジェクト認識結果を、クラウドセンサアプリケーション１２３へ通知する。

ステップＳ１３９において、クラウドセンサアプリケーション１２３は、特徴量抽出およびオブジェクト分類処理モジュール１９３からのオブジェクト認識処理の認識結果に基づいて、所定のアプリケーション処理を行う。クラウドセンサアプリケーション１２３は、所定のアプリケーション処理の実行後、リソースマネージャ１２１に対して、リソースの解放要求を通知する。

ステップＳ１４０において、リソースマネージャ１２１は、クラウドセンサアプリケーション１２３からのリソース解放要求を受信し、ObjDetectionEAS１２２の各モジュールの実行を停止し、リソースを解放する。これにより、トランスポートおよびデコード処理モジュール１９１、候補領域確定処理モジュール１９２、並びに、特徴量抽出およびオブジェクト分類処理モジュール１９３の実行が停止され、リソースが解放される。

ステップＳ１４１において、トランスポートおよびデコード処理モジュール１９１は、自身の実行を停止する前に、イメージフレームエンコーダモジュール１５２に対して、エンコードイメージストリームの転送停止を通知する。

ユーザ装置１１１がDVS３１を実装していない場合のオブジェクト認識のデータ処理は、以上のように実行される。

＜５．リソースマネージャによるリソース管理＞
＜リソース構成例＞
図１４は、リソースマネージャ１２１が管理するリソースの構成例を示す図である。

リソースマネージャ１２１は、ObjDetectionEAS１２２がエッジ環境(Edge Data Network)で稼働するようにアプリケーションリソースを管理する。より具体的には、トランスポートおよびデコード処理モジュール１９１、候補領域確定処理モジュール１９２、および、特徴量抽出およびオブジェクト分類処理モジュール１９３それぞれのリソースが管理される。

トランスポートおよびデコード処理モジュール１９１のリソースには、トランスポート処理とデコード処理の実行に必要なCPUタイムスロットとメモリが含まれる。候補領域確定処理モジュール１９２のリソースには、候補領域確定処理の実行に必要なCPUタイムスロットとメモリが含まれる。特徴量抽出およびオブジェクト分類処理モジュール１９３のリソースには、特徴量抽出処理およびオブジェクト分類処理の実行に必要なCPUタイムスロットとメモリが含まれる。

また、リソースマネージャ１２１は、ObjDetectionEAC１３３とObjDetectionEAS１２２との間でデータを転送するためのネットワーク/トランスポートリソースを管理する。このネットワーク/トランスポートリソースとしては、例えば、5G回線の移動体通信網（以下、5Gネットワークと称する。）をベースとするネットワークや、IOWN Global Forum, Inc.が提唱するオールフォトニクスネットワーク（以下、IOWNネットワークと称する。）をベースとするネットワークなどがある。

＜DVSがない場合のアプリケーションリソースの管理＞
図１５は、ユーザ装置１１１にDVS１３１が実装されていない場合のObjDetectionEAS１２２のアプリケーションリソースのライフサイクル管理を説明する図である。

ObjDetectionEAC１３３が、Iフレーム生成を検知すると、ステップＳ１６１において、Iフレーム転送タイミング通知を、リソースマネージャ１２１のトランスポート及びデコーダリソース管理モジュール１７１へ送信する。

トランスポート及びデコーダリソース管理モジュール１７１は、Iフレーム転送タイミング通知を受信すると、ステップＳ１６２において、トランスポート処理、デコード処理、および、候補領域確定処理のそれぞれに必要なCPUタイムスロットおよびメモリを確保して各モジュールを起動させる。これにより、トランスポート処理モジュール１９１A、デコード処理モジュール１９１B、および候補領域確定処理モジュール１９２が、起動される。図１５では、トランスポートおよびデコード処理モジュール１９１が、トランスポート処理モジュール１９１Aとデコード処理モジュール１９１Bに分けて示されている。

候補領域確定処理モジュール１９２は、ObjDetectionEAC１３３から転送され、デコードされたベースバンドのイメージデータを用いて候補領域確定処理を実行する。候補領域確定処理では、1枚のイメージフレームで候補領域が確定する場合もあれば、複数のイメージフレームのオブジェクトの遷移を利用して候補領域が確定する場合もある。複数のイメージフレームを利用する場合には、複数フレーム分のベースバンドのイメージフレームが生成されるまで待つ必要があるため、処理に遅延が生じる。

ステップＳ１６３において、候補領域確定処理モジュール１９２は、検出された物体の候補領域確定情報を、特徴量抽出及び分類処理リソース管理モジュール１７２へ通知する。

特徴量抽出及び分類処理リソース管理モジュール１７２は、物体の候補領域確定情報を、候補領域確定処理モジュール１９２から受信する。特徴量抽出及び分類処理リソース管理モジュール１７２は、ステップＳ１６４において、特徴量抽出処理及び分類処理を候補領域ごとに実行するのに必要なCPUタイムスロットおよびメモリを確保して、特徴量抽出およびオブジェクト分類処理モジュール１９３を候補領域の数だけ起動させる。

クラウドセンサアプリケーション１２３からリソース解放要求が通知されると、リソースマネージャ１２１は、ObjDetectionEAS１２２の各モジュールの実行を停止し、確保したCPUタイムスロットおよびメモリを解放する。トランスポート処理モジュール１９１Aは、自身の実行を停止する前に、ObjDetectionEAC１３３に対して、エンコードイメージストリームの転送停止を通知する。

＜DVSがある場合のアプリケーションリソースの管理＞
図１６は、ユーザ装置１１１にDVS１３１が実装されている場合のObjDetectionEAS１２２のアプリケーションリソースのライフサイクル管理を説明する図である。

ObjDetectionEAC１３３が、ステップＳ１８１において、撮像範囲内に進入した新たな物体の候補領域を検出して、物体の候補領域確定情報を、リソースマネージャ１２１の特徴量抽出及び分類処理リソース管理モジュール１７２へ通知する。

特徴量抽出及び分類処理リソース管理モジュール１７２は、ステップＳ１８２において、ObjDetectionEAC１３３から通知された物体の候補領域確定情報に基づいて、特徴量抽出およびオブジェクト分類処理モジュール１９３を候補領域ごとに実行するのに必要なCPUタイムスロットおよびメモリを確保して、特徴量抽出およびオブジェクト分類処理モジュール１９３を候補領域の数だけ起動させる。起動後、各特徴量抽出およびオブジェクト分類処理モジュール１９３は、ベースバンドのイメージデータの待機状態となる。

ObjDetectionEAC１３３が、Iフレーム生成を検知すると、ステップＳ１８３において、Iフレーム転送タイミング通知を、リソースマネージャ１２１のトランスポート及びデコーダリソース管理モジュール１７１へ送信する。

トランスポート及びデコーダリソース管理モジュール１７１は、Iフレーム転送タイミング通知を受信すると、ステップＳ１８４において、トランスポート処理およびデコード処理に必要なCPUタイムスロットおよびメモリを確保して各モジュールを起動させる。これにより、トランスポート処理モジュール１９１A、および、デコード処理モジュール１９１Bが、起動される。図１６では、トランスポートおよびデコード処理モジュール１９１が、トランスポート処理モジュール１９１Aとデコード処理モジュール１９１Bに分けて示されている。

ObjDetectionEAC１３３から転送され、デコードされたベースバンドのイメージデータは、待機状態である各特徴量抽出およびオブジェクト分類処理モジュール１９３に供給される。候補領域は特定されているので、１枚のイメージフレームが供給されれば、即座に特徴量抽出処理およびオブジェクト分類処理が実行可能である。

各モジュールの実行停止およびリソースの解放は、DVS１３１がない場合の図１５と同様である。

以上のように、DVS１３１が実装されている場合には、DVS１３１が実装されていない場合と比較して、候補領域の数に応じた特徴量抽出およびオブジェクト分類処理モジュール１９３を予め起動させておき、即座に特徴量抽出処理およびオブジェクト分類処理を実行することができるので、リソースを必要な時に動的に確保しつつ、オブジェクト認識処理を高速に実行することができる。

＜ネットワーク/トランスポートリソースの管理＞
＜5Gネットワークの場合＞
図１７は、5Gネットワークのネットワーク/トランスポートの構成例を示している。

5Gネットワークは、UE、AN(Access Network)、および、コアネットワークで構成される。５Gシステムのコアネットワークでは、サービスベースアーキテクチャが採用されている（3GPP TS.23.501 System architecture for the 5G System (5GS)）。このサービスベースアーキテクチャでは、コアネットワークの機能であるNF(Network Function)を定義し、NFどうしがサービスベースインターフェイスと呼ばれる統一的なインターフェイスを介して接続される。

UE２２１は、ユーザ装置（移動端末）である。UE２２１は、AMF２１１によるモビリティ管理およびSMF２１２によるセッション管理の下、外部のデータネットワーク(ISPやVPNで接続された企業ネットワーク等)にパケット通信(IP、イーサネット等のパケットデータユニット(PDU)の転送による通信)で接続して、サービスを受ける。

AN２２２は、UE２２１とコアネットワークとの間の有線または無線のネットワークである。

AMF２１１は、UE２２１のモビリティ管理、認証、および認可などを行う。また、AMF２１１は、SMF２１２の制御も行う。SMF２１２は、UE２２１のセッション管理を行う。

UPF(User Plane Function)２２３は、ユーザデータの転送を行う。DN (Data Network)２２４は、アプリケーションサーバ等が配置される外部ネットワークである。

UE２２１上のアプリケーションであるObjDetectionEAC１３３と、DV２２４上のアプリケーションであるObjDetectionEAS１２２との間の論理的な接続関係が、PDUセッション２２５と称される。このPDUセッション２２５を形成するのに必要なリソース、例えば、パケットを転送する無線および有線の転送路や、転送プロトコルの処理に必要な計算リソース等が、リソースマネージャ１２１が管理する、ネットワーク/トランスポートリソースに相当する。

図１８は、ネットワーク/トランスポートリソースが5Gネットワークである場合のネットワーク/トランスポートリソースのライフサイクル管理を説明する図である。図１８は、図１５に示したDVS１３１がない場合のアプリケーションリソースのライフサイクル管理と対応している。

ObjDetectionEAC１３３が、Iフレーム生成を検知すると、ステップＳ１６１において、Iフレーム転送タイミング通知が、リソースマネージャ１２１のトランスポート及びデコーダリソース管理モジュール１７１へ送信される。

トランスポート及びデコーダリソース管理モジュール１７１において、Iフレーム転送タイミング通知が受信されると、図１５で説明したように、ステップＳ１６２において、トランスポート処理およびデコード処理に必要なCPUタイムスロットおよびメモリが確保されてモジュールが起動される。このとき同時に、トランスポート及びデコーダリソース管理モジュール１７１は、ステップＳ１６２として、5GシステムAPIを介して、5Gシステムに対して、ObjDetectionEAC１３３からObjDetectionEAS１２２へエンコードイメージストリームを転送するのに必要な、AN２２２とUPF２２３とを介したPDUセッション２２５のリソースを確保する。

リソースマネージャ１２１は、ObjDetectionEAS１２２の各モジュールの実行を停止し、確保したCPUタイムスロットおよびメモリを解放するタイミングで、PDUセッション２２５のリソースも解放する。

＜IOWNネットワークの場合＞
図１９は、IOWNネットワークのネットワーク/トランスポートの構成例を示している。

IOWNネットワークでは、ObjDetectionEAC１３３とObjDetectionEAS１２２との間に形成される仮想パス２３１のトランスポートスタック構成は、図１９のようになると想定される。

トランスポートスタックは、最下層側から、Fiber Layer(1本のファイバ内の空間分割多重(SDM: Space Division Multiplexing)や、モード分割多重(MDM: Mode Division Multiplexing))、WDM Layerの波長分割多重(WDM: Wavelength Division Multiplexing)、TDM Layerの時分割多重(TDM: Time Division Multiplexing)の順で構成され、その上に、上位位層のトランスポートとして、IPパケットレイヤー、もしくは、non-IPレイヤーで構成される。

このスタック上に実現されるセッションは、基本的にコネクションオリエンテッドで確立される。すなわち、コネクションセットアップ時に送信側と受信側の間にGMPLS(Generalized Multi-Protocol Label Switch)により仮想パス２３１が形成される(ネットワークリソースが確保される)。上述したエンコードイメージストリームの転送の場合では、ObjDetectionEAC１３３が送信側、ObjDetectionEAS１２２が受信側となるが、送信側が優先度等配信要件を満足する仮想パス２３１を確保する。仮想パス２３１の確保には、コントロールプレーンでやりとりされるGMPLS用のRSVP(Resource reSerVation Protocol)-TE(Traffic Engineering)拡張等が利用される。この仮想パス２３１を構成するためのリソースが、リソースマネージャ１２１が管理する、ネットワーク/トランスポートリソースに相当する。

図２０は、ネットワーク/トランスポートのリソースがIOWNネットワークである場合のネットワーク/トランスポートリソースのライフサイクル管理を説明する図である。図２０は、図１５に示したDVS１３１がない場合のアプリケーションリソースのライフサイクル管理と対応している。

ObjDetectionEAC１３３が、Iフレーム生成を検知すると、ステップＳ１６１において、Iフレーム転送タイミング通知が、リソースマネージャ１２１のトランスポート及びデコーダリソース管理モジュール１７１へ送信される。

トランスポート及びデコーダリソース管理モジュール１７１において、Iフレーム転送タイミング通知が受信されると、図１５で説明したように、ステップＳ１６２において、トランスポート処理およびデコード処理に必要なCPUタイムスロットおよびメモリが確保されてモジュールが起動される。このとき同時に、トランスポート及びデコーダリソース管理モジュール１７１は、ステップＳ１６２として、IOWNシステムAPIを介して、IOWNシステムに対して、ObjDetectionEAC１３３からObjDetectionEAS１２２へエンコードイメージストリームを転送するのに必要な、AN相当とUPF相当とを介した仮想パス２３１のリソースを確保する。

リソースマネージャ１２１は、ObjDetectionEAS１２２の各モジュールの実行を停止し、確保したCPUタイムスロットおよびメモリを解放するタイミングで、仮想パス２３１のリソースも解放する。

＜６．トラッキング処理モジュールの追加構成例＞
次に、データ処理システム１００のその他の構成例として、ObjDetectionEAS１２２の処理の後に、認識された物体（オブジェクト）のトラッキング処理を行うアプリケーションを追加した構成について説明する。

図２１は、トラッキング処理を行うアプリケーションを追加したデータ処理システム１００の構成例を示すブロック図である。

なお、図２１では、トラッキング処理を行うアプリケーションの説明に必要なデータ処理システム１００の一部のみが示されており、重複する説明は適宜省略する。図２１は、ユーザ装置１１１にDVS１３１が実装されている場合に対応する構成例を示している。

図２１のデータ処理システム１００では、トラッキング処理を行うアプリケーションとしてのObjTrackingEAS２５１が追加されている。また、ワークフローマネージャ２５２とワークフローディスクリプション２５３とが設けられている。

ObjTrackingEAS２５１には、ベースバンドのイメージデータとオブジェクト認識処理結果がObjDetectionEAS１２２から供給される。ObjDetectionEAS１２２のオブジェクト認識処理は、ObjTrackingEAS２５１が行うトラッキング処理の前に行われなければならない。

ObjTrackingEAS２５１は、オブジェクト認識処理で検出されたオブジェクトの軌跡を追跡するトラッキング処理モジュール２７１を有する。トラッキング処理モジュール２７１は、ObjDetectionEAS１２２において認識されたオブジェクトのそれぞれが、全体の画像の中でどのように移動しているか、および、その後どう移動するかを検出し、軌跡の追跡結果をクラウドセンサアプリケーション１２３へ通知する。ObjTrackingEAS２５１は、Edge環境またはクラウド上のいずれかで実行される。

ワークフローマネージャ２５２は、エッジ環境またはクラウド上で稼働し、各処理モジュールのリソースを管理する。ワークフローマネージャ２５２は、上述のリソースマネージャ２１の名称を、MPEG-I-NBMPフレームワーク（ISO 23090-8:2018 Information technology － Coded representation of immersive media－ Part 8: Network Based Media Processing）に合わせて変更したものである。

ワークフローマネージャ２５２は、トラッキング処理リソース管理モジュール２８１と、リソース調整/最適化管理モジュール２８２と、その他の処理リソース管理モジュールを有する。その他の処理リソース管理モジュールには、図１０に示したトランスポート及びデコーダリソース管理モジュール１７１と、特徴量抽出及び分類処理リソース管理モジュール１７２とが含まれる。

トラッキング処理リソース管理モジュール２８１は、トラッキング処理モジュール２７１のリソース確保および実行を行う。また、トラッキング処理リソース管理モジュール２８１は、クラウドセンサアプリケーション１２３からリソースの解放要求を受信すると、トラッキング処理モジュール２７１の実行を停止し、リソースを解放する。

リソース調整/最適化管理モジュール２８２は、各アプリケーションの属性が記述されたワークフローディスクリプション(NBMP-WD)２５３を参照し、各アプリケーション（EAS）の実行場所の調整および最適化を行う。

すなわち、リソース調整/最適化管理モジュール２８２は、ワークフローディスクリプション(NBMP-WD)２５３を解析して、エッジ環境およびクラウドにおけるリソースの負荷状況を把握し、相対的に遅延要件の緩いアプリケーションを他のエッジ環境またはクラウドに移動するか否か、および、移動する場合の移動先の決定を行う。

ObjDetectionEAS１２２が実行されているエッジ環境において、そこで稼働するアプリケーションの負荷が高くなり、エッジ環境のCPUタイムスロットやメモリ等のアプリケーションリソース(ネットワーク/トランスポートリソースも含む)がひっ迫し、そのエッジ環境では、新たなObjTrackingEAS２５１の実行が困難になる場合があり得る。また、ObjTrackingEAS２５１が行うトラッキング処理は、オブジェクト認識処理ほど、処理の遅延要件が厳しくない場合がある。ObjTrackingEAS２５１の処理の遅延要件がObjDetectionEAS１２２に比べて緩いため、周辺のエッジ環境またはクラウド上においてObjTrackingEAS２５１を実行するのに必要なアプリケーションリソースが確保可能であれば、リソース調整/最適化管理モジュール２８２は、他の環境にObjTrackingEAS２５１を移動して実行するように、リソースを調整する。ワークフローディスクリプション(NBMP-WD)２５３には、所定のアプリケーション（処理モジュール）について、”処理の遅延要件がその他のアプリケーションに対して緩い場合には、他のエッジ環境またはクラウドで実行してもよい”というような条件がアプリケーションの属性として記述される。

図２２を参照して、トラッキング処理を行うObjTrackingEAS２５１のリソース調整/最適化を含むデータ処理フローを説明する。

初めに、ステップＳ２０１において、ObjDetectionEAC１３３のDVSデータ処理モジュール１５１は、DVS１３１から供給されるイベントデータを解析し、撮像範囲内の物体を検出する。ObjDetectionEAC１３３は、物体の候補領域を確定して、物体の候補領域確定情報を、ワークフローマネージャ２５２の特徴量抽出及び分類処理リソース管理モジュール１７２およびトラッキング処理リソース管理モジュール２８１へ通知する。

ステップＳ２０２において、特徴量抽出及び分類処理リソース管理モジュール１７２は、物体の候補領域確定情報を受信し、その候補領域確定情報に基づいて、ObjDetectionEAS１２２の候補領域確定処理モジュール１９２のリソース確保および実行を行う。また、トラッキング処理リソース管理モジュール２８１は、物体の候補領域確定情報を受信し、その候補領域確定情報に基づいて、ObjTrackingEAS２５１のトラッキング処理モジュール２７１のリソース確保および実行を行う。

ステップＳ２０３において、ObjDetectionEAC１３３のイメージフレームエンコーダモジュール１５２は、FBS１３２から供給されるベースバンドのイメージデータをエンコードする。その際、イメージフレームエンコーダモジュール１５２は、シーンチェンジ検知アルゴリズムによるIフレームの生成判定を行う。イメージフレームエンコーダモジュール１５２は、Iフレームを生成すると判定した場合、Iフレームをエンコードする前に、Iフレーム転送タイミング通知を、ワークフローマネージャ２５２のトランスポート及びデコーダリソース管理モジュール１７１へ送信する。

ステップＳ２０４において、トランスポート及びデコーダリソース管理モジュール１７１は、イメージフレームエンコーダモジュール１５２からのIフレーム転送タイミング通知を受信し、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１のリソース確保および実行を行う。トランスポートおよびデコード処理モジュール１９１のリソースは、後述するステップＳ２０８においてイメージフレームエンコーダモジュール１５２からエンコードイメージストリームのIフレームが転送される前に確保される。

ステップＳ２０５において、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１またはObjTrackingEAS２５１のトラッキング処理モジュール２７１の一方または両方は、リソース負荷増大のため、リソースの確保および実行ができないことを検知し、リソース調整/最適化管理モジュール２８２へ通知する。

ステップＳ２０６において、ワークフローマネージャ２５２のリソース調整/最適化管理モジュール２８２は、ワークフローディスクリプション２５３を解析し、先に実行しようとしたエッジ環境以外のエッジ環境か、または、クラウドに、遅延要件の緩いObjTrackingEAS２５１を移動するか否かを判定する。ワークフローディスクリプション２５３は、ObjDetectionEAC１３３から与えられる場合もあれば、サービスプロバイダのワークフローディスクリプションを管理するエンティティから与えられる場合もある。

リソース調整/最適化管理モジュール２８２は、ObjTrackingEAS２５１を移動すると判定すると、移動先となる他のエッジ環境またはクラウドを決定し、ObjTrackingEAS２５１の移動命令を、トラッキング処理リソース管理モジュール２８１へ通知する。

トラッキング処理リソース管理モジュール２８１は、ステップＳ２０７において、リソース調整/最適化管理モジュール２８２から、ObjTrackingEAS２５１の移動命令と移動先の環境とを受信する。そして、トラッキング処理リソース管理モジュール２８１は、指定された移動先の環境においてObjTrackingEAS２５１のトラッキング処理モジュール２７１のリソース確保（再確保）および実行を行う。ObjTrackingEAS２５１は、再確保された環境上で実行される。

ステップＳ２０８において、ObjDetectionEAC１３３のイメージフレームエンコーダモジュール１５２は、撮像したベースバンドのイメージデータをエンコードしたエンコードイメージストリームを、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１へアップリンク（送信）する。

ステップＳ２０９において、ObjDetectionEAS１２２のトランスポートおよびデコード処理モジュール１９１は、エンコードイメージストリームのトランスポート処理およびデコードを行う。デコードにより得られた撮像範囲全体のベースバンドのイメージデータがObjTrackingEAS２５１のトラッキング処理モジュール２７１に供給される。

ステップＳ２１０において、ObjDetectionEAS１２２の特徴量抽出およびオブジェクト分類処理モジュール１９３は、ベースバンドのイメージデータと、物体の候補領域確定情報とに基づいて、特徴量抽出処理およびオブジェクト分類処理を候補領域ごとに並列に実行する。特徴量抽出およびオブジェクト分類処理モジュール１９３は、オブジェクト分類処理結果、すなわち、オブジェクト認識結果を、トラッキング処理モジュール２７１およびクラウドセンサアプリケーション１２３へ通知する。

トラッキング処理モジュール２７１は、画像のオブジェクトの軌跡を追跡するトラッキング処理を実行し、軌跡の追跡結果を、クラウドセンサアプリケーション１２３へ通知する。

以上のように、リソース調整/最適化管理モジュール２８２が、ワークフローディスクリプション２５３を参照し、リソースの負荷状況に応じて、遅延要件の緩いアプリケーションを、他のエッジ環境またはクラウドへ移動することにより、リソースを調整および最適化することができる。

図２３は、ワークフローディスクリプション２５３の構造例を示している。

ワークフローディスクリプション２５３には、General Descriptor、Input Descriptor、Output Descriptor、Processing Descriptor、および、Requirements Descriptorが含まれる。このうちのRequirements Descriptorの属性に、“relativeProcessingDelayAcceptable”が導入される。“relativeProcessingDelayAcceptable”は、処理遅延を許容するか否かを、TrueまたはFalseにより指定することができる。

＜７．まとめ＞
データ処理システム１００は、クライアント側の装置であるユーザ装置１１１で取得したイメージデータをネットワーク（クラウド）１１２へ転送し、ネットワーク１１２上でオブジェクト認識処理を実行させる。オブジェクト認識処理の認識結果は、クラウドセンサアプリケーション１２３へ送信され、所定のアプリケーション処理に利用される。

オブジェクト認識処理等は負荷の高い処理であり、できるだけ不必要な処理が軽減されなければならない。ユーザ装置１１１で取得したイメージデータを、エッジ環境およびクラウドを含むネットワーク１１２へ転送し、新しいオブジェクトが入ったか否かもわからずに、常時オブジェクト認識処理を稼働するシステムはリソースが無駄となる。遅延要件の厳しい認識系アプリケーションは、今後、増加していくものと考えられ、リソースの枯渇やエネルギー消費が大きな問題となる可能性がある。そのため、リソースを必要な時に逐次動的に確保できるような方法が求められる。

上述したデータ処理システム１および１００では、動画像のシーンチェンジによるIフレーム生成にともなってオブジェクト認識処理に必要なリソースがネットワーク上のエッジ環境に確保される。換言すれば、シーンチェンジに対応する、新たな物体が検出されるタイミングでリソースが確保され、オブジェクト認識処理が稼働する。これにより、リソースを必要な時に逐次動的に確保することができる。

クライアント側装置が光信号の時間的輝度変化をイベントデータとして出力するDVS（DVS３１またはDVS１３１）を実装している場合には、フレームベースのイメージデータでは検出できない時間粒度で新たな物体を検出することができるので、フレームベースのイメージセンサ（FBS３２またはFBS１３２）のみの場合と比較して、より早くリソースを確保することができる。また、新たな物体の数も検出することができるので、リソース負荷も予測可能で、より適切なリソース準備が可能となる。

＜８．その他のユースケース例＞
本技術は、上述した画像内のオブジェクト認識処理以外の処理にも適用することができる。例えば、本技術は、ボディセンサにおいてリアルタイムに計測される生体情報をもとにした医療・ヘルスケアを行うシステムにも適用することができる。

ボディセンサネットワークは、身体の表面（ウェアラブル）及び体内（インプラント）に配置されたセンサによって作られるセンサネットワークの一種である。最近では、これらセンサ群を携帯ネットワーク、あるいは、院内ネットワーク(ローカルまたはパブリック5Gネットワーク)などを通して、外部のモニタリング/解析系のアプリケーションに接続し、心電図、動脈血酸素飽和度、体温といったリアルタイムに計測される生体情報をもとにした医療・ヘルスケアを行うシステムが急速に広まっている。

例えば、DVSの医療応用として、Event Based Sensorによる微小循環(毛細血管網とその輸入・輸出血管である細動脈，細静脈)の赤血球流量および濃度測定による急性または慢性病を検知する例が紹介されている。今後、FrameBasedSensorまたはEvent Based Sensor等のイメージセンサを利用して、血管内の赤血球の流れのみならず、何か異物(赤血球とは異なる形状または色をもつ物体)を検知して、認識した後、それが危険なものであれば、すぐに処置(滞留させたり、粉砕したりする等)ができるようにする緊急処置システムに、本技術を適用することができる。例えば、通常、一定の太さの血管を流れている赤血球の場合、形状は、ほぼ均一の状態で血管内を移動するだけなので、新しい赤血球が撮像範囲内に入ったとしても、エンコーダのシーンチェンジ検知に引っかからずに、動き予測のブロックマッチングで、あるオブジェクトの”移動”とみなされ、シーンチェンジは発生しない(PフレームやBフレームで処理される)。一方、剥離血栓等の異物が撮像範囲に入った場合には、エンコーダのシーンチェンジとして検出される。その場合、それが赤血球とは異なる”異物”であることをすぐに検知および認識して、その異物の内容に応じた緊急処置のトリガーをかける必要がある。この血管内異物発見のような処理は、頻繁に起こる事象ではないため、イメージセンサのフレームイメージをもとに常に異物認識処理にかけることは多大なリソースの無駄となる。今後、生体情報センサネットワークが各病院内のローカル5Gネットワークの普及とともに、広く展開されるようになると、患者のボディセンサから常時収集される膨大なイメージフレームデータ等を常に認識処理して緊急対応できるよう、ネットワークリソースおよび計算リソースを過剰に確保して運用するとなると、膨大な電力/エネルギーが常に無駄に消費されてしまう。本技術を適用することにより、異物が検知されそうな場合にのみ、必要なリソースをタイミングよく確保し、処理が終わった後は、すぐにリソースを解放することができる。

本技術は、医療センサネットワークのみならず、様々な産業分野にわたり膨大なセンサネットワークが展開していくに従い、データセンタのエネルギー消費問題、クラウド内センサアプリケーションのリソースの効率利用に大きく貢献することができる。

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

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

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

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

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

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

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

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

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

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

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

例えば、上述した実施の形態においては、複数のモジュールで構成されていたアプリケーションが１つのモジュールで構成されたり、さらに多数のモジュールに細分化されてもよい。

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

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

なお、本技術は、以下の構成を取ることができる。
（１）
イメージセンサのIフレーム生成のタイミングにともない、前記イメージセンサから転送されるイメージデータのオブジェクト認識処理に必要なリソースをネットワーク上に確保する管理モジュール
を備えるデータ処理装置。
（２）
前記管理モジュールは、前記イメージデータをエンコードするエンコーダが検出するシーンチェンジによるIフレーム生成のタイミングにともない、前記リソースを確保する
前記（１）に記載のデータ処理装置。
（３）
前記管理モジュールは、確保した前記リソースを用いて、オブジェクト認識処理アプリケーションを実行する
前記（１）または（２）に記載のデータ処理装置。
（４）
前記オブジェクト認識処理は、候補領域確定処理を含み、
前記管理モジュールは、前記候補領域確定処理で検出された候補領域の数に対応する前記リソースを確保する
前記（３）に記載のデータ処理装置。
（５）
前記イメージセンサを有するデバイスには、光信号の時間的輝度変化をイベントデータとして出力するイベントセンサが実装されており、
前記管理モジュールは、前記イベントデータに基づく前記Iフレーム生成に対応する新たな物体を検出したタイミングにともない、前記リソースを確保する
前記（１）ないし（４）のいずれかに記載のデータ処理装置。
（６）
前記管理モジュールは、前記新たな物体の候補領域確定情報を前記イベントセンサから受信したタイミングで、前記リソースを確保する
前記（５）に記載のデータ処理装置。
（７）
前記新たな物体の候補領域確定情報には、前記新たな物体の候補領域の数を含み、
前記管理モジュールは、前記新たな物体の候補領域の数に対応する前記リソースを確保する
前記（６）に記載のデータ処理装置。
（８）
前記管理モジュールは、さらに、前記オブジェクト認識処理で検出された物体を追跡するトラッキング処理に必要なリソースを前記ネットワーク上に確保する
前記（１）ないし（７）のいずれかに記載のデータ処理装置。
（９）
前記管理モジュールは、さらに、リソースの負荷状況と処理の遅延要件に応じて、アプリケーションの実行場所の調整を行う
前記（１）ないし（８）のいずれかに記載のデータ処理装置。
（１０）
前記管理モジュールは、前記リソースの解放要求に基づいて、確保した前記リソースを解放する
前記（１）ないし（９）のいずれかに記載のデータ処理装置。
（１１）
データ処理装置が、
イメージセンサのIフレーム生成のタイミングにともない、前記イメージセンサから転送されるイメージデータのオブジェクト認識処理に必要なリソースをネットワーク上に確保する
データ処理方法。
（１２）
イメージセンサにより生成されたイメージデータをネットワークへ転送するクライアントデバイスと、
前記イメージセンサのIフレーム生成のタイミングにともない、前記イメージデータのオブジェクト認識処理に必要なリソースを前記ネットワーク上に確保する管理モジュールと
を備えるデータ処理システム。
（１３）
前記クライアントデバイスは、光信号の時間的輝度変化をイベントデータとして出力するイベントセンサも備え、
前記管理モジュールは、前記イベントデータに基づいて、前記Iフレーム生成に対応する新たな物体を検出したタイミングにともない、前記リソースを確保する
前記（１２）に記載のデータ処理システム。

１：データ処理システム，１１：クライアントデバイス，１２：ネットワーク，２１：リソースマネージャ，２２：オブジェクト認識アプリケーション，２３：クラウドセンサアプリケーション，３２：フレームベースドセンサ，１００：データ処理システム，１１１：ユーザ装置，１１２：ネットワーク，１２１：リソースマネージャ，１２３：クラウドセンサアプリケーション，１５１：DVSデータ処理モジュール，１５２：イメージフレームエンコーダモジュール，１７１：デコーダリソース管理モジュール，１７２：分類処理リソース管理モジュール，１９１：デコード処理モジュール，１９１A：トランスポート処理モジュール，１９１B：デコード処理モジュール，１９２：候補領域確定処理モジュール，１９３：オブジェクト分類処理モジュール，２２５：PDUセッション，２３１：仮想パス，２５２：ワークフローマネージャ，２５３：ワークフローディスクリプション，２７１：トラッキング処理モジュール，２８１：トラッキング処理リソース管理モジュール，２８２：リソース調整/最適化管理モジュール，３０１：CPU，３０２：ROM，：３０３：RAM，３０６：入力部，３０７：出力部，３０８：記憶部，３０９：通信部，３１０：ドライブ

Claims (13)

1. 少なくともイメージセンサを有するクライアントデバイスとネットワークを介して接続されるデータ処理装置であって、
   前記イメージセンサのIフレーム生成に関する前記クライアントデバイスからの通知にともない、前記クライアントデバイスから転送される前記イメージセンサにより生成された動画像のイメージデータのオブジェクト認識処理に必要なリソースを前記ネットワーク上の所定の装置に確保する管理モジュール
   を備え、
   前記リソースには、前記所定の装置のCPUのタイムスロット及びメモリを少なくとも含む
   データ処理装置。
2. 前記管理モジュールは、前記イメージデータをエンコードするエンコーダがシーンチェンジを検出したタイミングに応じた前記通知にともない、前記リソースを確保する
   請求項１に記載のデータ処理装置。
3. 前記管理モジュールは、確保した前記リソースを用いて、オブジェクト認識処理アプリケーションを実行させる
   請求項１に記載のデータ処理装置。
4. 前記オブジェクト認識処理は、候補領域確定処理を含み、
   前記管理モジュールは、前記候補領域確定処理で検出された候補領域の数に対応する前記リソースを確保する
   請求項３に記載のデータ処理装置。
5. 前記イメージセンサを有する前記クライアントデバイスには、光信号の時間的輝度変化をイベントデータとして出力するイベントセンサが実装されており、
   前記管理モジュールは、前記イベントデータに基づく前記Iフレーム生成に対応する新たな物体を検出したタイミングの前記通知にともない、前記リソースを確保する
   請求項１に記載のデータ処理装置。
6. 前記管理モジュールは、前記通知として前記新たな物体の候補領域確定情報を前記イベントセンサから受信したタイミングで、前記リソースを確保する
   請求項５に記載のデータ処理装置。
7. 前記新たな物体の候補領域確定情報には、前記新たな物体の候補領域の数を含み、
   前記管理モジュールは、前記新たな物体の候補領域の数に対応する前記リソースを確保する
   請求項６に記載のデータ処理装置。
8. 前記管理モジュールは、さらに、前記オブジェクト認識処理で検出された物体を追跡するトラッキング処理に必要なリソースを前記ネットワーク上の所定の装置に確保する
   請求項１に記載のデータ処理装置。
9. 前記管理モジュールは、さらに、前記リソースの負荷状況と処理の遅延要件に応じて、前記オブジェクト認識処理のアプリケーションまたはその他の実行予定のアプリケーションの実行場所の調整を行う
   請求項１に記載のデータ処理装置。
10. 前記管理モジュールは、前記リソースの解放要求に基づいて、確保した前記リソースを解放する
    請求項１に記載のデータ処理装置。
11. 少なくともイメージセンサを有するクライアントデバイスとネットワークを介して接続されるデータ処理装置が、
    前記イメージセンサのIフレーム生成に関する前記クライアントデバイスからの通知にともない、前記クライアントデバイスから転送される前記イメージセンサにより得られた動画像のイメージデータのオブジェクト認識処理に必要なリソースを前記ネットワーク上の所定の装置に確保することを含み、
    前記リソースには、前記所定の装置のCPUのタイムスロット及びメモリを少なくとも含む
    データ処理方法。
12. 少なくともイメージセンサを有し、前記イメージセンサにより生成された動画像のイメージデータをネットワークへ転送するクライアントデバイスと、
    前記イメージセンサのIフレーム生成に関する前記クライアントデバイスからの通知にともない、前記イメージデータのオブジェクト認識処理に必要なリソースを前記ネットワーク上の所定の装置に確保する管理モジュールを備えるデータ処理装置と
    を備え、
    前記リソースには、前記所定の装置のCPUのタイムスロット及びメモリを少なくとも含む
    データ処理システム。
13. 前記クライアントデバイスは、光信号の時間的輝度変化をイベントデータとして出力するイベントセンサも備え、
    前記管理モジュールは、前記イベントデータに基づいて前記Iフレーム生成に対応する新たな物体を検出したタイミングに応じた前記通知にともない、前記リソースを確保する
    請求項１２に記載のデータ処理システム。