JP7301526B2 - 監視装置、監視方法及びプログラム - Google Patents

Description

本発明は、監視装置、監視方法及びプログラムに関する。

従来、監視カメラを備えた監視装置が知られている。特許文献１には、カメラ毎に異常を検出するセンサを備え、異常を検出したカメラの映像を保存する技術が開示されている。また、特許文献２には、異常の発生に伴いカメラのパン・チルト・ズーム（ＰＴＺ）を制御して、異常発生後の映像を捉える技術が開示されている。

特開２００１－３３９７１４号公報 特開２００６－２５４２７７号公報

監視装置において、異常発生前の映像も保存しておきたいという要望がある。しかしながら、異常発生前の映像を保存するためには、特許文献１の技術においては、監視対象が複数存在する場合には、監視対象の数に応じたカメラが必要になるという問題があった。

本発明はこのような問題点に鑑みなされたもので、より簡易な構成により、異常発生前の映像を録画することを目的とする。

そこで、本発明は、複数の監視対象の監視を行う監視装置であって、監視対象の異常の予兆を検知する予兆検知手段と、予兆が検知された監視対象が複数存在する場合に、予兆が検知された各監視対象の、予兆が検知された時点から異常発生の推定時点までの推定期間に応じて、撮影対象とする監視対象を決定する対象決定手段と、前記対象決定手段により決定された前記監視対象を、他の監視対象に優先して撮影するよう制御する撮影制御手段と、前記撮影制御手段により撮影された映像を格納する格納手段とを有することを特徴とする。

本発明によれば、より簡易な構成により、異常発生前の映像を録画することができる。

監視システムの全体構成図である。 監視装置の機能構成図である。 予兆検知処理を示すフローチャートである。 テーブルのデータ構成例を示す図である。 監視ルール更新処理を示すフローチャートである。 発生状況と稼働状態に対する異常監視の要否を示す図である。 稼働監視処理を示すフローチャートである。 テーブルのデータ構成例を示す図である。 テーブルのデータ構成例を示す図である。 テーブルのデータ構成例を示す図である。 第２の実施形態に係る監視ルール更新処理を示すフローチャートである。 各ロボットの監視時間を示す図である。 テーブルのデータ構成例を示す図である。 テーブルのデータ構成例を示す図である。 第３の実施形態に係る監視ルール更新処理を示すフローチャートである。 第３の実施形態に係る稼働監視処理を示すフローチャートである。 映像保存処理を示すフローチャートである。 異常検知変更処理を示すフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。
（第１の実施形態）
図１は、第１の実施形態に係る監視システムの全体構成図である。監視システムは、監視装置１００と、ＮＷカメラ１１２と、を備えている。監視装置１００とＮＷカメラ１１２は、ネットワーク回線１１１を介して接続する。さらに、ネットワーク回線１１１には、複数のＰＬＣ１１３が接続されている。

監視装置１００は、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）等の情報処理装置によって実現することができる。ＣＰＵ１０１は、監視装置１００の全体を制御するＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔである。ＲＯＭ１０２は、変更を必要としないプログラムやパラメータを格納するＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙである。ＲＡＭ１０３は、外部装置などから供給されるプログラムやデータを一時記憶するＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙである。外部記憶装置１０４は、監視装置１００に固定して設置されたハードディスクやメモリカードなどの記憶装置である。なお、外部記憶装置１０４は、監視装置１００から着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ Ｄｉｓｋ（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含んでもよい。

入力デバイスインターフェイス１０５は、ユーザの操作を受け、データを入力するポインティングデバイスやキーボードなどの入力デバイス１０９とのインターフェイスである。出力デバイスインターフェイス１０６は、監視装置１００の保持するデータや供給されたデータを表示するためのモニタ１１０とのインターフェイスである。通信インターフェイス１０７は、インターネットなどのネットワーク回線１１１に接続するための通信インターフェイスである。システムバス１０８は、１０１～１０７の各ユニットを通信可能に接続する伝送路である。後述する各処理は、ＲＯＭ１０２等のコンピュータ読み取り可能な記憶媒体に格納されたプログラムをＣＰＵ１０１が実行することにより処理として機能する。

ＮＷカメラ１１２は、ＰＴＺ制御が可能な映像を撮影する撮像装置であり、ネットワーク回線１１１を介して監視装置１００に接続されている。ロボット１１４は、生産ラインなどにおいて組立作業等を行う生産装置である。ＮＷカメラ１１２は、ＰＴＺにより、各ロボット１１４に順に画角を合わせることで、各ロボット１１４の映像を順に撮影する。ＰＬＣ１１３は、不図示の生産ラインの装置と接続されており、これら装置とロボット１１４の状態をもとに、ロボット１１４を制御するＰｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒである。ＰＬＣ１１３は、ロボットから得られる電流等の制御信号を、ネットワーク回線１１１を介して監視装置１００に伝達する。

図２は、監視装置１００の機能構成図である。録画制御部２０１は、ＮＷカメラ１１２から得た映像データを、録画ルールに基づいて映像管理部２０２に保存する。録画ルールは録画する期間を定義する。例えば、朝８時から１７時までを録画期間とする録画ルールなどがある。また、終日を録画期間とする録画ルールなどもある。なお、録画ルールは、時刻だけでなく、年月日、曜日等の情報を用いて定義されていてもよい。

映像管理部２０２は、ＮＷカメラ１１２により撮影された映像データを例えば外部記憶装置１０４等の予め定められた記憶領域に保存する。映像管理部２０２は、また予め定められた最大保存容量を超えないようにデータを削除する。具体的には、映像管理部２０２は、保存容量が最大を超えるときに、撮影日時が古いデータを削除して、新しいデータを保存する。

映像管理部２０２は、また、後述の異常検知部２０５により異常を検知したときに、異常発生直前からの映像を残すように制御する。例えば、映像管理部２０２は、異常発生を検知したときに、異常発生の１０分前から異常発生までを記憶領域から削除しないように制御する。また、他の例としては、映像管理部２０２は、異常発生までではなく、異常発生後の映像も残すように制御してもよい。映像を残す時間区間の定義はモニタ１１０や入力デバイス１０９を介して外部から与えられることとしてもよい。つまり、異常発生の何分を残すか、異常発生以後も残すか否か、異常発生後は何分残すかなどの情報が外部から与えられる。なお、保存区間は、これらに限定されるものではない。

また、映像を残すために、映像管理部２０２は、記憶領域から削除されないように制御する以外にも、残したい映像を外部記憶装置１０４に出力してもよい。また、他の例としては、映像管理部２０２は、通信インターフェイス１０７を介して他のコンピュータ装置に該当する区間の映像を送信するなどしてもよい。映像の残し方はこれらに限定されるものではない。

撮影制御部２０３は、監視ルールと、画角定義テーブルと、に基づいて、ＮＷカメラ１１２による撮影を制御する。ここで、監視ルールは、ロボットＩＤと監視時間を対応付けた情報である。画角定義テーブルは、ロボットＩＤと画角とを対応付けた情報である。本実施形態においては、撮影制御部２０３は、巡回監視ルール又は固定監視ルールを参照する。巡回監視ルールは、監視対象の複数のロボット１１４を順に撮影することを規定した条件である。撮影制御部２０３は、巡回監視ルールを参照する場合には、複数のロボット１１４を順に撮影するように制御する。これにより、巡回監視が実現する。一方で、固定監視ルールは、複数のロボット１１４のうち１台のロボット１１４のみを撮影対象として規定した条件である。撮影制御部２０３は、固定監視ルールを参照する場合には、１台のロボット１１４のみを撮影対象として撮影を行うよう制御する。これにより固定監視が実現する。なお、この場合、固定監視の対象になっていないロボット１１４の撮影は行われない。撮影制御部２０３は、後述の予兆検知部２０６の検知結果に応じて、参照する監視ルールを選択し、選択した監視ルールに基づいて、撮影を制御する。

