(57)【特許請求の範囲】
【請求項１】
ウォッチドッグによる再起動機能を有した監視通報装置において、
前記ウォッチドッグのタイマクリア信号を生成するＯＳと
プロセスドライバである個別のアプリケーションプロセスやハード制御ドライバの状態を一括管理するプロセスコントロールを設け、
前記プロセスコントロールは、前記個別のアプリケーションプロセスやハード制御ドライバの個々の生存信号を受信し、一纏めにした生存信号として、全てのプロセスドライバの動作が確認されている場合のみ生存パルスを前記ＯＳに送信し、
前記ＯＳは、前記生存パルスを前記タイマクリア信号として前記ウォッチドッグへ送信し、前記ウォッチドッグによる再起動機能を制御することを特徴とする監視通報装置。
【請求項２】
請求項１に記載の監視通報装置において、
前記プロセスコントロールは、前記個別のアプリケーションプロセスやハード制御ドライバが動作しているときには前記ＯＳへの生存信号を送信し、前記個別のアプリケーションプロセスやハード制御ドライバが異常時には前記ＯＳへの生存信号を停止することを特徴とする監視通報装置。
【請求項３】
請求項１に記載の監視通報装置において、
前記プロセスコントロールは、異常を検出した前記個別のアプリケーションプロセスやハード制御ドライバに対して個別の再起動処理を実施した後、復旧が確認されない場合にはウォッチドッグによるハードウェア全体の再起動を行うことを特徴とする監視通報装置。
【請求項４】
請求項１に記載の監視通報装置において、
前記個別のアプリケーションプロセスやハード制御ドライバに対して異常を検知した際に、揮発領域に保持しているデータを不揮発領域に退避を行うことを特徴とする監視通報装置。
【請求項５】
組込みＯＳを利用した監視通報装置のウォッチドッグによる再起動制御方法であって、
ウォッチドッグのタイマクリア信号を生成するＯＳを有し、
プロセスやＯＳ、ＣＰＵの個々の生存信号を１系統に纏めて一纏めにした生存信号に集約し、
全てのプロセスやＯＳ、ＣＰＵの個々の生存信号が確認出来た場合に前記一纏めにした生存信号を前記ＯＳへ送信することで該ＯＳがウォッチドッグのタイマクリア信号を生成し、
1つでも前記個々の生存信号が確認できなかった場合には前記一纏めにした生存信号を前記ＯＳへ送信しないことで該ＯＳがウォッチドッグのタイマクリア信号を生成せず、ウォッチドッグによる監視通報装置の再起動を実施することを特徴とする監視通報装置のウォッチドッグによる再起動制御方法。
【請求項６】
請求項５に記載の監視通報装置のウォッチドッグによる再起動制御方法において、
前記個々の生存信号が確認できなかった前記プロセスやＯＳ、ＣＰＵに対して個別の再起動処理を実施した後、復旧が確認されない場合には、前記ウォッチドッグによる監視通報装置の再起動を実施することを特徴とする監視通報装置のウォッチドッグによる再起動制御方法。
【請求項７】
請求項５に記載の監視通報装置のウォッチドッグによる再起動制御方法において、
前記個々の生存信号が確認できなかった際に、揮発領域に保持しているデータを不揮発領域に退避を行うことを特徴とする監視通報装置のウォッチドッグによる再起動制御方法。
【請求項８】
ＣＰＵと、
タイマクリア信号によりタイマがリセットされ、リセットされないと設定された時間後に前記ＣＰＵをリセットするリセットＩＣと、
前記ＣＰＵが制御するハードウェアを有し、
前記ＣＰＵは、前記ハードウェアを制御するハード制御ドライバと、個別のアプリケーションプロセスと、該個別のアプリケーションプロセスとハード制御ドライバの状態を一括管理するプロセスコントロールと、ＯＳを有し、
前記プロセスコントロールは、プロセスドライバである前記個別のアプリケーションプロセスやハード制御ドライバの個々の生存信号を受信し、一纏めにした生存信号として、全てのプロセスドライバの動作が確認されている場合のみ生存パルスを前記ＯＳに送信し、
前記ＯＳは、前記生存パルスを前記タイマクリア信号として前記ＣＰＵの端子を経由して前記リセットＩＣに送信することを特徴とする監視通報装置。
【請求項９】
請求項８に記載の監視通報装置において、
前記プロセスコントロールは、異常を検出した前記個別のアプリケーションプロセスやハード制御ドライバに対して個別の再起動処理を実施した後、復旧が確認されない場合には前記リセットＩＣによる前記ＣＰＵのリセットを行うことを特徴とする監視通報装置。
【請求項１０】
請求項８に記載の監視通報装置において、
前記個別のアプリケーションプロセスやハード制御ドライバに対して異常を検知した際に、揮発領域に保持しているデータを不揮発領域に退避を行う処理を行うことを特徴とする監視通報装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視通報装置に係り、特にその異常時処理に関する。
【背景技術】
【０００２】
従来から、現場に設置した監視通報装置に監視対象のデータを取り込んで、通信で遠隔地に監視対象の状態を転送して表示する監視システムが知られている。例えば、上下水道の給水、配水設備や、産業用の生産設備、販売データ収集設備等を遠隔監視や制御を行う監視装置に対してデータの転送及び利用者に対して警報通報を行う監視通報装置がある。
【０００３】
このような監視システムでは、通信コスト低減を図るため、常時通信回線ではなく公衆電話回線などの通信時のみ回線接続を行う都度通信回線を使用する場合も多い。
【０００４】
本技術分野の背景技術として、特開２００１−１７７６５７号公報（特許文献１）がある。特許文献１には、データを収集する遠方監視局と遠隔地の制御対象からデータを収集するテレメータ子局との間を、発呼によって接続される電話回線を介してデータや信号を伝送するように構成したシステムが記載されている。
【０００５】
このような監視通報装置は現場で異常が発生したときや外部からのアクセスが有ったときのみ通信機能を有効にして、現場の状況や収集しているデータを監視装置に伝送したり、利用者に対して通知を行う。ＡＤＳＬなどのネットワーク回線サービスが提供される以前から、公衆回線を利用してその都度通信を行う監視システムが知られている。
【０００６】
公衆回線を使用する監視通報装置はアナログモデムの機能を内蔵し、同じくモデムを接続したサーバー装置へダイアルアップを行いデータの伝送を行う機能や、利用者へ電話をかけて音声メッセージによる警報通報を行う。現在は、安価なネットワーク回線サービスの普及により電話回線を利用した監視システムの需要は減少しているが、現在でも音声による通報機能は利用者の携帯電話に直接通報を行えるなどの利点から一定の需要が有る。
【０００７】
また、公衆電話回線の他に新たに携帯電話回線を利用した監視システムも存在する。携帯電話回線は電波を利用するため他の通信回線と異なり、現場に電話線などの固定の通信線を施設する必要が無いため導入が非常に容易であることと、車載の設備のような移動体での通信が可能なことや、通信費が一般に固定回線よりも安価な場合があるため、近年需要が拡大している。このように都度通信による監視システムは、現在でも市場から一定の需要を得ている。
【０００８】
監視装置などの、特定の機能を実現するための必要十分条件を満たす、選択や交換の不可能なハードウェアとプログラムで構成されるコンピュータシステムである組込みシステムにおいては、プログラムの異常によりシステムが動作を停止した場合には、ウォッチドッグ・タイマ（ウォッチドッグ）を用いた処理によりシステムの再起動を行い異常状態からの回復を図る手段が用いられることが多い。ウォッチドッグ・タイマを用いた処理は、一般的には、ＣＰＵの他に、リセットＩＣ等の自律的に稼働するハードウェア（ウォッチドッグ）を用意し、ＣＰＵから特定のタイミングごとにタイマクリア信号を送信する。そして、ウォッチドッグに一定時間を過ぎてもタイマクリア信号が送信されない場合は、ウォッチドッグによりハードウェアの再起動や電源ＯＦＦ等の処理が実行される。
【０００９】
特に都度通信による監視システムは、監視装置自体が動作停止した場合に、監視装置の停止を利用者に通知する手段が無いため、システム停止時にウォッチドッグによりハードウェアの再起動を行うことは重要度が高い。すなわち、パソコン等は人が再起動できるが、監視装置では人が不在なので、確実な再起動が必要となる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００１−１７７６５７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記のようにウォッチドッグによる動作監視・管理はシステムの正常動作継続に有効であるが、一般的にウォッチドッグへのタイマクリア信号の生成はＣＰＵのメインプロセスにより実行される。従来のアセンブラ等の言語でソフトウェアが記述された単純な構造のシステムであれば、ソフトウェアが停止した際にはＣＰＵのメインプロセスも合わせて停止するため、ウォッチドッグが異常を検出する事が出来た。
【００１２】
しかし、Ｌｉｎｕｘ(登録商標)等の組込みＯＳを利用したシステムの場合、ＯＳやアプリケーションプロセス、ハード制御ドライバ等のアプリケーションが停止した場合でもＣＰＵのメインプロセスは動作を続けることが出来る。そのため、ＯＳや個別のプロセス、ドライバが停止した場合でも、ＣＰＵのメインプロセスからタイマクリア信号が生成され続け、ウォッチドッグによるハードウェアの再起動が行われない恐れがある。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、ウォッチドッグによる再起動機能を有した監視通報装置において、個別のアプリケーションプロセスやハード制御ドライバの状態を一括管理するプロセスコントロールを設け、プロセスコントロールは、個別のアプリケーションプロセスやハード制御ドライバの動作確認を行ない、ウォッチドッグによる再起動機能を制御する構成とする。
【発明の効果】
【００１４】
本発明によれば、監視通報装置の異常発生時に、異常の発生個所に関わらずウォッチドッグによる監視通報装置の再起動を実施することができる。
【図面の簡単な説明】
【００１５】
【図１】本実施例における監視通報装置のシステム全体の構成図である。
【図２】組込みＯＳシステムのソフトウェア階層構造の模式図である。
【図３】本実施例におけるプロセス停止検出時の処理の内容を示す図である。
【図４】本実施例におけるプロセス復旧実行時の処理の内容を示す図である。
【図５】本実施例におけるハードウェアの再起動実行時の処理の内容を示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施例を図面を用いて説明する。
【００１７】
図１に本実施例における監視通報装置のウォッチドッグによる再起動機能を有したシステム全体の構成を示す。図1において、監視通報装置は、ＣＰＵ１００、ウォッチドッグとして機能するリセットＩＣ２００と、ハードウェア３００からなる。また、ＣＰＵ１００内には、ＣＰＵ１００上にて動作する、ＯＳ１２０、プロセスコントロール１１０、プロセス・ドライバであるハード制御ドライバ１３０、通報プロセス１４０、データ集計プロセス１５０がある。
【００１８】
図２に、ＣＰＵ１００上で動作する、組込みＯＳシステムのソフトウェア階層構造の模式図を示す。組込みＯＳを利用したシステムの場合、ＯＳやアプリケーションが停止した場合でもＣＰＵのメインプロセスであるファームウェアは動作を続けることが出来る。そのためＯＳやアプリケーションが停止した場合でも、ファームウェアからタイマクリア信号が生成され続け、ウォッチドッグによるハードウェアの再起動が行われない恐れがある。
【００１９】
本実施例では、アプリケーション層の個別のアプリケーションプロセスやハード制御ドライバの状態を一括管理するプログラムであるプロセスコントロール１１０を設け、そのロセスコントロール１１０に、ウォッチドック回路へのタイマクリア信号に相当する生存パルスを出力する機能を設けたことで、異常の発生個所に関わらずウォッチドッグによる監視通報装置の再起動を実施することができる。
【００２０】
具体的な動作としては、ＣＰＵ１００上にて動作するプロセスコントロール１１０は、ハード制御ドライバ１３０、通報プロセス１４０、データ集計プロセス１５０からインクリメントカウンタによる個々の生存信号を受信し、動作確認を行ない、一纏めにした生存信号として、全てのプロセス・ドライバの生存信号が確認出来た場合、すなわち、全てのプロセス・ドライバの動作が確認されている場合にのみ、生存パルスをＯＳ１２０へ送信する。ＯＳ１２０はプロセスコントロール１１０より受取った生存パルスを、リセットＩＣ２００へＣＰＵ１００の端子を経由して送信する。
【００２１】
ウォッチドッグとして機能するリセットＩＣ２００は、ＣＰＵ１００から受信する生存パルスをタイマクリア信号として認識する。一定時間生存パルスの受信が無い場合には、ＣＰＵ１００及びハードウェア３００へリセット信号を送信する。
【００２２】
なお、生存信号としてインクリメントカウンタを用いて説明したが、動作しているかどうかが判別できればよいので、例えば、０，１の信号でもよい。  
図３にプロセス停止検出時の処理の内容を示す。ハードウェア３００が異常の場合には、ハード制御ドライバ１３０からプロセスコントロール１１０へのインクリメントカウンタによる生存信号が停止する。プロセスコントロール１１０は、ハード制御ドライバ１３０からの生存信号が停止したことにより、ＯＳ１２０への生存パルスの出力を停止する。これによりＯＳ１２０からリセットＩＣ２００への生存パルスの出力も停止する。
【００２３】
また、プロセスコントロール１１０はデータ集計プロセス１５０へデータの退避命令を送信する。これは、突発的なシステム停止が行われると、通報用に収集しているデータの保存が正常に行われず欠損が生じる恐れがあるため、可能な限りシステム停止前にデータの退避処理を行えることが望ましいためである。なお、このデータ退避処理は、揮発領域に保持しているデータを不揮発領域に退避を行うことが望ましい。
【００２４】
図４にプロセス復旧実行時の処理の内容を示す。ハード制御ドライバ１３０からの生存信号の停止を検出したプロセスコントロール１１０は、ハード制御ドライバ１３０に対してプロセスの再起動処理を実行する。
【００２５】
プロセスの再起動処理によりハード制御ドライバ１３０からの生存信号が復旧した場合には、プロセスコントロール１１０はＯＳ１２０への生存パルスの出力を再開する。これによりＯＳ１２０からリセットＩＣ２００への生存パルスの出力も再開される。
【００２６】
プロセスの再起動処理を実施してもハード制御ドライバ１３０からの生存信号が復旧しない場合、プロセスコントロール１１０は定期的にハード制御ドライバ１３０へのプロセスの再起動処理を実施する。
【００２７】
なお、図３において、プロセス停止検出時にデータの退避命令によりデータ退避処理を実施したが、本再起動処理と並行して退避処理を行っても良い。なお、データの保護を考えると退避処理を再起動処理より先に行うのが望ましい。
【００２８】
図５にハードウェアの再起動実行時の処理の内容を示す。リセットＩＣ２００に設定された時間以内に生存パルスが復旧し、リセットＩＣ２００のタイマクリアが行われない場合、リセットＩＣ２００は設定されたリセット実行時間経過後にＣＰＵ２００とハードウェア３００にリセット信号を出力し、監視通報装置のハードウェアの再起動を実施する。
【００２９】
このように、本実施例では、個別のアプリケーションプロセスとハード制御ドライバの状態を一括管理するプログラムに、ウォッチドック回路へのタイマクリア信号を出力する機能を設けたことで、異常の発生個所に関わらずウォッチドッグによる監視通報装置の再起動を実施することができる。言い換えれば、組込みＯＳを利用したシステムにおいても、プロセスやＯＳ、ＣＰＵの異常検出信号を１系統に纏めてウォッチドッグのタイマクリア信号に集約することで、システム異常時に確実なハードウェアの再起動を行うことが出来る。
【００３０】
また、監視通報装置のハードウェアの再起動実施前に異常プロセス単体の再起動を試みることで、通報装置の再起動による無監視状態の発生を減少させることが出来る。
【００３１】
また、ウォッチドッグによる監視通報装置のハードウェアの再起動実施前にデータの退避処理を実行することで、データの欠損を防ぐことが出来る。
【００３２】
以上実施例について説明したが、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【符号の説明】
【００３３】
１００：ＣＰＵ、１１０：プロセスコントロール、１２０：ＯＳ、
２００：リセットＩＣ、３００：ハードウェア、１３０：ハード制御ドライバ、
１４０：通報プロセス、１５０：データ集計プロセス
【図１】
0006401507.tif 000002
【図２】
0006401507.tif 000003
【図３】
0006401507.tif 000004
【図４】
0006401507.tif 000005
【図５】
0006401507.tif 000006