(57)【要約】  本発明は、複数のローカル端末と通信可能に接続される集中制御サーバ４が、複数の端末の間でリソースを共有して効率的に使用できる方法を提供する。  集中制御サーバは、現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集する情報収集部４ａと、各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算する決定部４ｂと、前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保するリソース確保部４ｃと、を備える【選択図】  図１８
2019503152.tif 000002
【特許請求の範囲】
【請求項１】
複数のローカル端末に通信可能に接続される制御サーバであって、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集する情報収集手段と、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算する決定手段と、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保するリソース確保手段と、を備える制御サーバ。
【請求項２】
前記複数のローカル端末の場所近傍で開催されるイベントに関するイベント情報を格納するイベントメモリを更に備え、
前記決定手段は、前記イベントメモリに格納されている対応するイベント情報を参照して、前記複数のローカル端末の各ローカル端末において追加すべき又は撤去すべきカメラの数を計算し、追加すべき又は撤去すべきカメラの前記数を、対応する前記ローカル端末に出力する請求項１に記載のサーバ。
【請求項３】
前記決定手段が行なう決定結果に関する情報を格納する決定結果履歴メモリと、
前記決定結果履歴メモリに格納されている決定結果に関する前記情報を解析し、前記複数のローカル端末の各ローカル端末における前記演算リソースを割り当てし直す必要があるかどうかを判断し、割り当てし直しを提案するメッセージを、アップグレードすべきと判断される当該ローカル端末に出力するリソース計画立案手段
とを更に備える請求項１又は２に記載のサーバ。
【請求項４】
制御サーバに通信可能に接続されるローカル端末であって、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当てる重み割り当て手段と、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する解析手段
とを備えるローカル端末。
【請求項５】
前記重み割り当て手段は、
近い将来の作業負荷を、過去の作業負荷パターン及び前記重み値に基づいて推定する作業負荷推定手段
を備える請求項４に記載のローカル端末。
【請求項６】
前記重み割り当て手段は、
少なくとも１つの補助センサを使用して前記場所をセンサし、当該場所における異常を検出する補助センサ手段
を更に備える請求項４又は５に記載のローカル端末。
【請求項７】
前記監視対象の前記場所を追跡する複数のカメラを備え、
前記重み割り当て手段は、前記カメラの数を監視し、前記数の変化を検出するカメラ検出手段
を更に備える請求項４乃至６のいずれか一項に記載のローカル端末。
【請求項８】
請求項１乃至３のいずれか一項に記載の前記制御サーバと、
請求項４乃至６のいずれか一項に記載の複数の前記ローカル端末
とを備え、
前記制御サーバは、前記複数の前記ローカル端末間において、各ローカル端末の前記演算リソースが前記重み値により異なるように割り当てる
分散型監視システム。
【請求項９】
複数のローカル端末に通信可能に接続される制御サーバに用いられる監視方法であって、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集し、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算し、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保する
監視方法。
【請求項１０】
監視プログラムを格納して複数のローカル端末に通信可能に接続される制御サーバがプロセスを実行するようにするためのコンピュータ可読記憶媒体であって、前記プロセスでは、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集し、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算し、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保する
コンピュータ可読記憶媒体。
【請求項１１】
制御サーバに通信可能に接続されるローカル端末に用いられる監視方法であって、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当て、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する
監視方法。
【請求項１２】
制御サーバに通信可能に接続されるローカル端末がプロセスを実行するための監視プログラムを格納するコンピュータ可読記憶媒体であって、前記プロセスでは、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当て、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する
コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視技術、例えば特定の場所を監視する集中制御サーバに関するものである。
【背景技術】
【０００２】
通常の映像監視システムは、映像解析サーバに有線ネットワークまたは無線ネットワークを介して接続される複数の映像カメラから成る。映像カメラは、様々な場所に設置されて、建物、地下鉄駅、空港などのような所定の場所を監視する。映像解析サーバの内部で実行される各種の映像解析ソフトウェアツールは、映像カメラから送出される映像ストリームデータをリアルタイムに解析し、異常な動きを自動的に特定する。このような異常な動きを関係当局に、アラームまたは表示通知により通知して関係当局が適切な措置を採り易くする。記録映像も記憶サーバにその場で格納して、被疑者をイベントが発生した後に追跡し易くして様々な解析を非リアルタイム用途で行なう。
【０００３】
特許文献１は、映像カメラをそれぞれの映像サーバに関連付けるシステム及び方法を開示している。このシステムは、映像カメラを映像サーバに自動的に割り当て、映像サーバが故障した場合、故障サーバに関連する映像カメラを作動中の他の映像サーバに割り当て直す。
【０００４】
特許文献２は、監視サーバが、接続先の監視端末を、これらの端末に接続されるカメラの台数を見張ることにより自動的に管理する技術を開示している。サーバは、各カメラの映像ソース情報の容量を監視して、カメラの増加台数または減少台数をチェックする。
【０００５】
特許文献３は、監視カメラが人物の監視処理及び計数処理を行なう技術を開示している。監視処理及び計数処理の精度は、計数結果に応じて変化する。
【０００６】
特許文献４は、監視装置が、監視対象の被写体に関する監視情報が、現在の状態及びセンサ信号に基づいて取得される場合に詳細度を設定する技術を開示している。監視装置は、複数の状態に応じた異なる解像度を同じセンサ信号に設定する。
【０００７】
更に、特許文献５は、関連する技術を開示している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国特許出願公開第２０１１／１４９０８０号明細書
【特許文献２】特開２００８−１１３３７６号
【特許文献３】特開２００５−３４６２６１号
【特許文献４】特開２００５−６５２３８号
【特許文献５】特開平５（１９９３）−１４３８１９号
【発明の概要】
【発明が解決しようとする課題】
【０００９】
映像解析ソフトウェアツールの性能が向上するにつれて、更に大きな処理能力及び更に多くのリソースが必要になる。このようなツールに対する処理能力及び要求リソースも、時間の経過と共に大きく変化する。しかしながら、特許文献１〜特許文献４に開示されているような、映像カメラに割り当てられる一定容量の映像解析サーバは、このような変化する要求に適合することができず、重要なイベントを特定するのが遅くなってしまう、または重要なイベントを完全に見逃してしまう。特許文献１〜特許文献４では、利用可能なリソースが制限されて少なくなるので、端末が、リソースの使用を、例えば重要ではない画像の解像度を下げることにより調整する必要がある。
【００１０】
しかしながら、制限されるリソースは、非常に混雑する場所を監視する、またはこのような混雑する場所を長時間監視する場合には、最終的に不足する。リソース不足を解消する１つの方法は、より多くのリソースを追加することである。しかしながら、この方法はコストが嵩む。これに加えて、リソースが頻繁に使用される端末と、リソースが頻繁には使用されない端末とがある。条件を全く考慮せずに、頻繁には使用されないリソースを増やしても意味が無い。
【００１１】
本発明は、上記の問題に鑑みなされたものであり、本発明は、複数の端末のリソースを、これら端末の間で共有しながら効率的に使用できる方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記の問題を解決するために、本発明の第１の観点は、複数のローカル端末に通信可能に接続される制御サーバであり、当該制御サーバは、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集する情報収集部と、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集部で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算する決定部と、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保するリソース確保部と、を備える。
【００１３】
本発明の第２の観点は、制御サーバに通信可能に接続されるローカル端末であって、当該ローカル端末は、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当てる重み割り当て部と、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する解析部
とを備える。
【００１４】
本発明の第３の観点に係る分散型監視システムは、
前記制御サーバと、
複数の前記ローカル端末
とを備え、
前記制御サーバは、前記複数の前記ローカル端末間において、各ローカル端末の前記演算リソースが前記重み値により異なるように割り当てる。
【００１５】
本発明の第４の観点は、複数のローカル端末に通信可能に接続される制御サーバに用いられる監視方法であって、当該監視方法は、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集し、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集部で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算し、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保する。
【００１６】
本発明の第５の観点は、監視プログラムを格納して複数のローカル端末に通信可能に接続される制御サーバがプロセスを実行するようにするためのコンピュータ可読記憶媒体であって、前記プロセスでは、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集し、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集部で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算し、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保する。
【００１７】
本発明の第６の観点は、制御サーバに通信可能に接続されるローカル端末に用いられる監視方法であって、当該監視方法は、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当て、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する。
【００１８】
本発明の第７の観点は、制御サーバに通信可能に接続されるローカル端末がプロセスを実行するための監視プログラムを格納するコンピュータ可読記憶媒体であって、前記プロセスでは、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当て、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する。
【発明の効果】
【００１９】
本発明によれば、集中制御サーバのような監視技術において、複数の端末のリソースを、これら端末の間で共有しながら効率的に使用できる方法を提供することができる。
【図面の簡単な説明】
【００２０】
【図１】図１は、本発明の第１の実施形態による分散型監視システムの構成例を示すブロック図である。
【図２】図２は、第１の実施形態による集中制御サーバの構成例を示すブロック図である。
【図３】図３は、第１の実施形態によるローカル端末の構成例を示すブロック図である。
【図４】図４は、第１の実施形態による重み割り当て部の構成要素例を示すブロック図である。
【図５】図５は、重みメモリ内のテーブルの一例を示している。
【図６】図６は、集中制御サーバにより実行されるプロセスの一例を示すフローチャートである。
【図７】図７は、ローカル端末により実行されるプロセスの一例を示すフローチャートである。
【図８】図８は、本発明の第２の実施形態による分散型監視システムの構成例を示すブロック図である。
【図９】図９は、第２の実施形態による集中制御サーバの構成例を示すブロック図である。
【図１０】図１０は、イベントメモリ内のイベント情報テーブルの例を示す図である。
【図１１】図１１は、第２の実施形態によるローカル端末の構成例を示すブロック図である。
【図１２】図１２は、第２の実施形態による重み割り当て部の構成例要素を示すブロック図である。
【図１３】図１３は、集中制御サーバにより実行されるプロセスの一例を示すフローチャートである。
【図１４】図１４は、第２の実施形態によるローカル端末により実行されるプロセスの一例を示すフローチャートである。
【図１５】図１５は、本発明の第３の実施形態による分散型監視システムの構成例を示すブロック図である。
【図１６】図１６は、第３の実施形態による集中制御サーバの構成例を示すブロック図である。
【図１７】図１７は、集中制御サーバにより実行されるプロセスの一例を示すフローチャートである。
【図１８】図１８は、第４の実施形態による集中制御サーバの構成例を示すブロック図である。
【図１９】図１９は、本発明の実施形態による分散型監視システムを実現する情報処理装置の構成例を示すブロック図である。
【００２１】
当業者であれば、これらの図における構成要素は、簡潔性及び明瞭性を期して示されており、必ずしも寸法通りには描かれていないことを理解できるであろう。例えば、集積回路構造を示すこれらの図におけるこれらの構成要素の幾つかの構成要素の寸法は他の構成要素よりも誇張して表現され、本実施形態及び別の実施形態に対する理解を向上させ易くしている。
【発明を実施するための形態】
【００２２】
本発明の各実施形態について、これらの図面を参照しながら以下に説明することとする。以下の詳細な説明は、例示に過ぎず、本発明または本発明の用途及び用法を限定するものではない。更に、本発明は、前出の発明の背景、または以下の詳細な説明において提示される如何なる理論にも拘束されないものとする。
【００２３】
〈第１の実施形態〉
図１は、第１の実施形態による分散型監視システム１００の構成例を示すブロック図である。分散型監視システム１００は、建物、地下鉄駅、空港のようなイベントに関連する様々な場所の所定の現場を監視する。分散型監視システム１００は、ローカル端末３＿１，３＿２，３＿３，．．．，３＿ｎ（以後、「３＿１〜３＿ｎ」と表記する；ｎは、正の整数である）のうち１つ以上のローカル端末における演算に必要とされる演算リソース（computing resource）が少なく制限されている場合でも、監視映像中に重要な状況下にある異常なイベントを短時間のうちに確実に検出する。これを達成するために、分散型監視システム１００は、演算リソースを他のローカル端末３＿１〜３＿ｎから自動的に調達する。
【００２４】
分散型監視システム１００は、集中制御サーバ１及びローカル端末３＿１〜３＿ｎを含む。集中制御サーバ１及びローカル端末３＿１〜３＿ｎの各ローカル端末は、有線ネットワークまたは無線ネットワーク（もしくは、有線ネットワーク及び無線ネットワークの組み合わせ、以後「ネットワーク２」と表記する）を介して通信することができる。ローカル端末３＿１〜３＿ｎは各監視エリアに設置される制御カメラ（図３に示す）を制御し、集中制御サーバ１は、ローカル端末３＿１〜３＿ｎの間での演算リソースの合理的な共有化を容易にする。
【００２５】
例えば地下鉄の駅では、地下鉄の駅内に複数のカメラを固定させて、このカメラ群の各々のカメラが、所定のエリアをそれぞれ監視する。監視映像に対する特定の処理は、当該特定の地下鉄駅で利用可能な演算リソースを使用して行なわれる。ところが、これらの駅エリア付近における状況、例えば、事故、行事、競技によっては、群衆が増える。これらの状況を理解するために、または増加した群衆の中から犯罪者を見つけ出すために、複雑で多大な時間を要する演算を行なう映像解析ソフトウェアが必要になる。この処理要求の増加に伴い、より多くの演算リソースが必要となり、当該地下鉄駅で利用可能な演算リソースは、この要求の増加のために不足する。しかしながら、このような状況は、普通、全ての駅で同時には発生しない。他の駅における演算リソースは未使用のままであり、このリソース利用率は低下する。例えば、駅Ａ（図示せず）のローカル端末３ａは、ある時刻におけるラッシュ時の群衆の出現によって多くのリソースを必要とし、駅Ｂ（図示せず）のローカル端末３ｂは、特別な事が何も起きていないので、リソースが残っている。分散型監視システム１００は、都市または地方の地下鉄駅のこのようなネットワークにおいて使用することができる。ローカル端末３＿１〜３＿ｎの各ローカル端末は、以下に説明する実施形態では、異なる地下鉄駅にそれぞれ設置される。ローカル端末３＿１〜３＿ｎは、このような緊急事態を自律的に検出し、要求の重要度、及び当該要求に必要な演算リソースを重みとして決定し、当該重み（要求）を集中制御サーバ１に通知する。集中制御サーバ１は、ローカル端末３ａのような重要度がより高い地下鉄駅における要求増加を、ローカル端末３ｂのような重要度がより低い地下鉄駅のリソースから切り替えて確保（リザーブ）することで対応する。このように、分散型監視システム１００は、地下鉄駅の１つ以上の地下鉄駅における演算に必要な演算リソースが少なく制限されている場合でも、監視映像中の重要な状況における異常なイベントを短時間のうちに確実に検出する。
【００２６】
（集中制御サーバ）
図２に示すように、集中制御サーバ１は、Ｉ／Ｏインターフェース１１及び制御部１２を含む。制御部１２は、ローカル端末３＿１〜３＿ｎの間のリソース共有を実現し、既存のリソース共有方法が使用される。例えば、米国特許出願公開第ＵＳ１１／１４０，４２９号は、複数のデータセンターが分担する作業負荷の軽減を選択的に行なう技術を開示している。更に詳細には、第２データセンターに分類されるユーザリクエストに関連する作業負荷の一部を軽減してユーザリクエストを処理し、負荷軽減ステップ／操作は、第１データセンター及び第２データセンターの一方のデータセンターに関連する管理ポリシーに基づいて行なわれる。この技術では、ローカル端末３＿１〜３＿ｎは、他のローカル端末の１種のアクセラレータとしても機能する。ローカル端末が、処理量が大量に急激に増える状況に直面してこれらの処理がオーバーフローしそうになる場合、サーバは別のローカル端末をアクセラレータとして指定して、幾つかの処理を引き受けて負荷を軽減する、別の表現をすると、ビジーなローカル端末が、別のローカル端末の演算リソースを利用することができるようにする。負荷軽減の前に、サーバは、２つの端末を一時的なペアとして仮想的にリンクさせる。全ての処理が完了した後、サーバはペアのリンクを解除する。サーバは、ペアのリンクを、予めスケジューリングして管理するだけでなく、事前通知を行なうこともなく管理することができる。
【００２７】
制御部１２は、情報収集部１２ａ、決定部１２ｂ、及びリソース確保部１２ｃを含む。
【００２８】
情報収集部１２ａは、ローカル端末３＿１〜３＿ｎの各々における要求の重要度を示す重み値を取り出し、ローカル端末３＿１〜３＿ｎの各々で利用可能なＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ：中央処理部）及び／又はメモリのような現在の演算リソースに関する情報を収集する。
【００２９】
決定部１２ｂは、ローカル端末３＿１〜３＿ｎの重要度を、重み値に基づいて決定し、要求リソースとローカル端末３＿１〜３＿ｎで利用可能なリソースとの乖離を計算する。決定部１２ｂは、共有している演算リソースを、重要度がより低いローカル端末３＿１〜３＿ｎから、重要度がより高いローカル端末３＿１〜３＿ｎに切り替えて配分する。
【００３０】
リソース確保部１２ｃは、決定部１２ｂの指示に基づいて、追加の演算リソースを、重要度がより低いローカル端末３＿１〜３＿ｎから、重要度がより高いローカル端末３＿１〜３＿ｎに切り替えて確保し、監視映像中の異常なイベントを危機的なローカル端末３＿１〜３＿ｎにおいて短時間のうちに検出する。
【００３１】
Ｉ／Ｏインターフェース１１は、集中制御サーバ１の他の構成部、及びネットワーク２と通信することができる。例えば、Ｉ／Ｏインターフェース１１は、ディスプレイ（図示せず）に接続され、決定部１２ｂにより行なわれる決定を表示する。Ｉ／Ｏインターフェース１１は、情報及びデータを集中制御サーバ１とローカル端末３＿１〜３＿ｎとの間で送受信する。
【００３２】
（ローカル端末）
図３に示すように、ローカル端末３＿１〜３＿ｎは、カメラ３１、ローカルネットワーク３２、重み割り当て部３３、映像記憶装置３４、解析部３５、イベント情報メモリ３６、及びＩ／Ｏインターフェース３７を含む。
【００３３】
カメラ３１は、任意の種類の有線監視カメラまたは無線監視カメラ、固定カメラ、及び／又は携帯カメラとすることができる。カメラ３１は、現場の所定のエリアを十分高い解像度で監視することができる。
【００３４】
ローカルネットワーク３２は、有線ネットワークまたは無線ネットワークであり、当該ネットワークを介して、カメラ３１は、監視映像ストリームを供給して重み割り当て部３３において処理する。
【００３５】
重み割り当て部３３は、監視映像ストリームを、ローカルネットワーク３２を介して受信し、カメラ３１のフレームに表示される人物の人数を監視する。重み割り当て部３３は、ローカル端末の重要度を判定し、重み値をそれに応じて割り当てる。
【００３６】
映像記憶装置３４は、監視映像ストリームを一時的に格納するバッファとして機能する。特定のローカル端末の重要度が、より低い重要度である（重みが小さい）と評価されると、重要度がより高い他のローカル端末に当該特定のローカル端末の演算リソースは使用される。この場合、映像記憶装置３４は、当該映像記憶装置自体が設置されている駅を撮影した監視映像ストリームを自装置内の一部に記憶し、他のローカル端末の重要度に応じて解析部３５に提供することにより、他の駅にあるローカル端末のカメラ３１に表示されるイベントを追跡し損ねることがないようにする。
【００３７】
解析部３５は、すなわち映像解析ソフトウェアツールとしての主構成部は、監視映像ストリームを解析し、ラッシュ時の群衆、火災、及び事故のような監視映像ストリーム中の様々なイベントを検出する。解析部３５は、重み割り当て部３３の他のセンサの出力を使用することができる。解析部３５は、各イベントの重大度に応じてアラームを生成して、当該アラームをＩ／Ｏインターフェース１１に送信する。解析部３５は、イベントをイベント情報メモリ３６に格納する。
【００３８】
イベント情報メモリ３６は、解析部３５により検出されるイベント及び関連アラームを格納することにより、イベント及びアラームを後の時点で参照することができる。イベント情報メモリ３６はまた、イベントが検出される時刻及び場所の特定のフィルム映像を格納する。
【００３９】
Ｉ／Ｏインターフェース３７は、他の構成部及びネットワーク２と通信することができる。例えば、Ｉ／Ｏインターフェース３７は、ディスプレイ（図示せず）に接続され、解析部３５から送信されるアラームを表示する。ディスプレイによりユーザは、イベント情報メモリ３６にアクセスして、格納イベントに関する調査を更に行なうことができる。Ｉ／Ｏインターフェース３７は、情報及びデータを、集中制御サーバ１及び他のローカル端末３＿１〜３＿ｎとの間で送受信する。
【００４０】
図４は、重み割り当て部３３の構成例を示している。重み割り当て部３３は、作業負荷推定部３３ａ、補助センサ部３３ｄ、故障検出部３３ｅを含む。重み割り当て部３３は、重みメモリ３３ｆに通信可能に接続される。
【００４１】
重み割り当て部３３は、作業負荷推定部３３ａ、補助センサ部３３ｄ、及び故障検出部３３ｅの出力を合成し、重み値を計算する。
【００４２】
作業負荷推定部３３ａは、フレーム事前解析部３３ｂ及び作業負荷予測部３３ｃを含む。作業負荷推定部３３ａは、フレーム事前解析部３３ｂ及び作業負荷予測部３３ｃの出力を合成して近い将来の作業負荷を推定する。更に詳細には、作業負荷推定部３３ａは、作業負荷量を、計算に必要なコアの数の観点から推定する。複数のコアは算出のユニットとして捉えられ、如何なる標準サーバ構成も考えられうる。
【００４３】
フレーム事前解析部３３ｂは、カメラ３１から送信されるフレーム中の監視映像ストリームを区分し、次に、これらのフレームに対し事前解析を行なって、フレーム中の人物の大まかな人数を推定する。フレーム事前解析部３３ｂは、閾値を格納するメモリを保持することができ、フレーム中に表示される人物の人数に基づいて仮重み値を決定する。
【００４４】
作業負荷予測部３３ｃは、必要な作業負荷及び当該作業負荷に必要なリソースを、過去の作業負荷パターン及びフレーム事前解析部３３ｂから取得される重み値に基づいて予測する。
【００４５】
補助センサ部３３ｄは、ローカル端末３＿１〜３＿ｎの周りの状況を、煙検出器、温度検出器、及び音声検出器のような他のセンサを使用して監視する。補助センサ部３３ｄは、他のセンサの出力に含まれる異常を検出する。補助センサ部３３ｄは、全てのセンサからのデータを関連付けて状況を正確に明示することができる。補助センサ部３３ｄは、重要度を、例えば｛１．０，１．１，１．２，１．３．．．，２．０｝の範囲で判定する。
【００４６】
故障検出部３３ｅは、映像記憶装置３４、解析部３５、及びイベント情報メモリ３６のような重要な構成要素の故障を監視する。これらの重要な構成要素の故障は、解析部３５における映像解析演算に影響を及ぼし、重要なイベントを見逃してしまう。故障検出部３３ｅは、故障を検出し、リソースのロスを判断し、それに応じて、重み値を重み割り当て部３３において大きくして、より多くのリソースを他のローカル端末３＿１〜３＿ｎから切り替えて確保することにより、故障検出部３３ｅ自体が存在する現場における、重要な構成要素の損失を補償する。故障検出部３３ｅは、検出される故障に基づいて、コアの数の観点から、演算能力の低下を判断する。
【００４７】
重みメモリ３３ｆは、出力される値及び計算された重み値を格納する。
【００４８】
重み値を計算する例について、図５を参照して以下に説明する。重み割り当て部３３は、出力を、更に詳細にはコアの数（Ａと示す）を作業負荷推定部３３ａから取得し、重要度（Ｂと示す）を補助センサ部３３ｄから取得し、故障による故障コアの数（Ｃと示す）を故障検出部３３ｅから取得する。重み割り当て部３３は、重み値（Ｄと示す）を、Ｄ＝Ｂ＊（Ａ＋Ｃ）のような数式を使用することにより計算する。重み割り当て部３３は、出力（Ａ−Ｄ）を重みメモリ３３ｆに格納する。この計算は、１つの例であり、出力値の計算はこの方法に限定されない。重み割り当て部３３は、重み値を重みメモリ３３ｆから集中制御サーバ１に、Ｉ／Ｏインターフェース３７を介してネットワーク２経由で送信する。
【００４９】
（分散型監視システムの操作）
集中制御サーバ１が実行するプロセスについて、図６を参照して詳細に説明する。
【００５０】
まず、ステップＳ１０１では、集中制御サーバ１の情報収集部１２ａが、現在の重み値のような、ローカル端末３＿１〜３＿ｎの現在の実行環境に関する情報を収集する。
【００５１】
ステップＳ１０２では、情報収集部１２ａが、ローカル端末３＿１〜３＿ｎの重み値の変化を、現在の重み値と前の重み値を比較することにより監視する。重み値の変化が検出される場合、情報収集部１２ａは、当該変化を決定部１２ｂに通知する。
【００５２】
ステップＳ１０３では、決定部１２ｂが、現在の要求リソースを、ローカル端末３＿１〜３＿ｎから受信される重み値に基づいて計算する。
【００５３】
ステップＳ１０４では、決定部１２ｂが、現在の要求リソースとローカル端末３＿１〜３＿ｎで利用可能なリソースとの乖離を計算する。乖離は、リソースの不足または余剰を示す。
【００５４】
ステップＳ１０５では、決定部１２ｂが、全てのローカル端末３＿１〜３＿ｎの乖離を降順に並べる。
【００５５】
ステップＳ１０６では、リソース確保部１２ｃが、リソースを、乖離が最小である（リソースの余剰）ローカル端末から乖離が最大である（リソースの不足）ローカル端末に切り替えて確保する。
【００５６】
ステップＳ１０７では、リソース確保部１２ｃが、ローカル端末３＿１〜３＿ｎに対してリソース再配分について通知し、リソースを当該情報に従って、仮想化リソース共有技術を適用することにより再配分する。
【００５７】
次に、ローカル端末３＿１〜３＿ｎが実行するプロセスについて図７を参照して詳細に説明する。
【００５８】
まず、ステップＳ２０１では、フレーム事前解析部３３ｂが、監視映像ストリームの事前解析を行ない、フレーム中の人物の合計人数を計数し、仮重み値を推定する。フレーム事前解析部３３ｂは、メモリ内の閾値を参照し、フレーム中に表示される人物の人数に基づいて仮重み値を決定する。
【００５９】
ステップＳ２０２では、作業負荷予測部３３ｃが、作業負荷解析処理を行ない、近未来作業負荷推定を行なう。推定を行なう場合、作業負荷予測部３３ｃは、必要な作業負荷、及び当該必要な作業負荷に必要なリソースを、過去の作業負荷パターン、及びフレーム事前解析部３３ｂから取得される仮重み値に基づいて予測する。
【００６０】
ステップＳ２０３では、補助センサ部３３ｄが状況を、煙検出器、温度検出器、及び音声検出器のような他のセンサを使用して監視する。補助センサ部３３ｄは、他のセンサの出力に含まれる異常を検出する。詳細には、補助センサ部３３ｄは、全てのセンサからのデータを関連付けて重要度を判断する。
【００６１】
ステップＳ２０４では、故障検出部３３ｅが、解析部３５における解析不良を監視し、不良が今までに検出されている場合には、解析不良により生じるリソースのロスを判断する。
【００６２】
ステップＳ２０５では、重み割り当て部３３が、作業負荷推定部３３ａの出力（コアの数のような作業負荷推定値）、補助センサ部３３ｄの出力（重要度）、及び故障検出部３３ｅの出力（故障による故障コアの数）を合成し、現在の重み値を、上に説明される合成出力に基づいて計算する。重み割り当て部３３は、計算による重み値を集中サーバ１に、Ｉ／Ｏインターフェース３７を介してネットワーク２経由で送信する。
【００６３】
ステップＳ２０６では、解析部３５が、監視映像解析を、解析部が保有する演算リソース、及び集中制御サーバ１により事前に割り当てられる他のローカル端末３＿１〜３＿ｎの演算リソースを使用して行なう。これにより、解析部３５は、余剰演算リソースを利用することができ、解析部３５は、カメラ３１から送信される画像の解像度の低下を回避して状況を解析することができる。
【００６４】
ステップＳ２０７では、解析部３５が、検出イベントをイベント情報メモリ３６に格納し、検出イベントについてのアラートを、Ｉ／Ｏインターフェース３７を介して送信する。アラートは、ディスプレイに表示されて当該アラートをユーザ（作業者）に通知する。
【００６５】
（第１の実施形態の効果）
上に説明したように、第１の実施形態による分散型監視システム１００は、リソースを保有する複数の端末のリソースを、これらの端末同士の間で共有しながら効率的に使用することができる。分散型監視システム１００は、これを、端末のカメラで撮影する画像の解像度を低下させることなく、または余剰リソースを追加することなく実現することができる。分散型監視システム１００は、ローカル端末３＿１〜３＿ｎの１つ以上のローカル端末における演算に必要な演算リソースが少なく制限されている場合でも、監視映像中の異常なイベントの検出を、重要な状況において短時間のうちに確実に行なうことができる。その理由は、重要なイベント、及びリソースに対する新たな要求が検出される場合、分散型監視システム１００が、リソースを、重要度がより低いローカル端末から、重要度がより高いローカル端末に一時的に割り当てし直すからである。
【００６６】
〈第２の実施形態〉
第１の実施形態では、演算リソースの割り当ては、設置ローカル端末の場所（例えば、地下鉄駅）の当該時刻における混雑状態に応じて決定される。しかしながら、混雑状態は、当該場所の近傍で開催されるイベント（例えば、行事、スポーツ競技）によって異なる傾向がある。これらのイベントは、イベントスケジュールを事前に取得することにより予測可能である。第２の実施形態では、演算リソースを、イベントスケジュールを考慮に入れることにより割り当てる分散型監視システム２００について説明する。分散型監視システム２００では、ローカル端末に接続されるカメラの数を、イベントの規模に依存して増やす又は減らすことができる。
【００６７】
更に、カメラの数を、増やす又は減らすことにより、予測不能なラッシュ時の群衆に対処することができる。ローカル端末が群衆を検出する場合、ローカル端末は、検出結果を、例えばアラームをディスプレイに表示することにより通知して、管理者（ユーザ）による警告として認識させる。これにより、管理者は、ローカル端末設置場所に携帯カメラを一時的に設置することができる。
【００６８】
図８は、第２の実施形態による分散型監視システム２００の構成例を示すブロック図である。分散型監視システム２００は、集中制御サーバ１０及びローカル端末３０＿１〜３０＿ｎを含む。
【００６９】
（集中制御サーバ）
図９に示すように、集中制御サーバ１０は、Ｉ／Ｏインターフェース１１、制御部１３、及びイベントメモリ１４を含む。制御部１３は、情報収集部１３ａ、決定部１３ｂ、及びリソース確保部１２ｃを含む。第２の実施形態では、ローカル端末３０＿１〜３０＿ｎが駅にそれぞれ設置されると仮定する。
【００７０】
イベントメモリ１４は、図１０に示すイベント情報テーブル１４ａを格納し、イベント情報テーブル１４ａは、ローカル端末３０＿１〜３０＿ｎの場所（駅）の近傍の様々な場所で発生する様々なイベントの情報を有する。これらのイベントは、例えば、行事、競技、事故現場、建物、旅行先であるが、これに限定されない。イベントメモリ１４は、警察署データベースのような外部データベースと同期させることができ、外部データベースは普通、様々なイベントの群衆人数の推定値を記録する。イベント情報テーブル１４ａは、「Ｓｔａｔｉｏｎ  Ｎｏ．（駅番号）」、「Ｅｖｅｎｔ  ＩＤ（イベントＩＤ）」、「Ｄｕｒａｔｉｏｎ  ｏｆ  ｅｖｅｎｔ（イベント期間）」、及び「Ｃｒｏｗｄ  ｓｉｚｅ  ｅｓｔｉｍａｔｅｓ（群衆人数推定値）」のような記録項目を有する。
【００７１】
「Ｓｔａｔｉｏｎ  Ｎｏ．（駅番号）」は、各駅の場所の識別子を表わしている。
【００７２】
「Ｅｖｅｎｔ  ＩＤ（イベントＩＤ）」は、駅の近傍で発生する各イベントの種類の識別子を表わしている。
【００７３】
「Ｄｕｒａｔｉｏｎ  ｏｆ  ｅｖｅｎｔ（イベント期間）」は、特定のイベントが続く日数を表わしている。
【００７４】
「Ｃｒｏｗｄ  ｓｉｚｅ  ｅｓｔｉｍａｔｅｓ（群衆人数推定値）」は、普通の日と比較した場合の推定増加人数（推定増加率）を表わしている。群衆人数は、時刻によって変化する。従って、推定値は、図１０のＤａｙ１  ｅｓｔｉｍａｔｅｓ  １４ｂ（第１日推定値１４ｂ）に表わされるように、１日の所定時間間隔で表わすことができる、または一方の軸が時刻を示し、他方の軸が群衆人数を示すグラフとして表わすことができる。これらの推定値は、カレンダーエントリーとして表わすことができる。
【００７５】
情報収集部１３ａは、ローカル端末３０＿１〜３０＿ｎの重み値を取り出し、カメラの数、及びローカル端末３０＿１〜３０＿ｎの各ローカル端末で利用可能なＣＰＵ，メモリのような演算リソースに関する現在情報を収集する。
【００７６】
決定部１３ｂは、ローカル端末３０＿１〜３０＿ｎの重要度を、重み値に基づいて決定する。決定部１３ｂは、要求リソースとローカル端末３０＿１〜３０＿ｎの各ローカル端末で利用可能なリソースとの乖離を計算する。決定部１３ｂは、演算リソースを、重要度がより低いローカル端末３０＿１〜３０＿ｎから、重要度がより高いローカル端末３０＿１〜３０＿ｎに切り替えて配分することを提案する。決定部１３ｂは、１日の異なる時刻における群衆人数推定値をイベントメモリ１４のイベント情報テーブル１４ａから取り出し、群衆人数推定値を使用して、カメラ３１を特定のローカル端末３０＿１〜３０＿ｎに追加する、または特定のローカル端末３０＿１〜３０＿ｎから撤去する必要があるかどうかを決定する。
【００７７】
他部の構成は、第１の実施形態において説明されたものと同じである。
【００７８】
（ローカル端末）
図１１に示すように、ローカル端末３０＿１〜３０＿ｎの各ローカル端末は、カメラ３１、ローカルネットワーク３２、重み割り当て部３８、映像記憶装置３４、解析部３５、イベント情報メモリ３６、及びＩ／Ｏインターフェース３７を含む。
【００７９】
カメラ３１は、群衆人数推定値によって異なるが、追加する（例えばカメラ３１ａ）か、または撤去する（例えばカメラ３１ｂ）ことができる。カメラ３１は、駅の壁または天井に一時的に取り付けることができる、もしくは、カメラ３１を取り付けた帽子またはベストを着用する人物、またはカメラ３１を保持するロボットを群衆の中に潜入させることができる。ローカル端末３０＿１〜３０＿ｎが広々とした空間または室外に設置される場合、カメラ３１を載せたドローンを使用することができる。
【００８０】
図１２は、重み割り当て部３８の構成例を示している。重み割り当て部３８は、作業負荷推定部３３ａ、補助センサ部３３ｄ、故障検出部３３ｅ、及びカメラ検出部３８ａを含む。
【００８１】
カメラ検出部３８ａは、ローカル端末３０＿１〜３０＿ｎにおけるカメラ３１の追加／撤去を監視する。カメラ３１の数の増加／減少により、当該特定のローカル端末３０＿１〜３０＿ｎにおける重み値がそれに応じて増加／減少する。カメラ検出部３８ａは、カメラ３１の追加／撤去に関するカメラ情報を重み割り当て部３８に送信する。重み割り当て部３８は、重み値を、カメラ情報を考慮に入れて計算する。
【００８２】
他の構成部は、第１の実施形態において説明されるものと同じである。
（分散型監視システムの操作）
【００８３】
集中制御サーバ１０が実行するプロセスについて、図１３を参照して詳細に説明する。
【００８４】
まず、ステップＳ３０１では、集中制御サーバ１０の情報収集部１３ａが、カメラ３１の数、及びローカル端末３０＿１〜３０＿ｎの各ローカル端末で利用可能なＣＰＵ，メモリのような演算リソースに関する情報を収集する。
【００８５】
ステップＳ３０２では、決定部１３ｂが、ローカル端末３０＿１〜３０＿ｎの各ローカル端末に現在必要なカメラの数を、イベントメモリ１４のイベント情報テーブル１４ａの群衆人数推定値を参照することにより計算する。
【００８６】
ステップＳ３０３では、決定部１３ｂが、カメラ追加／撤去の決定をローカル端末３０＿１〜３０＿ｎにＩ／Ｏインターフェース１１を介してネットワーク２経由で出力する。ローカル端末３０＿１〜３０＿ｎは、カメラ追加／撤去の判断をディスプレイに表示する。これにより、ローカル端末３０＿１〜３０＿ｎのユーザ（作業者）は、表示情報を通知として認識することができ、作業者は、カメラ３１を通知に従って取り付けるか、または撤去する。
【００８７】
ステップＳ３０４〜３０９は、第１の実施形態における図６に示すステップＳ１０２〜Ｓ１０７と同じである。
【００８８】
次に、ローカル端末３０＿１〜３０＿ｎで実行されるプロセスについて図１４を参照して詳細に説明する。
【００８９】
まず、ステップＳ４０１では、カメラ検出部３８ａが、カメラの追加／撤去を監視し、処理要求の変化を推定する。
【００９０】
ステップＳ４０２〜Ｓ４０５は、第１の実施形態における図７に示すステップＳ２０１〜Ｓ２０４と同じである。
【００９１】
ステップＳ４０６では、重み割り当て部３３が、作業負荷推定部３３ａの出力、補助センサ部３３ｄの出力、故障検出部３３ｅの出力、及びカメラ検出部３８ａの出力を合成し、重み値を合成出力に基づいて決定する。
【００９２】
ステップＳ４０７〜Ｓ４０８は、第１の実施形態における図７に示すステップＳ２０６〜Ｓ２０７と同じである。
【００９３】
（第２の実施形態の効果）
上に説明したように、第２の実施形態による分散型監視システム２００は、第１の実施形態の効果の他に、ローカル端末３０＿１〜３０＿ｎのうち１つ以上のローカル端末における演算に必要な演算リソースが少なく制限されている場合でも、異常なイベントを監視映像中に重要な状況において短時間のうちに確実に検出する。その理由は、重要なイベント、及びリソースに対する新たな要求が検出される場合、分散型監視システム２００が、リソースを、重要度がより低いローカル端末から、重要度がより高いローカル端末に一時的に割り当てし直すからである。
【００９４】
更に、分散型監視システム２００は、カメラ３１をローカル端末３０＿１〜３０＿ｎの間で最適に使用するのを容易にするための調整を行なう。これにより、演算コストを低減することができる。分散型監視システム２００は更に、カメラ３１の追加に必要な演算リソースの増加を認識し、演算リソースを異なるローカル端末３０＿１〜３０＿ｎの間で自動的に管理する。
【００９５】
〈第３の実施形態〉
第１及び第２の実施形態では、演算リソースの合計量は一定である。しかしながら、駅のような設置現場を訪れる訪問者の人数に関連して、ビジーなローカル端末と、ビジーではない他のローカル端末とが必ず存在する。このような場合、ビジーなローカル端末と、ビジーではないローカル端末の間の頻繁かつ一時的なリソース使用により、データ伝送効率が低下してしまう。従って、より多くのリソースをビジーなローカル端末に、より少ないリソースをビジーではないローカル端末に永続的に割り当てし直すことが好ましい。この割り当てし直し操作は、所定の時間間隔で行なわれて、リソース使用効率を高める必要がある。第３の実施形態では、永続的な割り当てし直し操作を行なう分散型監視システム３００について説明する。
【００９６】
（集中制御サーバ）
図１５は、第３の実施形態による分散型監視システム３００の構成例を示すブロック図である。分散型監視システム３００は、集中制御サーバ４及びローカル端末３０＿１〜３０＿ｎを含む。
【００９７】
集中制御サーバ４により、最適なリソース計画を容易に立てることができる。幾つかのローカル端末３０＿１〜３０＿ｎにおけるより多くの演算リソースに対する要求が、当該特定のローカル端末３０＿１〜３０＿ｎの密集度及び重要度に応じて他のローカル端末３０＿１〜３０＿ｎよりも急速に増加すると、演算リソースをこれらのローカル端末３０＿１〜３０＿ｎに一時的に割り当てし直す必要が生じる。同様に、ローカル端末３０＿１〜３０＿ｎにおけるカメラ３１の数を増やす要求が生じる。分散型監視システム３００は、最適な決定結果を算出し、ローカル端末３０＿１〜３０＿ｎにおける演算リソース及びカメラ３１の大幅な再配分（または、必要に応じてアップグレード）を提案する。この最適な決定結果により、イベントを監視映像中にリアルタイムに検出することができ、演算を効率的に行なうことができ、演算コストを低減することができる。
【００９８】
図１６に示すように、集中制御サーバ４は、Ｉ／Ｏインターフェース１１、制御部１５、イベントメモリ１４、及び決定結果履歴メモリ１６を含む。制御部１５は、情報収集部１３ａ、決定部１３ｂ、リソース確保部１２ｃ、及びリソース計画立案部１５ａを含む。
【００９９】
決定結果履歴メモリ１６は、第２の実施形態において説明されるような幾つかのローカル端末３０＿１〜３０＿ｎから他のローカル端末３０＿１〜３０＿ｎへのカメラ３１の移動のような決定部１３ｂが行なったリソース再配分についての決定結果を格納する。決定結果履歴メモリ１６は更に、リソースをローカル端末３０＿１〜３０＿ｎの間で共有することに関する決定結果を格納する。
【０１００】
リソース計画立案部１５ａは、決定結果履歴メモリ１６に格納されている決定結果を解析し、ローカル端末３０＿１〜３０＿ｎにおけるＣＰＵ及びメモリのような演算リソースをアップグレードして、演算リソースに対する着実に増加している要求を満たす必要があることを提案し、ローカル端末３０＿１〜３０＿ｎの間のデータ移動を抑制する。リソース計画立案部１５ａは、決定結果履歴メモリ１６を定期的に参照し、ローカル端末３０＿１〜３０＿ｎの間のカメラ３１の移動を解析する。リソース計画立案部１５ａは、固定カメラ３１の数を増やす必要があるローカル端末３０＿１〜３０＿ｎを特定することにより、着実に増加している要求を、これらのローカル端末３０＿１〜３０＿ｎにより満たす。これにより、カメラ３１をローカル端末３０＿１〜３０＿ｎの間で頻繁に入れ替える回数を減らすことができる。リソース増加要求またはリソース減少要求は、カメラの増加数または減少数に関連付けることができる。
【０１０１】
分散型監視システム３００の他の構成部、及びローカル端末３０＿１〜３０＿ｎは、第１の実施形態または第２の実施形態おいて説明されるものと同じである。
（分散型監視システムの操作）
【０１０２】
集中制御サーバ４が実行するプロセスについて、図１７を参照して詳細に説明する。
【０１０３】
ステップＳ５０１及びＳ５０２は、図１３の第２の実施形態におけるステップＳ３０１及びＳ３０２と同じである。
【０１０４】
ステップＳ５０３では、決定部１３ｂが、カメラ追加／撤去の決定結果を、Ｉ／Ｏインターフェース１１を介して出力し、当該決定結果を決定結果履歴メモリ１６に格納する。
【０１０５】
ステップＳ５０４〜５０８は、図１３の第２の実施形態におけるステップＳ３０４〜Ｓ３０８と同じである。
【０１０６】
ステップＳ５０９では、リソース確保部１２ｃが、ローカル端末３０＿１〜３０＿ｎにリソース配分結果を通知し、リソース配分結果の記録を決定結果履歴メモリ１６に格納する。
【０１０７】
ステップＳ５１０では、リソース計画立案部１５ａが、決定結果履歴メモリ１６を定期的に参照し、ローカル端末３０＿１〜３０＿ｎにおけるリソース容量のアップグレードを提案する。更に詳細には、リソース計画立案部１５ａは、決定結果履歴メモリ１６に格納されている決定結果を解析し、解析に基づいて、ローカル端末３０＿１〜３０＿ｎにおけるＣＰＵ及びメモリのような演算リソースをアップグレードまたは再配分して、演算リソースに対する着実に増加している要求を満たす必要があることを提案する。これにより、ローカル端末３０＿１〜３０＿ｎの間で伝送されるデータ量を減らすことができる。
【０１０８】
（第３の実施形態の効果）
上に説明したように、第３の実施形態による分散型監視システム３００により、第１の実施形態の効果の他に、最適なリソース計画を容易に立てることができる。その理由は、リソース計画立案部１５ａが、決定結果履歴メモリ１６に格納されている決定結果を解析し、解析に基づいて、演算リソースをアップグレードする必要があることを提案するからである。
【０１０９】
リソースを最適化することにより、演算効率を高め、演算コストを低減することができる。分散型監視システム３００は、異常なイベントを監視映像中に、最小コストでリアルタイムに確実に検出し、要求リソースの経時的な変化に確実に対処する。
【０１１０】
〈第４の実施形態〉
図１８は、本発明の第４の実施形態による集中制御サーバ４の構成を示している。図１８に示すように、集中制御サーバ４は、情報収集部４ａ、決定部４ｂ、及びリソース確保部４ｃを含む。集中制御サーバ４は、複数のローカル端末に通信可能に接続され、これらのローカル端末は、ローカル端末のリソースをこれらのローカル端末の間で共有する。
【０１１１】
情報収集部４ａは、現在利用可能な演算リソース及び重み値を含む情報を複数のローカル端末から収集し、重み値は、ローカル端末における現在の処理要求を表わす。
【０１１２】
決定部４ｂは、各ローカル端末における要求リソースを、要求リソースの重み値に基づいて計算し、計算による要求リソースと各ローカル端末において情報収集部により収集される現在利用可能な演算リソースとの乖離を計算する。
【０１１３】
リソース確保部４ｃは、余剰演算リソースを、複数のローカル端末の中で乖離が最も小さい別のローカル端末から、複数のローカル端末の中で乖離が最も大きいローカル端末に切り替えて確保する。
【０１１４】
この実施形態は、端末のリソースを割り当てて、リソースを端末の間で効率的に使用することができるようにする。その理由は、リソース確保部４ｃが、余剰演算リソースを、複数のローカル端末の中で乖離が最も小さい別のローカル端末から、複数のローカル端末の中で乖離が最も大きいローカル端末に切り替えて確保するからである。
【０１１５】
（情報処理装置）
図１９は、一例として、情報処理装置９００（コンピュータ）の構成を示しており、情報処理装置９００は、本発明の実施形態に関連する分散型監視システム（及び、組み込みサーバ及びローカル端末）を実現することができる。別の表現をすると、図１９は、上記の実施形態における個々の機能を実行することができるハードウェア環境を表わす図１、図８、図１５におけるようなシステムを実現することができるコンピュータ（情報処理装置）の構成を示している。図１９では、矢印の方向は、一例であり、データまたは信号の流れを限定するものではない。
【０１１６】
図１９に示す情報処理装置９００は、以下の構成要素：
−ＣＰＵ９０１（Central_PROCESSING_Unit：中央処理部）；
−ＲＯＭ９０２（Read_Only_Memory：リードオンリーメモリ）；
−ＲＡＭ９０３（Random_Access_Memory：ランダムアクセスメモリ）；
−ハードディスク９０４（記憶装置）；
−外部装置との通信インターフェース９０５（インターフェース：以後「Ｉ／Ｆ」と表記する）；
−ＣＤ−ＲＯＭ（Compact_Disc_Read_Only_Memory：コンパクトディスクリードオンリーメモリ）のような記憶媒体９０７に格納されているデータの読み出し、及び書き込みを行なうことができるリーダー／ライター９０８；及び
−入力／出力インターフェース９０９を構成要素として含む。
【０１１７】
情報処理装置９００は、これらの構成要素がバス９０６（通信線）を介して接続される構成の汎用コンピュータである。
【０１１８】
上記の実施形態を例として用いて説明される本発明は、図１９に示す情報処理装置９００に、これらの実施形態の説明において参照されるブロック図（図１〜図４、図８〜図９、図１１〜図１２、図１５〜図１６、図１８）またはフローチャート（図６〜図７、図１３〜図１４、図１７）に例示される機能を実行することができるコンピュータプログラムを取り込むことにより実現され、次にコンピュータプログラムを、このようなハードウェアのＣＰＵ９０１に読み込み、コンピュータプログラムを解釈してコンピュータプログラムを実行することにより実現される。装置に供給されるコンピュータプログラムは、読み取り可能かつ書き込み可能な揮発性ストレージメモリ（ＲＡＭ９０３）に格納するか、またはハードディスク９０４のような不揮発性記憶装置に格納することができる。
【０１１９】
更に、上に説明した事例では、汎用手順を次に用いて、コンピュータプログラムをこのようなハードウェアに供給することができる。これらの手順では、例えばコンピュータプログラムを装置に、ＣＤ−ＲＯＭのような様々な記憶媒体９０７のいずれかの記憶媒体を介してインストールする、またはコンピュータプログラムを外部ソースからインターネットのような通信線を介してダウンロードする。これらの事例では、本発明は、このようなコンピュータプログラムを形成するコードにより構成されるものとして捉える、またはコードを格納する記憶媒体９０７により構成されるものとして捉えることができる。
【０１２０】
これらの実施形態についてのこれまでの説明は、当業者が本発明を作製して本発明を使用することができるように行なわれる。また、これらの実施形態に対する様々な変形が、当業者には容易に明らかとなり、本明細書において規定される共通の原理および特定の例は、創造的努力を伴うことなく他の実施形態に適用することができる。したがって、本発明は、本明細書で説明した実施形態に限定されるものではなく、特許請求の範囲及び均等物による限定によって規定される最も広い範囲が与えられる。更に、出願経過において特許請求の範囲が補正されたとしても、発明者の意図は、特許請求の範囲に記載の発明の全ての均等物を維持することであるということに留意されたい。
【符号の説明】
【０１２１】
１：集中制御サーバ
２：ネットワーク
３＿１，３＿２，３＿３，．．．，３＿ｎ：ローカル端末
４：集中制御サーバ
４ａ：情報収集部
４ｂ：決定部
４ｃ：リソース確保部
１０：集中制御サーバ
１１：Ｉ／Ｏインターフェース
１２：制御部
１２ａ：情報収集部
１２ｂ：決定部
１２ｃ：リソース確保部
１３：制御部
１３ａ：情報収集部
１３ｂ：決定部
１４：イベントメモリ
１４ａ：イベント情報テーブル
１５ａ：リソース計画立案部
１６：決定結果履歴メモリ
３１：カメラ
３２：ローカルネットワーク
３３：重み割り当て部
３３ａ：作業負荷推定部
３３ｂ：フレーム事前解析部
３３ｃ：作業負荷予測部
３３ｄ：補助センサ部
３３ｅ：故障検出部
３３ｆ：重みメモリ
３５：解析部
３６：イベント情報メモリ
３７：Ｉ／Ｏインターフェース
３８：重み割り当て部
３８ａ：カメラ検出部
１００：分散型監視システム
２００：分散型監視システム
３００：分散型監視システム
９００：情報処理装置
９０１：ＣＰＵ
９０２：ＲＯＭ
９０３：ＲＡＭ
９０４：ハードディスク
９０５：通信インターフェース
９０６：バス
９０７：記憶媒体
９０８：リーダー／ライター
９０９：入力／出力インターフェース
【図１】
2019503152.tif 000003
【図２】
2019503152.tif 000004
【図３】
2019503152.tif 000005
【図４】
2019503152.tif 000006
【図５】
2019503152.tif 000007
【図６】
2019503152.tif 000008
【図７】
2019503152.tif 000009
【図８】
2019503152.tif 000010
【図９】
2019503152.tif 000011
【図１０】
2019503152.tif 000012
【図１１】
2019503152.tif 000013
【図１２】
2019503152.tif 000014
【図１３】
2019503152.tif 000015
【図１４】
2019503152.tif 000016
【図１５】
2019503152.tif 000017
【図１６】
2019503152.tif 000018
【図１７】
2019503152.tif 000019
【図１８】
2019503152.tif 000020
【図１９】
2019503152.tif 000021
【手続補正書】
【提出日】平成30年7月4日(2018.7.4)
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のローカル端末に通信可能に接続される制御サーバであって、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集する情報収集手段と、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算する決定手段と、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保するリソース確保手段と、を備える制御サーバ。
【請求項２】
前記複数のローカル端末の場所近傍で開催されるイベントに関するイベント情報を格納するイベントメモリを更に備え、
前記決定手段は、前記イベントメモリに格納されている対応するイベント情報を参照して、前記複数のローカル端末の各ローカル端末において追加すべき又は撤去すべきカメラの数を計算し、追加すべき又は撤去すべきカメラの前記数を、対応する前記ローカル端末に出力する請求項１に記載のサーバ。
【請求項３】
前記決定手段が行なう決定結果に関する情報を格納する決定結果履歴メモリと、
前記決定結果履歴メモリに格納されている決定結果に関する前記情報を解析し、前記複数のローカル端末の各ローカル端末における前記演算リソースを割り当てし直す必要があるかどうかを判断し、割り当てし直しを提案するメッセージを、アップグレードすべきと判断される当該ローカル端末に出力するリソース計画立案手段
とを更に備える請求項１又は２に記載のサーバ。
【請求項４】
制御サーバに通信可能に接続されるローカル端末であって、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当てる重み割り当て手段と、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する解析手段
とを備えるローカル端末。
【請求項５】
前記重み割り当て手段は、
近い将来の作業負荷を、過去の作業負荷パターン及び前記重み値に基づいて推定する作業負荷推定手段
を備える請求項４に記載のローカル端末。
【請求項６】
前記重み割り当て手段は、
少なくとも１つの補助センサを使用して前記場所をセンサし、当該場所における異常を検出する補助センサ手段
を更に備える請求項４又は５に記載のローカル端末。
【請求項７】
前記監視対象の前記場所を追跡する複数のカメラを備え、
前記重み割り当て手段は、前記カメラの数を監視し、前記数の変化を検出するカメラ検出手段
を更に備える請求項４乃至６のいずれか一項に記載のローカル端末。
【請求項８】
複数のローカル端末に通信可能に接続される制御サーバに用いられる監視方法であって、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集し、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算し、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保する
監視方法。
【請求項９】
監視プログラムを格納して複数のローカル端末に通信可能に接続される制御サーバがプロセスを実行するようにするためのプログラムであって、前記プロセスでは、
現在利用可能な演算リソース及び前記ローカル端末における現在の処理要求を表わす重み値を含む情報を前記複数のローカル端末から収集し、
各ローカル端末における要求リソースを前記ローカル端末の重み値に基づいて計算し、計算された前記要求リソースと前記情報収集手段で収集された各ローカル端末の前記現在利用可能な演算リソースとの乖離を計算し、
前記複数のローカル端末の中で乖離が最も小さい別のローカル端末の余剰演算リソースを、前記複数のローカル端末の中で乖離が最も大きいローカル端末のために確保する
ことをコンピュータに実現させるプログラム。
【請求項１０】
制御サーバに通信可能に接続されるローカル端末に用いられる監視方法であって、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当て、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する
監視方法。
【請求項１１】
制御サーバに通信可能に接続されるローカル端末がプロセスを実行するための監視プログラムであって、前記プロセスでは、
前記ローカル端末に割り当てられる場所を監視して危機レベルを判断し、当該危機レベルを基に前記ローカル端末の重み値を割り当て、
前記重み値に基づいて割り当てられる演算リソースを用いて監視結果を解析し、前記解析結果に含まれるイベントを検出して前記イベントの重大度に基づいたアラームを生成する
ことをコンピュータに実現させる監視プログラム。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図１９
【補正方法】変更
【補正の内容】
【図１９】
2019503152.tif 000022
【国際調査報告】
2019503152.tif 000023
2019503152.tif 000024