ここで、固定監視ルールを参照する場合の処理について説明する。撮影制御部２０３は、固定監視ルールに定義されたロボットＩＤを選択し、選択したロボットＩＤに対応付けられた画角を画角定義テーブルから読み出す。そして、撮影制御部２０３は、画角定義テーブルから読み出した画角に応じて、ＮＷカメラ１１２の画角を変更した上で画角を固定することで、固定監視ルールに定義されたロボットの撮影を継続して行うよう制御する。

次に、巡回監視ルールを参照する場合の処理について説明する。この場合、撮影制御部２０３は、まず、巡回監視ルールにおいて、１番目のロボットＩＤを選択し、選択したロボットＩＤに対応付けられた画角を画角定義テーブルから読み出す。そして、撮影制御部２０３は、画角定義テーブルから読み出した画角に応じて、ＮＷカメラ１１２の画角を変更し、１番目のロボットの監視時間の間、画角を固定することで、１番目のロボットの撮影を行う。撮影制御部２０３は、監視時間が経過すると、巡回監視ルールにおいて、２番目のロボットＩＤを選択し、選択したロボットＩＤに対応した画角を特定し、特定した画角に応じてＮＷカメラ１１２の画角を変更する。そして、撮影制御部２０３は、２番目のロボットの監視時間の間、２番目のロボットの撮影を行う。このように、撮影制御部２０３は、複数台のロボットの撮影を繰り返す。

なお、撮影制御部２０３は、監視対象のロボットのＩＤと、監視対象の画角と、監視時間と、を紐付ける情報を参照することで、撮影対象を制御すればよく、参照される情報のデータ構成は、実施形態に限定されるものではない。また、撮影制御部２０３は、撮影対象に応じてＰＴＺを制御すればよく、制御対象は画角に限定されるものではない。

稼働状態取得部２０４は、ロボットの稼働状態を取得する。例えば、生産ラインが停止しているときにはロボットの稼働は停止する。また、生産ラインにおけるロボットは前工程の完了待ちにある間は稼働を停止することがある。稼働状態取得部２０４は、これらロボットの停止中か稼働中かの情報を取得する。稼働状態取得部２０４は、具体的には、ＰＬＣ１１３を介してロボット１１４の稼働状態を、ネットワーク回線１１１及び通信インターフェイス１０７を介して取得する。

異常検知部２０５は、ロボットに異常が発生したことを検知する。具体的には、異常検知部２０５は、ＰＬＣ１１３を介して得られるデータに基づいて、ロボットに異常が発生したことを検知する。異常検知部２０５が取得するデータとしては、ロボットの制御失敗等のエラー信号、ロボットのエラー信号、ロボット周辺に取り付けられた振動センサ・熱センサ等の信号等が挙げられる。取得するデータがエラー信号等のカテゴリ値であれば、特定エラーが生じたことで異常を検知できる。また、取得するデータが制御信号や各種センサなどのスカラ値であれば、その値が予め定めた閾値に達することで異常を検知できる。なお、データによる異常検知の方法はこれらに限定されない。また、他の例としては、異常検知部２０５は、他のセンサ信号に基づいてロボットの停止を検知するようにしてもよい。異常検知の方法はこれらに限定されるものではない。

予兆検知部２０６は、ロボット１１４に異常が発生する予兆があるか否かを判断する。予兆検知部２０６は、加えて、予兆を検知した時点から異常が発生すると推定される推定時点までの推定期間（寿命）を予測する。具体的には、予兆検知部２０６は、ロボットのセンシングデータをもとに、正常時のセンシングデータの振る舞いを予め学習しておき、正常時のセンシングデータからの乖離が大きくなり始めたことをもって異常の予兆を検知する。正常状態のモデリングにはＭＴ法などを用いることが考えられる。例えば、予兆検知部２０６は、各ロボットから関節軸のモータ制御電流を取得し、数秒間の電流波形の統計量（平均・分散等）をとることや、電流波形のフーリエ変換等の統計量を取ることにより、特徴量ベクトルを生成する。そして、予兆検知部２０６は、正常時の特徴量ベクトルをもとに正常時の確率分布を学習する。

適用時には、予兆検知部２０６は、正常時の確率分布から、ロボットのセンシングデータから求めた特徴量ベクトルが発生する確率を求める。発生確率の負対数尤度を異常度と定義して、異常度が閾値以上であれば、異常が発生する予兆があると判断できる。閾値は、予兆を検知したい異常事例のデータを集め、異常が発生する１月前などの異常度をもとに設定することが考えられる。これにより閾値を超えた異常度を検知することで、検知から異常発生までの寿命を１月と予測できるようになる。なお、異常度の算出には、ＭＴ法以外を用いてもよく、多層ニューラルネットワークにより、正常時の特徴量ベクトルを復元可能に学習して、復元誤差により異常度を求めてもよい。異常度を求める方法はこれらに限定されない。

また、他の例としては、予兆検知部２０６は、特徴量ベクトルから異常発生までの残時間を求め、残時間が所定以下になったときに、異常の予兆を検知してもよい。具体的には、予兆検知部２０６は、正常状態から異常状態に至るまでのデータをいくつか用意して、各時点の特徴量ベクトルを入力として寿命を重回帰モデルにより求めるように学習する。そして、予兆検知部２０６は、重回帰モデルに特徴ベクトルを入力することで、異常発生までの残時間を求める。以下、異常発生までの時間を寿命と称する。なお、異常予測の方法はこれらに限定されるものではない。

また予兆検知部２０６は、異常の発生状況も求める。異常の種類によって、異常が発生する状況が変わる。例えば、モータなどの駆動部の異常は、稼働中においてのみ発生が予想される。一方で、ブレーキ等の異常は、稼働中と停止中の双方で発生が予想される。そこで異常の種類毎に、前述の方法により予兆を検知するモデルを構成しておく。そして、予兆検知部２０６は、モデル毎に発生状況を定義したテーブルを保持しておく。そして、予兆検知部２０６は、いずれかのモデルにより予兆が検知されたとき、その発生状況をテーブルから求めることにより、異常の発生状況を予測する。

予測される異常の発生状況は、ロボット稼働状態以外の状況を用いて定義してもよい。例えば、生産ラインの合流点などにロボットがあるときに、片方のラインからの部品の取り出しの際に頻発することが分かっている異常の場合がある。合流する２ラインの各々の稼働状態を発生状況として利用して、該当するラインが稼働しているときのみ異常が発生すると定義してもよい。あるいは、いくつかの仕向け製品を混流生産しているときに、特定の仕向け製品の場合にだけに用いる部品の取り出しの際にのみ故障が発生するなどという場合には、いずれの仕向け製品を組み立てているかという情報を発生状況として利用してもよい。発生状況の定義はこれらに限定されない。

