(57)【要約】【課題】ＯＳを搭載したオプションモジュール自身の異常検出に、ウォッチドックタイマによる異常監視を確実、容易にする。【解決手段】オペレーティングシステム（ＯＳ）を搭載したオプションモジュール２の異常を、ハードウェア構成のウォッチドックタイマ３０で監視するため、オプションモジュールの起動から通常動作状態に入るまでの起動処理時間がウォッチドックタイマのタイマ値よりも長い時間を要する起動処理に、ウォッチドックタイマの動作をソフトウェア的に一時停止させる。  ウォッチドックタイマのタイマ値を、起動処理が完了するまでに必要な時間以上にソフトウェア的に変更することも含む。【選択図】図１
2008040698.tif 000002
【特許請求の範囲】
【請求項１】
オペレーティングシステムを搭載したオプションモジュールの異常を、ハードウェア構成のウォッチドックタイマで監視するプログラマブルコントローラの異常監視方式であって、
前記オプションモジュールの起動から通常動作状態に入るまでの起動処理時間が前記ウォッチドックタイマのタイマ値よりも長い時間を要する起動処理に、前記ウォッチドックタイマの動作をソフトウェア的に一時停止させる手段を備えたことを特徴とするプログラマブルコントローラの異常監視方式。
【請求項２】
オペレーティングシステムを搭載したオプションモジュールの異常を、ハードウェア構成のウォッチドックタイマで監視するプログラマブルコントローラの異常監視方式であって、
前記オプションモジュールの起動から通常動作状態に入るまでの起動処理時間が前記ウォッチドックタイマのタイマ値よりも長い時間を要する起動処理に、前記ウォッチドックタイマのタイマ値を、該起動処理が完了するまでに必要な時間以上にソフトウェア的に変更する手段を備えたことを特徴とするプログラマブルコントローラの異常監視方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラマブルコントローラの異常監視方式に係り、特にオペレーティングシステム（ＯＳ）を搭載したオプションモジュールの異常監視方式に関する。
【背景技術】
【０００２】
プログラマブルコントローラ（以下、ＰＬＣと呼ぶ）は、複数モジュールの集積でシステムを構築し、例えば図４にシステム構成例を示すように、管理ＣＰＵであるＣＰＵモジュール１と、監視制御を行うＷｅｂモジュール２が実装され、Ｗｅｂサイトを利用した監視や制御を可能にする。Ｗｅｂモジュール２はＰＬＣシステムのオプションモジュールになる。
【０００３】
オプションモジュールの異常監視方式としては、オプションモジュールにウォッチドックタイマ（ＷＤＴ）機能を実装し、オプションモジュール自身が暴走していないか監視を行うようにしている。ウォッチドックタイマ機能とは、モジュールが一定時間以内に定期的にウォッチドックタイマのリトリガ処理を行わなくなった場合に、ウォッチドックタイマがタイムアップして、モジュールのハードウェアの異常を検出する仕組みである。
【０００４】
オプションモジュールでウォッチドックタイマの異常が発生した場合、この異常をバス経由でＣＰＵモジュール１に通知する機能もバス上に実装しておき、ＣＰＵモジュール１が他のオプションモジュールの異常検出も行うものもある（例えば、特許文献１参照）。
【特許文献１】特開２００２−１６３００８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
一般に、ＰＬＣのオプションモジュールは、ＯＳレスに構成されており、システム起動時のセットアップ処理時や起動時の診断処理時などでも、プログラムで自由にウォッチドックタイマのリトリガ処理を行い、ウォッチドックタイマのタイムアップが発生しない仕組みとされている。
【０００６】
監視制御を行うＷｅｂモジュールでもウォッチドックタイマ機能を実装して、オプションモジュール自身が暴走していないか監視を行う場合、ＯＳを搭載した下記の仕様になるＷｅｂモジュールでは従来のウォッチドックタイマのハードウェア機能そのものでは問題がある。
【０００７】
・ＷｅｂモジュールはＯＳとしてＬｉｎｕｘ（登録商標）を採用し、Ｂｏｏｔ処理（システムの起動処理）もＬｉｎｕｘに対応したＢｏｏｔを採用する。
【０００８】
・Ｗｅｂモジュールには、メモリ・記憶領域としてフラッシュメモリとＳＤＲＡＭを実装する。
【０００９】
・Ｌｉｎｕｘには一般のオプションモジュールよりメモリ容量を多く必要とする。
【００１０】
・Ｌｉｎｕｘは、Ｂｏｏｔ処理実行後でなければ起動できない。
【００１１】
・組み込みＬｉｎｕｘでは、図５にイメージで示すように、圧縮されたカーネルイメージ（ＯＳの基本機能を実装したソフトウェアファイル）を予めフラッシュメモリに格納しておき、起動時に自己解凍を行い、ＲＡＭ上で動作させる。
【００１２】
・ＬｉｎｕｘではＯＳ起動後に、各アプリケーションソフトウェア、例えばＡｐａｃｈｅ（登録商標）などを起動させる。
【００１３】
上記仕様を踏まえて、ウォッチドックタイマ機能を実現するためには、下記の問題がある。
【００１４】
・組み込みＬｉｎｕｘでは、圧縮されたカーネルイメージを予めフラッシュメモリに格納して、起動時に自己解凍を行い、ＲＡＭ上で動作させているが、自己解凍時はウォッチドックタイマのリトリガ処理を実行できない。
【００１５】
・ＬｉｎｕｘではＯＳ起動後に、ｉｎｉｔプロセスから各ランレベル毎にアプリケーションソフトウェア（Ａｐａｃｈｅなど）を起動させているが、各アプリケーションの起動待ち時に、ウォッチドックタイマのリトリガ処理を実行できない。
【００１６】
・カーネルのソースファイルは公開されているので、ソース上にウォッチドックタイマのリトリガ処理を追加することは可能であるが、カーネルに新たに追加するためには、Ｌｉｎｕｘの動作全てを理解した上で、タイムアップが発生しないよう追加する必要があるが、この方式は現実的にはかなり難しい。また、カーネルがバージョンアップされた場合に、バージョンアップに対応できない可能性があり、オープンソフトウェアのメリットを享受できない。
【００１７】
本発明の目的は、ＯＳを搭載したオプションモジュール自身の異常検出に、ウォッチドックタイマによる異常監視を確実、容易にするプログラマブルコントローラの異常監視方式を提供することにある。
【課題を解決するための手段】
【００１８】
本発明は、前記の課題を解決するため、ＯＳを搭載したオプションモジュールのハードウェアとして、電源投入時から常に起動されていたウォッチドックタイマをソフトウェア的に起動／停止できる手段を設け、またはウォッチドックタイマのタイマ値をソフトウェア的に変更できる手段を設け、ウォッチドックタイマのタイマ値よりも長い時間を要する処理におけるウォッチドックタイマの誤った異常検出を防止するものであり、以下の方式を特徴とする。
【００１９】
（１）オペレーティングシステムを搭載したオプションモジュールの異常を、ハードウェア構成のウォッチドックタイマで監視するプログラマブルコントローラの異常監視方式であって、
前記オプションモジュールの起動から通常動作状態に入るまでの起動処理時間が前記ウォッチドックタイマのタイマ値よりも長い時間を要する起動処理に、前記ウォッチドックタイマの動作をソフトウェア的に一時停止させる手段を備えたことを特徴とする。
【００２０】
（２）オペレーティングシステムを搭載したオプションモジュールの異常を、ハードウェア構成のウォッチドックタイマで監視するプログラマブルコントローラの異常監視方式であって、
前記オプションモジュールの起動から通常動作状態に入るまでの起動処理時間が前記ウォッチドックタイマのタイマ値よりも長い時間を要する起動処理に、前記ウォッチドックタイマのタイマ値を、該起動処理が完了するまでに必要な時間以上にソフトウェア的に変更する手段を備えたことを特徴とする。
【発明の効果】
【００２１】
以上のとおり、本発明によれば、ＯＳを搭載したオプションモジュールのハードウェアとして、電源投入時から常に起動されていたウォッチドックタイマをソフトウェア的に起動／停止できる手段を設け、またはウォッチドックタイマのタイマ値をソフトウェア的に変更できる手段を設け、ウォッチドックタイマのタイマ値よりも長い時間を要する処理におけるウォッチドックタイマの誤った異常検出を防止するため、オプションモジュール自身の異常検出に、ウォッチドックタイマによる異常監視が確実、容易になる。
【００２２】
また、カーネルのソース上にウォッチドックタイマのリトリガ処理を追加する必要がなくなり、Ｌｉｎｕｘの動作全てを理解した上で、タイムアップが発生しないようリトリガ処理を追加する必要がなく、カーネルがバージョンアップされた場合に、カーネルのソースファイルを入れ替えることが可能で、オープンソフトウェアのメリットを享受できる。
【００２３】
また、Ｌｉｎｕｘ上のＷｅｂアプリケーションでウォッチドックリトリガ処理を実行するので、ＬｉｎｕｘのＧＰＬライセンスに抵触しないため、ウォッチドックタイマによる異常監視の実施が容易になる。
【発明を実施するための最良の形態】
【００２４】
（実施形態１）
図１は本実施形態になるＰＬＣシステムの構成図であり、図４と同等のものは同一符号で示す。Ｗｅｂモジュール２は、ハードウェア的にはマイクロコンピュータ１０とメモリ２０で構成され、ＣＰＵモジュール１とはバス結合される。マイクロコンピュータ１０にはＯＳとしてＬｉｎｕｘを組み込み、Ｌｉｎｕｘで装備するＢｏｏｔ処理、圧縮カーネル、アプリケーションなどのソフトウェアを搭載する。
【００２５】
本実施形態では、組み込みＬｉｎｕｘを採用したＷｅｂモジュールで、ウォッチドックタイマ機能を実現するために、下記機能を実現するハードウェア機能を新たに設ける。
【００２６】
モジュール電源投入時から常に起動されていたハードウェアのウォッチドックタイマ３０をソフトウェアから起動／停止できる機能を設ける。この新たな機能によりＷｅｂモジュール２のソフトウェアはウォッチドックタイマ３０による異常監視を行う箇所と行わない箇所を設定可能にする。
【００２７】
例えば、圧縮されたカーネルイメージを自己解凍するときやｉｎｉｔプロセスからアプリケーションソフトウェアを起動して待ち状態のときは、ソフトウェアからウォッチドックタイマ３０を停止させることにより、Ｌｉｎｕｘのカーネルソフトウェアにウォッチドックタイマのリトリガ処理を追加することなく、Ｌｉｎｕｘ上でウォッチドックタイマ機能を実現できる。
【００２８】
図２はウォッチドックタイマ機能のソフトウェア処理例を示す。ＰＬＣシステムの電源を投入したとき（Ｓ１）、マイコン１０ではＢｏｏｔ処理を起動する（Ｓ２）。この起動処理に際してウォッチドックタイマ機能を起動させる。次いで、マイコンのセットアップを行う（Ｓ３）。このセットアップ中には、ウォッチドックタイマ機能を動作中にして異常監視を行う。
【００２９】
次に、メモリ診断とデバイス診断と圧縮カーネル解凍とＯＳ起動およびアプリケーションソフトウェア起動の各処理中（Ｓ４〜Ｓ８）には、ウォッチドックタイマ機能を一時停止させておく。これら処理の終了で通常動作状態に入ったとき（Ｓ９）、Ｗｅｂアプリケーション起動時にウォッチドックタイマ機能を再起動させ、ウォッチドックタイマ機能による異常監視を行う。
【００３０】
以上のように、本実施形態では、Ｗｅｂモジュール２のハードウェアとして、電源投入時から常に起動されていたウォッチドックタイマ機能にソフトウェアから起動・停止できる機能を設ける。この機能によりＷｅｂモジュールのソフトウェアはウォッチドックによる異常監視を行う処理機能と行わない処理機能を設定できる。
【００３１】
すなわち、メモリ診断・デバイス診断・圧縮カーネルイメージ解凍・ＯＳ起動・アプリケーションソフトウェア起動状態のときは、ソフトウェアからウォッチドックタイマ機能を停止させることにより、Ｌｉｎｕｘのカーネルソフトウェアにウォッチドックタイマのリトリガ処理を追加することなく、Ｌｉｎｕｘ上でウォッチドックタイマ機能を実現できる。
【００３２】
また、カーネルのソース上にウォッチドックタイマのリトリガ処理を追加する必要がなくなり、ＬｉｎｕＸの動作全てを理解した上で、タイムアップが発生しないようリトリガ処理を追加する必要がなく、カーネルがバージョンアップされた場合に、カーネルのソースファイルを入れ替えることが可能で、オープンソフトウェアのメリットを享受できる。
【００３３】
（実施形態２）
本実施形態は、組み込みＬｉｎｕｘを採用したＷｅｂモジュールで、ウォッチドックタイマ機能を実現するために、実施形態１から更に下記機能を追加変更する。
【００３４】
モジュール電源投入時から常に起動されていたハードウェアのウォッチドックタイマ３０にソフトウェアからウォッチドックタイマのタイマ値を変更できる機能を設ける。この新たな機能によりＷｅｂモジュール２のソフトウェアは、ＯＳの起動時など時間を要する箇所では、ウォッチドックタイマのタイマ値を変更することができる。これによりＷｅｂモジュール２は常にウォッチドックタイマ機能による異常監視が実行されている状態となる。
【００３５】
例えば、圧縮されたカーネルイメージを自己解凍時するときやｉｎｉｔプロセスからアプリケーションソフトウェアを起動して待ち状態のときは、ウォッチドックタイマ機能のタイマ値を大きくすることで、ウォッチドックタイマ機能を停止させず、またＬｉｎｕｘのカーネルソフトウェアにウォッチドックタイマのリトリガ処理を追加することなく、Ｌｉｎｕｘ上でウォッチドックタイマ機能を実現できる。
【００３６】
図３はウォッチドックタイマ機能のソフトウェア処理例を示す。ＰＬＣシステムの電源を投入したとき（Ｓ１）、マイコン１０ではＢｏｏｔ処理を起動する（Ｓ２）。この起動処理に際してウォッチドックタイマ機能を起動させる。次いで、マイコンのセットアップを行う（Ｓ３）。このセットアップ中には、ウォッチドックタイマ機能を動作中にして異常監視を行う。
【００３７】
次に、メモリ診断処理の実行時には（Ｓ４）、ウォッチドックタイマ機能のタイマ値を変更し、メモリ診断中はリトリガ処理を不要とする。メモリ診断完了後にウォッチドックタイマ機能のタイマ値を標準値に戻す。
【００３８】
デバイス診断処理の実行時には（Ｓ５）、ウォッチドックタイマ機能のタイマ値を変更し、デバイス診断中はリトリガ処理を不要とする。リトリガ処理を実行後、ウォッチドックタイマ機能のタイマ値を圧縮カーネル解凍とＯＳ起動およびアプリケーションソフトウェア起動の各処理が完了するまでに必要な時間にタイマ値を変更し、以後の処理（Ｓ６〜Ｓ８）にはウォッチドックタイマ機能を動作させておく。
【００３９】
これら処理の終了で通常動作状態に入ったとき（Ｓ９）、Ｗｅｂアプリケーション起動時にウォッチドックタイマ機能を再起動させ、ウォッチドックタイマ機能による異常監視を行う。
【００４０】
以上のように、本実施形態では、モジュールのハードウェア機能として、電源投入時から常に起動されているウォッチドックタイマ機能のタイマ値をソフトウェアから変更できる機能を設ける。この新たな機能によりＷｅｂモジュールのソフトウェアは処理に時間を要する箇所ではタイマ値を変更して常にウォッチドックタイマ機能が動作している状態を実現できる。
【００４１】
すなわち、メモリ診断・デバイス診断・圧縮カーネルイメージ解凍・ＯＳ起動・アプリケーションソフトウェア起動状態のときは、ソフトウェアからウォッチドックタイマ機能のタイマ値を変更させることにより、ウォッチドックタイマ機能を停止させることなく、またＬｉｎｕｘのカーネルソフトウェアにウォッチドックタイマのリトリガ処理を追加することなく、Ｌｉｎｕｘ上でウォッチドックタイマ機能を実現できる。
【００４２】
また、カーネルのソース上にウォッチドックタイマのリトリガ処理を追加する必要がなくなり、ＬｉｎｕＸの動作全てを理解した上で、タイムアップが発生しないようリトリガ処理を追加する必要がなく、カーネルがバージョンアップされた場合に、カーネルのソースファイルを入れ替えることが可能で、オープンソフトウェアのメリットを享受できる。
【図面の簡単な説明】
【００４３】
【図１】本発明の実施形態を示すＰＬＣシステムの構成図。
【図２】ウォッチドックタイマ機能のソフトウェア処理例（実施形態１）。
【図３】ウォッチドックタイマ機能のソフトウェア処理例（実施形態２）。
【図４】ＰＬＣシステムの構成図。
【図５】Ｌｉｎｕｘにおける圧縮されたカーネルイメージの解凍例。
【符号の説明】
【００４４】
１  ＣＰＵモジュール
２  Ｗｅｂモジュール
１０  マイコン
２０  メモリ
３０  ウォッチドックタイマ
【図１】
2008040698.tif 000003
【図２】
2008040698.tif 000004
【図３】
2008040698.tif 000005
【図４】
2008040698.tif 000006
【図５】
2008040698.tif 000007