なお、複数のモデルによる予兆が同時に検知された場合は、予兆検知部２０６は、結果を統合する。具体的には、予兆検知部２０６は、寿命が短い予測を採用する。これによって、先に発生する異常を優先できる。また、他の例としては、予兆検知部２０６は、複数の検知結果をもとに、寿命値の最小値と発生状況の論理和を用いて検知結果を生成してもよい。これによって、異常予測で求める寿命が正確でない場合も、後述の監視ルール更新処理によって異常の発生の際の映像をもれなく撮影できる。異常予測の結果の統合方法はこれらに限定されない。

図３は、監視装置１００による予兆検知処理を示すフローチャートである。予兆検知処理は、１日に１回等、予め定められた頻度で、予め定められたタイミングにおいて実行される。Ｓ３０１において、予兆検知部２０６は、監視対象のすべてのロボットにおいて、異常の予兆検知を行う。予兆検知部２０６は、いずれかのロボットにおいて異常の予兆が検知された場合には（Ｓ３０１でＹＥＳ）、処理をＳ３０２へ進める。予兆検知部２０６は、いずれのロボットにおいても異常の予兆が検知されなかった場合には（Ｓ３０１でＮＯ）、予兆検知処理を終了する。Ｓ３０２において、予兆検知部２０６は、新たに予兆を検知したロボットを予兆テーブルに登録する。

図４（ａ）は、予兆テーブルの一例を示す図である。予兆テーブルには、ロボットＩＤと、寿命と、算定日と、発生状況と、が対応付けて記憶される。ここで、ロボットＩＤは、ロボットの識別情報である。寿命は、検知された予兆に対して、予兆検知部２０６により推定された値である。算定日は、予兆が検知された日である。発生状況は、対応するロボットにおいて、異常の発生し得る状況である。本実施形態においては、発生状況は、稼働状況で表現され、稼働中、停止中、稼働中又は停止中（稼働・停止中）の３つの値を取り得る。なお、本実施形態においては、監視装置１００は、寿命や算定日については、日単位で管理するものとするが、これに限定されるものではない。例えば、時、分のようにより細かい単位で管理してもよい。

なお、既に予兆テーブルにロボットＩＤが登録済みのロボットにおいて予兆が検知されたとする。この場合には、予兆検知部２０６は、新たな検知結果に応じて、予兆テーブルの登録内容を更新してもよい。また、他の例としては、予兆検知部２０６は、前述の予兆検知部２０６の予測結果の統合方法と同様に、寿命値が短い方を予兆テーブルに残すようにしてもよい。また、他の例としては、予兆検知部２０６は、寿命値の最小値と発生状況の論理和を用いて予兆テーブルを更新してもよい。

次に、Ｓ３０３において、予兆検知部２０６は、新たに予兆を検知したロボットを稼働状態テーブルに登録する。図４（ｂ）は、稼働状態テーブルの一例を示す図である。稼働状態テーブルには、ロボットＩＤと稼働状態とが対応付けて記憶される。稼働状態は、ロボットＩＤで識別されるロボットの稼働状態である。稼働状態は、稼働、停止、稼働待ちの２つの値を取り得る。ここで、稼働待ちは、ロボットが停止している状態であるが、稼働をしようとしている状態である。なお、稼働状態は、稼働状態取得部２０４により取得され、記録される。稼働状態は、監視対象の状態を示す状態情報である。本処理については、図７を参照しつつ説明する。図３に戻り、Ｓ３０３の処理の後、Ｓ３０４において、撮影制御部２０３は、監視ルール更新処理を行う。

図５は、監視装置１００による監視ルール更新処理を示すフローチャートである。Ｓ５０１において、撮影制御部２０３は、監視判断テーブルを更新する。図４（ｃ）は、監視判断テーブルの一例を示す図である。監視判断テーブルには、ロボットＩＤと、残寿命と、異常監視の要否と、が対応付けて記憶される。撮影制御部２０３は、予兆テーブルと、稼働監視テーブルと、判定日の情報と、に基づいて、監視判断テーブルに格納する情報を生成する。ここで、判定日はＳ５０１の処理が実行されている日付であり、図６（ａ）の例では、２０１８年４月２０日である。残寿命は、判定日における寿命の残りの日数である。撮影制御部２０３は、ロボットＩＤが同じ予兆テーブルの算定日から判定日までの経過日数を求めて、予兆テーブルの寿命から経過日数を引いた値を残寿命として求める。異常監視の要否は、処理時点において対応するロボットの異常監視が必要か否かを示す情報である。撮影制御部２０３は、ロボットＩＤが同じ予兆テーブルの発生状況に稼働監視テーブルの稼働状態が該当するとき「要」と判断し、それ以外の場合は「否」と判断する。すなわち、撮影制御部２０３は、予兆が検知され、かつ稼働状態が発生状況に該当する場合に、異常監視が必要であると判断する。

図６は、発生状況と稼働状態に対する異常監視の要否を示す図である。図６に示すように、稼働中に発生する異常のときは稼働状態においてのみ監視が「要」と判断される。反対に停止中に発生する故障の時は停止状態においてのみ監視が「要」と判断される。双方の状態において異常が発生するときは稼働状態にかかわらず監視が「要」と判断される。なお、稼働中に発生する故障などの場合は、稼働が開始する前から監視をすべきであるため、稼働待ちの状態においても監視は「要」と判断される。

図５に戻り、Ｓ５０２において、撮影制御部２０３は、Ｓ５０１における更新後の監視判断テーブルにおいて、異常監視が「要」のレコードが存在するか否かを判定する。撮影制御部２０３は、「要」のレコードが存在する場合には（Ｓ５０２でＹＥＳ）、処理をＳ５０４へ進める。撮影制御部２０３は、「要」のレコードが存在しない場合には（Ｓ５０２でＮＯ）、処理をＳ５０３へ進める。

Ｓ５０３において、撮影制御部２０３は、巡回監視ルールに基づいて、ＰＴＺを制御し、ＮＷカメラ１１２による撮影を行うよう制御する。これにより、ＮＷカメラ１１２は、監視対象のすべてのロボット１１４を順に撮影する巡回監視を実現する。

一方、Ｓ５０４において、撮影制御部２０３は、監視判定テーブルにおいて、異常監視の要否が「要」のロボットを固定監視の対象として決定する。なお、撮影制御部２０３は、異常監視の要否が「要」のロボットが複数存在する場合には、最も残寿命が短いロボットを固定監視の対象として決定する。本処理は、対象決定処理の一例である。そして、撮影制御部２０３は、特定したロボットを固定監視する固定監視ルールを設定し、これに基づいて、ＰＴＺを制御し、ＮＷカメラ１１２による撮影を行うよう制御する。すなわち、固定監視ルールには、特定したロボットのロボットＩＤが定義される。これにより、監視対象は、異常監視が必要なロボットのうちで、残寿命が最も短いロボットに固定される。例えば、図６に示す監視判定テーブルにおいては、監視対象は、ロボットＩＤ「００１」のロボットに固定される。なお、Ｓ５０３又はＳ５０４における撮影制御部２０３の制御の下で撮影された画像は、録画制御部２０１により保存される。ここで、Ｓ５０３及びＳ５０４の処理は、撮影制御処理及び格納処理の一例である。

撮影制御部２０３は、Ｓ５０３の処理の後、処理をＳ５０５へ進める。また、撮影制御部２０３は、Ｓ５０４の処理の後、処理をＳ５０５へ進める。Ｓ５０５において、撮影制御部２０３は、稼働状態テーブルにおいて「稼働待ち」の稼働状態に対応付けられているロボットに対し、稼働を開始してよいことを示す稼働指示を送信する。具体的には、撮影制御部２０３は、通信インターフェイス１０７とネットワーク回線１１１を介してＰＬＣ１１３に稼働指示を送る。受信したＰＬＣ１１３は対象のロボットの稼働を開始する。

図７は、監視装置１００による稼働監視処理を示すフローチャートである。稼働監視処理は、予め定められた頻度で実行される。また、他の例としては、稼働監視処理は、外部のＰＬＣ１１３から送信される、ロボット稼働状態の変更信号をトリガーとして実行されてもよい。Ｓ７０１において、稼働状態取得部２０４は、稼働監視テーブルに登録されているロボットの稼働状態が変化したか否かを判定する。具体的には、稼働状態取得部２０４は、各ロボットの稼働状態を取得し、取得した稼働状態が稼働監視テーブルに登録されている稼働状態と異なる場合に、稼働状態が変化したと判定する。稼働状態取得部２０４は、稼働状態が変化した場合には（Ｓ７０１でＹＥＳ）、処理をＳ７０２へ進める。Ｓ２０４は、稼働状態が変化していない場合には（Ｓ７０１でＮＯ）、稼働監視処理を終了する。Ｓ７０２において、撮影制御部２０３は、稼働状態の変化に対応して、稼働状態テーブルを更新する。次に、Ｓ７０３において、撮影制御部２０３は、監視ルール更新処理を行う。監視ルール更新処理は、図５を参照しつつ説明した処理である。

例えば、図４（ａ）に示す予兆テーブルと、図４（ｂ）に示す稼働状態テーブルが記憶されている状況で稼働監視処理が実行され、Ｓ７０２において、図８（ａ）に示すように、稼働状態テーブルの内容が変更されたとする。この場合、続くＳ７０３において、図８（ｂ）に示すように監視判断テーブルの内容も更新される。ここで、ＩＤ００３のロボットの稼働状態は「稼働待ち」であるが、発生状況として定義された「稼働中」に発生する異常の監視のために、「稼働中」に移行する前に監視を開始するのが望ましい。そこで、図８（ｂ）に示すように、ＩＤ００３のロボットについても、異常監視が「要」に設定される。このように、発生状況に移行する状態にあるロボットについても異常監視を「要」に設定することで、固定監視の候補とすることができる。したがって、稼働直後にロボットに異常が発生するような場合においても、異常の発生前から、予兆が検知されたロボットの映像を録画することができる。

さらに、すべてのロボットが停止した場合には、図８（ａ）に示す稼働状態テーブルは、図９（ａ）に示すように、テーブルの内容が変更される。このとき、監視ルール更新処理により、監視判断テーブルは、図９（ｂ）に示すように、テーブルの内容が更新される。このように、いずれのロボットも固定監視が不要な状態になる。その結果、巡回監視ルールが設定される。これは、いずれの予兆に対応した異常も、稼働中にしか起こり得ず、停止中には固定監視が不要であるためである。このように、監視装置１００は、異常が発生しない状況の際には、通常の巡回監視を実施するよう制御することができる。これにより、ＮＷカメラ１１２を異常発生の直前からの映像を捉える以外の目的に有効に活用できる。

また、図１０（ａ）に示す予兆テーブルと、図９（ａ）に示す稼働状態テーブルが記憶されているとする。この場合、監視判断テーブルには、図１０（ｂ）に示す情報が記憶される。ロボットＩＤ００１の異常の発生状況が「稼働・停止中」であり、稼働中にも停止中にも異常が発生する可能性がある。そのため、ロボットの稼働状態が停止中であっても、異常監視は「要」と判断される。その結果、ロボットＩＤ００１を固定監視するような固定監視ルールが設定される。このように、監視装置１００は、発生状況と稼働状態の組み合せから、異常監視の要否を判断する。

以上のように、本実施形態に係る監視装置１００は、１つのＮＷカメラ１１２により監視対象の複数のロボットを順に撮影する。そして、監視装置１００は、異常の予兆が検知された場合には、撮影対象を予兆が検知されたロボットに固定し、撮影を行うよう制御する。これにより、監視装置１００は、異常が発生する前から、予兆が検知されたロボットの撮影を行い、撮影画像を記録することができる。

さらに、監視装置１００は、予兆検知により寿命を推定し、寿命が最も短いロボットを優先的に撮影対象として決定する。これにより、異常発生の映像をより短期間で得ることができ、映像による原因分析に早く着手できる。さらに、本実施形態の監視装置１００は、異常の予兆が検知されないロボットは固定監視の対象としない。これにより、異常の予兆が検知されたロボットの固定監視や、予め定められた巡回監視に、より多くの時間を割り当てることができる。さらに、監視装置１００は、固定監視ルールを設定する場合において、ロボットが停止状態から稼働状態に移る前に、稼働待ち状態に遷移した場合には、稼働待ち状態中に撮影対象を固定して撮影を開始してから、ロボットの稼働開始を許可する。このように、稼働開始前にロボットに撮影対象を固定できるため、稼働直後にロボットに異常が発生した場合であっても、異常の発生前からの映像を録画できる。

第１の実施形態の第１の変形例について説明する。予兆検知部２０６による異常予測では、理論上は異常の予兆を検知した後、常に異常の予兆を検知する。しかしながら、ロボットからのセンシングデータのノイズなどの影響や、稼働によるロボット内部部品のかみ合いの改善等により、異常の予兆が消えることがある。そのため、異常予測処理（図３）において、予兆検知部２０６は、予兆が消えた場合には、予兆が消えたロボットに関するレコードを予兆テーブルから削除するようにしてもよい。一方で、ノイズなどの影響により、実際には予兆がある場合に、予兆が消えることもある。予兆検知部２０６は、一定の期間の間に継続的に予兆が消えたときには、予兆が消えたロボットに関するレコードを予兆テーブルから削除するようにしてもよい。これによって、異常の発生する可能性の低いロボットを固定監視する必要がなくなる。

第２の変形例としては、監視装置１００は、予兆が検知された監視対象の撮影を、予兆が検知されなかった監視対象に優先して行えばよく、そのための具体的な処理は、実施形態に限定されるものではない。他の例としては、監視装置１００は、予兆が検知された監視対象について、巡回監視ルールに定義された監視時間を一定時間延期する等してもよい。

第３の変形例としては、監視対象は、ロボットに限定されるものではない。他の例としては、組立製品を搬送する搬送器等、ロボット以外の生産装置であってもよい。また、他の例としては、駅・建物などの入場ゲート等のように、生産装置以外の装置であってもよい。このように、監視対象は、センサデータや映像データ等の監視対象の異常検知・異常予測に必要なデータを取得できる装置であればよい。

第４の変形例としては、本実施形態においては、ＮＷカメラ１１２は、巡回監視においては、ロボット単位で巡回して撮影を行うこととしたが、撮影対象の単位はこれに限定されるものではない。他の例としては、１台のロボットの部位単位で撮影を行うこととしてもよい。また他の例としては、複数台のロボット単位で撮影を行うこととしてもよい。また、他の例としては、生産ラインのエリア単位、生産工場内の製品の搬送経路のエリア単位、人が通る通路のエリア単位で撮影を行うこととしてもよい。この場合、巡回監視ルールは、撮影単位に応じて定義されるものとする。

第５の変形例としては、異常検知や異常の予兆検知において利用するセンシングデータは、装置内部から取得できる制御等のデータだけではなく、装置に取り付けた振動センサ・熱センサ等の情報であってもよい。また、他の例としては、監視装置１００は、映像データなどを利用してもよい。このように、異常検知や予兆検知に利用されるデータは、実施形態に限定されるものではない。

第６の変形例としては、監視装置１００は、稼働待ち状態だけでなく、停止待ち状態についても定義して、異常予測処理を行ってもよい。監視装置１００は、停止待ち状態にあるときは、停止中にのみ発生する異常の監視のために、停止状態に移行する前に対象のロボットを撮影対象に設定した上でロボットが停止することを許可する。これにより、状態変化直後にロボットに異常が発生する場合にも、異常発生前から映像を録画することができる。

第７の変形例としては、監視装置１００は、Ｓ５０５の処理を行わないこととし、稼働待ち状態から一定時間が経過した後で、稼働状態を変更するようにしてもよい。この場合、監視装置１００は、稼働待ち状態の継続中に撮影対象を変更すればよい。

第８の変形例としては、監視装置１００は、処理時点の状況が発生状況に一致するか否かによらず、異常の予兆が検知されたことを条件として、監視判断テーブルにおいて異常監視を「要」に設定してもよい。この場合、予兆検知部２０６による発生状況の管理や、稼働状態取得部２０４による稼働状態の取得等の処理も不要である。

第９の変形例としては、本実施形態の映像管理部２０２は、録画ルールに該当しないときは映像の保存を行わないこととしたが、他の例としては、常に映像を保存するようにしてもよい。この場合、監視装置１００は、録画制御部２０１を有さなくともよい。

第１０の変形例としては、複数の監視対象において異常の予兆が検知された場合には、撮影制御部２０３は、１つの監視対象を固定監視の対象として選択すればよく、そのための具体的な処理は実施形態に限定されるものではない。

第１１の変形例としては、本実施形態においては、監視装置１００は、映像が最大容量に達したとき映像が削除されるため、異常発生前からの映像を残すようにしている。ただし、映像管理部２０２の容量に基づく削除をしなくてもよい。この場合、異常を検知してからの映像を特別に残すように処理する必要がないため、監視装置１００は、異常検知部２０５を有さなくともよい。

第１２の変形例としては、監視装置１００は、異常の予兆を示すロボットがないときは、監視を行わないようにしてもよい。例えば、監視装置１００は、ＮＷカメラ１１２等の電源をＯＦＦにするよう制御する。具体的には、監視装置１００は、図５のＳ５０３においてＮＷカメラの電源をＯＦＦにするようにし、Ｓ５０４の直前でＮＷカメラの電源をＯＮにするよう制御する。これによって、異常の予兆を示すロボットがないときは監視を行わないため、電力等のリソース消費を抑えることができる。

（第２の実施形態）
次に、第２の実施形態に係る監視システムについて、第１の実施形態に係る監視システムと異なる点を主に説明する。異常の発生の直前の短い期間の映像だけではなく、長い期間の映像が原因分析に利用される場合がある。例えば、サビやオイル漏れなどの劣化に時間のかかる場合には、長期的な映像が原因分析にとって有効である。しかしながら、異常から発生までの期間が長い状態での寿命の予測は精度が低いことが多い。そこで、本実施形態の監視装置１００は、寿命が一定以下になるまでは、予兆が検知されたロボットを巡回監視して、寿命が一定以下になった時に固定監視する。

図１１は、第２の実施形態に係る監視ルール更新処理を示すフローチャートである。なお、図１１に示す監視ルール更新処理の各処理のうち、図５を参照しつつ説明した第１の実施形態に係る監視ルール更新処理の各処理と同一の処理には、同一の番号を付している。撮影制御部２０３は、Ｓ５０２において、監視判断テーブルにおいて、異常監視が「要」のレコードが存在する場合には（Ｓ５０２でＹＥＳ）、処理をＳ１１０１へ進める。なお、撮影制御部２０３は、異常監視が「要」のレコードが存在しない場合には（Ｓ５０２でＮＯ）、第１の実施形態において説明したように、処理をＳ５０３へ進める。

Ｓ１１０１において、撮影制御部２０３は、監視判断テーブルで異常監視が「要」のロボットの残寿命が、すべて基準値以上であるか否かを判断する。ここで、基準値は予め定められた閾値である。撮影制御部２０３は、残寿命がすべて基準値以上の場合には（Ｓ１１０１でＹＥＳ）、処理をＳ１１０２へ進める。撮影制御部２０３は、基準値未満のロボットが存在する場合には（Ｓ１１０１でＮＯ）、処理をＳ５０４へ進める。

Ｓ１１０２において、撮影制御部２０３は、残寿命に基づいて各ロボットの監視時間を定め、巡回監視ルールを設定する。なお、ここで設定される巡回監視ルールは、Ｓ５０３において設定される巡回監視ルールと同様に、監視対象のすべてのロボット１１４を順番に撮影する条件である。ただし、Ｓ１１０２において設定される巡回監視ルールは、残寿命に基づいて設定された監視時間が定義されており、Ｓ５０３において設定される、デフォルトの巡回監視ルールとは、監視時間の定義が異なる。撮影制御部２０３は、具体的には、（式１）に基づき、予め定めた合計監視時間を残寿命に反比例させてロボットごとの監視時間を決定する。図１２は、合計監視時間が６５秒の場合の各ロボットの監視時間を示す図である。

また、他の例としては、撮影制御部２０３は、ロボット毎に基準となる監視時間を定めておき、それに（式１）で得られる監視時間を加えるなどして求めてもよい。また、他の例としては、撮影制御部２０３は、残寿命の順位毎に定めた監視時間を用いるようにしてもよい。また、他の例としては、撮影制御部２０３は、残寿命によらずに一律の監視時間を設定してもよい。また、他の例としては、撮影制御部２０３は、残寿命の短いＮ個のロボットのみに絞り込んで監視時間を決めてもよい。また、他の例としては、撮影制御部２０３は、Ｓ５０３において設定される、デフォルトの巡回監視ルールに、残寿命に基づいて求めたものを統合して巡回監視ルールを設定してもよい。これにより、デフォルトの巡回監視ルールにおいて定義されたロボットを監視しつつ、異常の予兆のあるロボットも監視できるようになる。なお、この場合の監視時間の決定方法はこれらに限定されない。Ｓ１１０２の処理は、時間決定処理の一例である。

なお、異常予測処理によって寿命が更新される方が望ましい。なぜなら、異常発生の時期に近いほど予測精度は高まると考えられるため、時間の経過ごとに寿命を再計算するほうが、寿命の精度が高まるためである。

以上の処理により、監視装置１００は、残寿命が長いうちは巡回監視する。これによって、残寿命の予測が誤っている場合にも、異常発生前の映像が録画できる。そのため、長期的な映像に基づき原因分析をする際に有効である。また、監視装置１００は、残寿命に基づいて監視時間を決める。これによって、より異常の発生の可能性が高いロボットの映像を長く残せるので、原因分析をする際に有効である。第２の実施形態に係る監視装置１００のこれ以外の構成及び処理は、第１の実施形態に係る監視装置１００の構成及び処理と同様である。

（第３の実施形態）
次に、第３の実施形態に係る監視システムについて、他の実施形態に係る監視システムと異なる点を主に説明する。第３の実施形態に係る監視システムにおいては、監視装置１００は、録画ルールに定められた録画期間外において異常の発生が予想される場合に、録画ルールを更新する。さらに、監視装置１００は、通常の録画ルールに定められた録画期間以外の期間の録画データについては、異常が検知されなかった場合には、優先的に削除する。

本実施形態の録画制御部２０１は、監視ルールに含まれるロボットの異常の発生状況に合わせて録画ルールを変更する。具体的には、録画制御部２０１は、図１３（ａ）に示す録画ルールテーブルにおいて、通常ルール以外にも異常前ルールを、異常の発生状況毎に保持しており、予兆の検知結果等に基づいて、参照する録画ルールを決定する。ここで、異常前ルールとは、通常ルールと異なる録画ルールである。録画制御部２０１は、異常前ルールを参照する場合には、通常ルールにおいて録画される期間以外の期間においても録画が行われることになる。なお、異常前ルールにおいて録画される期間は、通常ルールにおいて録画される期間と重なる期間を含んでもよく、また含まなくてもよい。以降では、通常ルールにおいて録画される期間を通常ルール期間と称することとする。一方で、異常前ルールにおいて録画される期間のうち、通常ルール期間と重ならない期間を異常前ルール期間と称することとする。なお、異常前録画ルールは、入力デバイス１０９やモニタ１１０を介してユーザが入力することで作成されるものとする。図１３（ａ）の例では、通常ルールの他、発生状況が稼働の場合の異常前ルールと、発生状況が停止の場合の異常前ルールと、発生状況が稼働又は停止の場合の異常前ルールとが保持されている。

他の例としては、異常が生じ得る時間帯に応じた録画ルールが設定されてもよい。本実施形態のように、異常の発生状況が稼働状態により定義され、生産工場の稼働予定などが決まっているとする。この場合には、録画制御部２０１は、図１３（ｂ）に示す稼働予定テーブルを入力デバイス１０９やモニタ１１０を介して取得する。そして、録画制御部２０１は、録画ルールの通常ルールと、稼働予定テーブルの情報から、異常前ルールを求める。具体的には、録画制御部２０１は、稼働状態ごとの時間帯と通常ルールの時間帯の論理和を求める。これによって、生産工場の稼働予定などから自動的に異常前ルールを決定できる。

また、他の例としては、録画制御部２０１は、異常の発生状況が生じる時間帯を、過去の状況の発生時刻の履歴をもとに、統計的な処理により求めてもよい。録画制御部２０１は、発生状況が稼働状態のように分かりやすい場合は、入力デバイス１０９などを介して取得できるが、より複雑になる場合には難しい。この場合には、録画制御部２０１は、過去に状況が発生した時刻をロギングしておき、時間軸上での発生状況のカーネル密度推定などを行い、密度関数が所定以上を有する区間を発生時間帯とする。さらには、録画制御部２０１は、これをモニタ１１０などに表示して入力デバイス１０９により修正してもよい。これによって、入力のユーザ負荷を軽減できる。また、他の例としては、録画制御部２０１は、入力デバイス１０９やモニタ１１０を介して、異常の発生状況に合わせた録画ルールを直接受け付けてもよい。

また、他の例としては、録画制御部２０１は、ユーザ入力により異常前録画ルールを定めるのではなく、自動生成するようにしてもよい。例えば、終日を録画するルールをデフォルト値として保持して起き、それを用いるようにしてもよい。異常の発生状況に合わせた録画ルールの作成方法はこれらに限定されない。

録画制御部２０１は、第１の実施形態において説明したように、最大容量を超えないようにデータを削除・保存するために、撮影日時が古いデータを削除する。本実施形態に係る録画制御部２０１はさらに、通常の録画ルールの期間以外の他の期間に撮影されたデータが保存されている場合には、他の期間の映像データにおける監視対象が稼働したときに、他の期間の映像データを優先して削除する。具体的には、録画制御部２０１は、映像データを図１４に示すような映像管理テーブルを用いて管理をする。ここで、撮影期間は、映像データの撮影された開始日時と終了日時からなる期間情報である。サイズは、映像データのバイトサイズである。映像データは映像のバイナリデータである。フラグは、削除を制御するためのフラグである。フラグが「削除」の場合、撮影日時に係わらず優先的して削除される。一方でフラグが「ロック」である場合は、撮影日時に係わらず削除が禁止される。フラグ「ＮＡ」は、フラグが「削除」の映像データがない場合に、撮影日時の古さに基づいて順に削除されることを示す。なお、初期状態においては、フラグには「ＮＡ」が記録される。録画制御部２０１は、異常検知時に映像を映像管理部２０２から削除しないように制御された場合に、フラグを「ロック」に変更する。また、録画制御部２０１は、異常前ルール期間の映像に対しては、フラグを「削除」に変更する。

図１５は、第３の実施形態に係る監視ルール更新処理を示すフローチャートである。なお、図１５に示す監視ルール更新処理のうち、図５を参照しつつ説明した第１の実施形態に係る監視ルール更新処理の各処理及び図１１を参照しつつ説明した第２の実施形態に係る監視ルール更新処理の各処理と同一の処理には、それぞれ同一の番号を付している。

第３の実施形態に係る監視ルール更新処理においては、ＣＰＵ１０１は、Ｓ５０３の処理の後、処理をＳ１５０１へ進める。Ｓ１５０１において、録画制御部２０１は、録画ルールを録画ルールテーブル（図１３（ａ））に格納される通常ルールに設定する。異常監視が「要」のロボットが存在しないためである。また、ＣＰＵ１０１は、Ｓ１１０２及びＳ５０４の処理の後、処理をＳ１５０２へ進める。Ｓ１５０２において、録画制御部２０１は、監視ルール（巡回監視ルールあるいは固定監視ルール）における監視対象のロボットの異常の発生状況を取得し、発生状況に対応する異常前ルールを録画ルールテーブルから選択する。

図１６は、第３の実施形態に係る稼働監視処理を示すフローチャートである。なお、図１６に示す稼働監視処理のうち、図７を参照しつつ説明した第１の実施形態に係る稼働監視処理の各処理と同一の処理には、同一の番号を付している。ＣＰＵ１０１は、Ｓ７０２の処理の後、処理をＳ１６０１へ進める。

Ｓ１６０１において、録画制御部２０１は、映像管理部２０２に異常前ルール期間に録画された映像が存在するか否かを判定する。具体的には、録画制御部２０１は、図１３（ａ）の録画ルールテーブルと映像管理テーブル（図１４）を参照し、映像管理部２０２に異常前ルール期間の映像が保存されているか否かを判定する。ただし、録画制御部２０１は、映像管理部２０２にフラグが「ＮＡ」以外の映像しか存在しない場合には、異常前ルール期間の映像はないと判定する。録画制御部２０１は、異常前ルール期間の映像が存在する場合には（Ｓ１６０１でＹＥＳ）、処理をＳ１６０２へ進める。録画制御部２０１は、異常前ルール期間の映像が存在しない場合には（Ｓ１６０１でＮＯ）、処理をＳ７０３へ進める。

Ｓ１６０２において、録画制御部２０１は、異常前ルール期間の映像の撮影後に、予兆が検知されたロボットの稼働が確認されたか否かを判断する。具体的には、Ｓ１６０１で特定した異常前ルール期間の映像を得る。該映像の期間中に撮影されたロボットをリストアップするために、期間中に適用された監視ルール（巡回監視ルールあるいは固定監視ルール）と監視判断テーブルを得て、監視対象となりかつ予兆が検知されていたロボットを得る。得られたロボット一覧は、該映像に映る予兆を示すロボットである。よって、次に、得られたロボットが全て稼働したか否かを判断する。具体的には、稼働状態取得部２０４を介して継続的にロボットの稼働状態をロギングしておき、ログから撮影後に稼働をしたか否かを判断する。

録画制御部２０１は、すべてのロボットが稼働した場合には（Ｓ１６０２でＹＥＳ）、処理をＳ１６０３へ進める。録画制御部２０１は、稼働していないロボットが存在する場合には（Ｓ１６０２でＮＯ）、処理をＳ７０３へ進める。Ｓ１６０３において、録画制御部２０１は、映像管理テーブル（図１４）において、異常前ルール期間の映像に対応するレコードを特定し、特定したレコードのフラグを「ＮＡ」から「削除」に更新する。録画制御部２０１は、１つのレコード内に異常前ルール期間の映像と通常ルール期間の映像が含まれている場合には、映像レコードを期間に応じて分割した上で、異常前ルール期間の映像のレコーのフラグを「削除」に変更する。なお、この場合、通常ルール期間の映像のレコードのフラグは「ＮＡ」とする。

図１７は、監視装置１００による映像保存処理を示すフローチャートである。監視装置１００は、映像データを受信する度に、映像保存処理を実行する。Ｓ１７０１において、録画制御部２０１は、映像データの撮影時刻が、設定中の録画ルールの期間に該当するか否かを判定する。録画制御部２０１は、録画ルールの期間に該当する場合には（Ｓ１７０１でＹＥＳ）、処理をＳ１７０２へ進める。録画制御部２０１は、録画ルールの期間に該当しない場合には（Ｓ１７０１でＮＯ）、映像を保存することなく映像保存処理を終了する。Ｓ１７０２において、録画制御部２０１は、映像管理部２０２に保存されているデータ容量が保存可能な最大容量を超えているか否かを判定する。録画制御部２０１は、データ容量が最大容量を超えている場合には（Ｓ１７０２でＹＥＳ）、処理をＳ１７０４へ進める。録画制御部２０１は、データ容量が最大保存容量を超えていない場合には（Ｓ１７０２でＮＯ）、処理をＳ１７０３へ進める。Ｓ１７０３において、録画制御部２０１は、新たな領域を保存領域として確保し、確保した領域に、受信した映像データを保存する。

Ｓ１７０４において、録画制御部２０１は、映像管理部２０２の映像管理テーブルにおいて、フラグが「削除」のレコードが存在するか否かを判定する。録画制御部２０１は、「削除」のレコードが存在する場合には（Ｓ１７０４でＹＥＳ）、処理をＳ１７０６へ進める。録画制御部２０１は、「削除」のレコードが存在しない場合には（Ｓ１７０４でＮＯ）、処理をＳ１７０５へ進める。Ｓ１７０５において、録画制御部２０１は、フラグが「ＮＡ」のレコードのうち、撮影期間が最も古いレコードを特定する。そして、録画制御部２０１は、特定したレコードのデータ領域を新たな保存用領域とし、新たな保存用領域に、受信した映像データを保存する。Ｓ１７０６において、録画制御部２０１は、フラグが「削除」のレコードのデータ領域を新たな保存用領域とし、新たな保存用領域に、受信した映像データを保存する。Ｓ１７０６の処理は、削除制御処理の一例である。なお、第３の実施形態に係る監視システムのこれ以外の構成及び処理は、他の実施形態に係る監視システムの構成及び処理と同様である。

以上のように、本実施形態においては、監視装置１００は、異常の予兆が検知された場合には、録画ルールを変更し、異常の発生状況において録画が行われるように制御する。これにより、録画ルールにおける録画期間外において異常の発生が予想される場合においても、異常が発生する前からの映像を保存することができる。

例えば、生産工場での生産ラインの稼働が８時から１７時までであるとき、録画ルールも８時から１７時とすることが考えられる。これに対し、生産ラインが停止している間にも異常が発生すると予想される場合がある。本実施形態の監視装置１００によれば、生産ラインが停止している間も異常の発生の監視が実現されるので、異常の瞬間を逃すことなく撮影ができる。逆に、夜間の監視のためにライン停止中を通常ルールとしている場合において、日中に異常発生が予想される場合がある。この場合にも、監視装置１００は、録画ルールを更新することで、日中のライン稼働中に発生する異常を撮影できる。

また、通常ルールの期間外の映像は、異常が検知されなかった場合には優先的に削除される。これによって、通常の録画ルールの期間外の映像を録画することにより、通常の録画ルールの期間の映像が大幅に消えることを抑制できる。通常ルールの期間は異常発生からの映像データを捉える以外の目的により撮影されていることが予想されるため、他目的での利用を阻害しなくなる。例えば、夜間監視などが目的の場合には、侵入などが発覚したときに過去のデータをさかのぼって確認する必要がある。そのため、通常ルールの期間の映像が残りやすくなることは効果がある。

第３の実施形態の第１の変形例について説明する。本実施形態においては、監視装置１００は、通常の録画ルールに定められた録画期間以外の期間の録画データについては、異常が検知されなかった場合には、優先的に削除する。しかし、優先的に削除しなくてもよい。このとき、図１６の映像のフラグを削除に更新する処理は不要になり、図１７のＳ１７０４，Ｓ１７０６の処理も不要である。これによって、異常前ルール期間と通常ルール期間のどちらの映像も撮影が古い順に削除される。このように、録画期間外の録画データの優先削除の有無に、実施形態は限定されるものではない。

第２の変形例としては、通常録画ルールはなくてもよい。本実施形態においては、監視装置１００は異常の予兆を示すロボットがないとき巡回監視を行うため、通常ルールを設定していた（Ｓ１５０１）。しかし、予兆を示すロボットがないとき、ＮＷカメラ等の電源をＯＦＦにすることが考えられる。このとき、通常録画ルールはないことが自然である。この場合は、録画ルールを通常録画ルールに設定（Ｓ１５０１）において録画ルールを削除し、録画ルールがないときは録画しないように録画制御部２０１を構成する。あるいは、録画期間のないルールを録画ルールとして設定する。これにより、Ｓ１５０２で設定される異常前ルールを無効にすることができる。このように、通常録画ルールの有無に、実施形態に限定されるものではない。

第３の変形例としては、本実施形態においては、予兆が検知されたロボットが稼働したと判断（Ｓ１６０２）すると、直ちに異常前ルール期間の映像のフラグを「削除」に更新（Ｓ１６０３）している。これを、一定時間の稼働を確認後に異常前ルール期間の映像のフラグを「削除」に更新するようにしてもよい。これにより、稼働からしばらくしてから異常が発生する場合においても、映像を残すことができるようになる。

（第４の実施形態）
次に、第４の実施形態に係る監視システムについて、他の実施形態に係る監視システムと異なる点を主に説明する。本実施形態の異常検知部２０５及び予兆検知部２０６は、ＰＬＣ１１３を介して得られるデータのデータ源の電源がオンの場合には、第１の実施形態において説明したように、ＰＬＣ１１３からのデータに基づいて、それぞれ異常検知及び予兆検知を行う。一方で、異常検知部２０５及び予兆検知部２０６は、データ源の電源がオフの場合には、ＮＷカメラ１１２により撮影された映像を用いて、それぞれ異常検知及び予兆検知を行う。この場合、具体的には、異常検知部２０５は、ＮＷカメラ１１２の映像を利用して、モーション検知により、所定以上のモーションが発生したときに異常を検知する。また、他の例としては、異常検知部２０５は、映像の音声から、所定以上のレベルの音量が検知されたときに異常を検知してもよい。なお、映像を用いた異常検知の方法はこれらに限定されるものではない。

予兆検知部２０６は、異常検知部２０５による異常検知の方法に応じた方法で予兆検知を行う。例えば、異常検知部２０５が映像を用いたモーション検知により異常検知を行う場合には、予兆検知部２０６は、映像をもとに、正常時の映像を予め学習しておき、正常時の映像との乖離の程度に応じて予兆検知を行う。これにより、生産停止中等のように、データ源等の電源がオフの状態においても、異常検知及び予兆検知を行うことができる。

図１８は、監視装置１００による異常検知変更処理を示すフローチャートである。Ｓ１８０１において、異常検知部２０５は、予め定められた装置の電源がＯＦＦであるか否かを判定する。ここで対象となる装置は、ＰＬＣ１１３やロボット１１４、ロボット１１４に対応して設置されたセンサ、生産装置等であってもよい。異常検知部２０５は、装置の電源がＯＦＦの場合には（Ｓ１８０１でＹＥＳ）、処理をＳ１８０２へ進める。異常検知部２０５は、装置の電源がＯＮの場合には（Ｓ１８０１でＮＯ）、処理をＳ１８０３へ進める。

Ｓ１８０２において、異常検知部２０５は、異常検知の方法として、映像に基づく検知方法を設定する。さらに、異常検知部２０５は、予兆検知の方法として、映像に基づく検知方法を設定する。一方で、Ｓ１８０３において、異常検知部２０５は、異常検知の方法として、センサデータに基づく方法を設定する。さらに、異常検知部２０５は、予兆検知の方法として、センサデータに基づく方法を設定する。これにより、電源ＯＦＦの場合には、異常検知部２０５は、映像に基づく異常検知を行い、予兆検知部２０６は、映像に基づく予兆検知を行う。一方、電源ＯＮの場合には、異常検知部２０５は、センサデータに基づく異常検知を行い、予兆検知部２０６は、センサデータに基づく予兆検知を行う。なお、第４の実施形態に係る監視システムのこれ以外の構成及び処理は、他の実施形態に係る監視システムの構成及び処理と同様である。

以上の通り、第４の実施形態に係る監視装置１００は、エラー信号による異常検知ができないときも、異常の発生を検知して、映像を残すことができる。休日や夜間などの生産工場が稼働していないときには、生産装置の電源がＯＦＦにされることがある。そのような場合にも、ロボットの関節軸のブレーキなどに異常が生じれば、ロボットアームの固定が解除され、壁にぶつかるなどの大きな音やモーションを生じると考えられる。本実施形態に係る監視装置１００は、このような異常を検知することができ、さらにこのような異常が発生する前から映像を残すことができる。

以上、上述した各実施形態によれば、より簡易な構成により、異常発生前の映像を録画することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００ 監視装置
１１２ ＮＷカメラ
２０３ 撮影制御部
２０５ 異常検知部
２０６ 予兆検知部

Claims (14)

1. 複数の監視対象の監視を行う監視装置であって、
   監視対象の異常の予兆を検知する予兆検知手段と、
   予兆が検知された監視対象が複数存在する場合に、予兆が検知された各監視対象の、予兆が検知された時点から異常発生の推定時点までの推定期間に応じて、撮影対象とする監視対象を決定する対象決定手段と、
   前記対象決定手段により決定された前記監視対象を、他の監視対象に優先して撮影するよう制御する撮影制御手段と、
   前記撮影制御手段により撮影された映像を格納する格納手段と
   を有することを特徴とする監視装置。
2. 前記撮影制御手段は、複数の監視対象を順番に撮影するよう制御し、予兆が検知された場合に、予兆が検知されなかった監視対象に優先して、予兆が検知された前記監視対象の撮影を行うよう制御することを特徴とする請求項１に記載の監視装置。
3. 前記撮影制御手段は、予兆が検知された場合に、予兆が検知された監視対象の撮影を行うよう制御し、かつ予兆が検知されなかった監視対象の撮影を行わないよう制御することを特徴とする請求項１又は２に記載の監視装置。
4. 前記対象決定手段は、前記推定期間が最も短い監視対象を撮影対象として決定することを特徴とする請求項１乃至３の何れか１項に記載の監視装置。
5. 前記対象決定手段は、予兆が検知された各監視対象の前記推定期間のうち少なくとも１つが予め定められた閾値よりも短い場合に、前記推定期間に応じて撮影対象を決定することを特徴とする請求項１乃至４の何れか１項に記載の監視装置。
6. 前記撮影制御手段は、予兆が検知された各監視対象の前記推定期間がいずれも閾値以上の場合に、前記複数の監視対象を順番に撮影するよう制御することを特徴とする請求項１乃至５の何れか１項に記載の監視装置。
7. 予兆が検知された各監視対象の前記推定期間がいずれも閾値以上の場合に、前記推定期間に応じて、前記予兆が検知された各監視対象の監視時間を決定する時間決定手段をさらに有し、
   前記撮影制御手段は、前記時間決定手段により決定された監視時間に従い、前記複数の監視対象を順番に撮影するよう制御することを特徴とする請求項６に記載の監視装置。
8. 前記監視対象の状態を示す状態情報を取得する取得手段と、
   前記状態情報に基づいて、前記監視対象が異常の発生状況にあるか否かを判定する判定手段と
   をさらに有し、
   前記撮影制御手段は、前記予兆が検知された前記監視対象が、異常の発生状況にある場合に、前記予兆が検知された前記監視対象の撮影を行うよう制御することを特徴とする請求項１乃至７の何れか１項に記載の監視装置。
9. 前記判定手段は、前記状態情報に基づいて、前記監視対象が異常の発生状況に移行する状態にあるか否かをさらに判定し、
   前記撮影制御手段は、前記予兆が検知された前記監視対象が、前記異常の発生状況に移行する状態にある場合に、前記予兆が検知された前記監視対象を撮影するよう制御することを特徴とする請求項８に記載の監視装置。
10. 前記撮影制御手段は、前記予兆が検知されていない場合に、第１の期間において撮影を行うよう制御し、前記予兆が検知された場合には、前記第１の期間と異なる第２の期間において撮影を行うよう制御することを特徴とする請求項１乃至９の何れか１項に記載の監視装置。
11. 前記第２の期間のうち第１の期間と重ならない期間において撮影された映像を、前記第１の期間の映像に優先して削除するよう制御する削除制御手段をさらに有することを特徴とする請求項１０に記載の監視装置。
12. 前記削除制御手段は、前記第２の期間のうち前記第１の期間と重ならない期間において撮影された映像を取得し、該映像の期間において前記撮影制御手段が撮影をした予兆を示す監視対象の稼働を確認後に、該映像を前記第１の期間の映像に優先して削除するよう制御することを特徴とする請求項１１に記載の監視装置。
13. 複数の監視対象の監視を行う監視装置が実行する監視方法であって、
    監視対象の異常の予兆を検知する予兆検知ステップと、
    予兆が検知された監視対象が複数存在する場合に、予兆が検知された各監視対象の、予兆が検知された時点から異常発生の推定時点までの推定期間に応じて、撮影対象とする監視対象を決定する対象決定ステップと、
    前記対象決定ステップにより決定された前記監視対象を、他の前記監視対象に優先して撮影するよう制御する撮影制御ステップと、
    前記撮影制御ステップにおいて撮影された映像を格納する格納ステップと
    を含むことを特徴とする監視方法。
14. コンピュータを、請求項１乃至１２の何れか１項に記載の監視装置の各手段として機能させるためのプログラム。

Images