(57)【要約】      （修正有）【課題】  大きな補助記憶容量を必要とせずに、運用ソフトウェアを自動的に再インストールすること。【解決手段】  運用ソフトウェア１１８は分割データ１〜ｎから構成されているが、ｎ台のプログラマブルコントローラ１００それぞれには、それら分割データ１〜ｎが分散格納されるようにした。この状態で、例えば、分割データｘが格納されているプログラマブルコントローラ１００で、再インストールが必要となれば、そのプログラマブルコントローラ１００からの要求により、他のプログラマブルコントローラ１００からは、分割データ１〜ｎ（分割データｘを除く）がそのプログラマブルコントローラ１００に転送される。したがって、それら分割データ１〜ｎ（分割データｘを除く）と分割データｘからは運用ソフトウェア１１８が復元され得、再インストールを行えることになる。【選択図】  図１
2005266939.tif 000002
【特許請求の範囲】
【請求項１】
運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、ｎ（ｎ：一般に、２以上の整数）台のプログラマブルコントローラ相互間で、該運用ソフトウェアを入替えするためのソフトウェア自動入替え方法であって、プログラマブルコントローラそれぞれに設けられている分散格納用補助記憶エリアには、運用ソフトウェアがｎ分割された際での、ｎ個の運用ソフトウェア部分それぞれが予め分散格納されることで、プログラマブルコントローラそれぞれでは、動作チェック結果が不良であることを契機として、運用ソフトウェアの再インストールが行われるソフトウェア自動入替え方法。
【請求項２】
請求項１に記載のソフトウェア自動入替え方法において、上記ｎ台のプログラマブルコントローラそれぞれは同一グループ内に所属し、かつ広域内に分散設置された状態で、ネットワークを介し相互接続されるソフトウェア自動入替え方法。
【請求項３】
請求項１、または２に記載のソフトウェア自動入替え方法において、上記プログラマブルコントローラそれぞれでは、自プログラマブルコントローラに分散格納されている運用ソフトウェア部分と、他プログラマブルコントローラそれぞれから収集された運用ソフトウェア部分とから復元される運用ソフトウェアが、運用ソフトウェア格納用補助記憶エリア上に格納されることによって、運用ソフトウェアの再インストールが行われるソフトウェア自動入替え方法。
【請求項４】
運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、ｎ（ｎ：一般に、２以上の整数）台のプログラマブルコントローラ相互間で、該運用ソフトウェアを、更新、あるいはバージョンアップされたものと入替えするためのソフトウェア自動入替え方法であって、上記プログラマブルコントローラの何れかで、運用ソフトウェアの更新、あるいはバージョンアップが行われたことに伴い、他プログラマブルコントローラそれぞれでも、運用ソフトウェアの更新、あるいはバージョンアップが行われるソフトウェア自動入替え方法。
【請求項５】
請求項４に記載のソフトウェア自動入替え方法において、上記ｎ台のプログラマブルコントローラそれぞれは同一グループ内に所属し、かつ広域内に分散設置された状態で、ネットワークを介し相互接続されるソフトウェア自動入替え方法。
【請求項６】
請求項４、または５に記載のソフトウェア自動入替え方法において、運用ソフトウェアの更新、あるいはバージョンアップが行われたプログラマブルコントローラでの動作チェック結果が良であることを条件として、該プログラマブルコントローラにより、プログラマブルコントローラそれぞれに設けられている分散格納用補助記憶エリアには、更新、あるいはバージョンアップされた運用ソフトウェアがｎ分割された際での、ｎ個の運用ソフトウェア部分それぞれが分散格納されるソフトウェア自動入替え方法。
【請求項７】
請求項６に記載のソフトウェア自動入替え方法において、上記運用ソフトウェアの更新、あるいはバージョンアップが行われたプログラマブルコントローラ以外のプログラマブルコントローラそれぞれでは、自プログラマブルコントローラに分散格納されている運用ソフトウェア部分と、自プログラマブルコントローラ以外のプログラマブルコントローラそれぞれから収集された運用ソフトウェア部分とから構成される、更新、あるいはバージョンアップされた運用ソフトウェアが、運用ソフトウェア格納用補助記憶エリア上に格納されることによって、運用ソフトウェアの更新、あるいはバージョンアップが行われるソフトウェア自動入替え方法。
【請求項８】
請求項４、または５に記載のソフトウェア自動入替え方法において、運用ソフトウェアの更新、あるいはバージョンアップが行われたプログラマブルコントローラでの動作チェック結果が不良であることを条件として、該プログラマブルコントローラでは、自プログラマブルコントローラに分散格納されている、更新前、あるいはバージョンアップ前の運用ソフトウェア部分と、他プログラマブルコントローラそれぞれから収集された、更新前、あるいはバージョンアップ前の運用ソフトウェア部分とから復元される運用ソフトウェアが、運用ソフトウェア格納用補助記憶エリア上に格納されることによって、運用ソフトウェアの再インストールが行われるソフトウェア自動入替え方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、複数台のプログラマブルコントローラ相互間で、その運用ソフトウェアが自動的に再インストールされたり、更には、何れかのプログラマブルコントローラで運用ソフトウェアが更新、あるいはバージョンアップされた場合には、残りのプログラマブルコントローラでも運用ソフトウェアが自動的に、更新、あるいはバージョンアップされるようにしたソフトウェア自動入替え方法に関する。
【背景技術】
【０００２】
一般に、プログラマブルコントローラは、小型、かつディスクやファン等の機械的な駆動部がなく、耐環境性に優れており、また、連続稼動がその特徴として挙げられる。この特徴を活かすように、これまでにも、集中的に設置されている、監視制御対象としての各種設備を分散監視制御するのに用いられている。更に、近年では、広域分散システム上での遠隔地であって、かつ人間が容易に行けない場所に分散設置された上、各種設備を監視制御するのにも用いられており、その監視制御の一環として、各種データがプログラマブルコントローラそれぞれにより収集されるようになっている。
【０００３】
また、プログラマブルコントローラには、オペレーティングシステム（ＯＳ）や各種のアプリケーション等、様々なソフトウェアがインストールされており、これらソフトウェアが実行されることで、特定の処理が遂行されている。その際、新たなソフトウェアを追加するインストールや、インストール済みソフトウェアを更新するバージョンアップも、必要に応じて、随時、行われるようになっている。
【０００４】
ところで、プログラマブルコントローラ一般では、ソフトウェア実行中に、それに対応する補助記憶上のファイルが書き換わることがないように、当該ファイルにロックをかけている。このため、動作中には、該当ソフトウェアのバージョンアップは不可能となる。ＯＳも動作中には入れ替えることが不可なファイルの１つである。
【０００５】
因みに、特許文献１には、ＯＳを入替える場合、まずネットワークに接続されたサーバからセットアッププログラム（ＯＳ）をダウンロードして、現行ＯＳとは異なるセットアッププログラムで立ち上げ直し、そのセットアッププログラム下で新ＯＳをダウンロードして、書き換えを行うことが記載されている。
【特許文献１】特開平１０―１３３８６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、特許文献１に記載されているような、旧ソフトウェアを上書きするプログラマブルコントローラシステムでのソフトウェア入れ替え方法では、入れ替えた新ソフトウェアに不具合がある場合や、入替え途中で失敗した場合には、元に戻せないという不具合がある。また、入れ替えたОＳで障害が発生した場合は、ネットワークも利用不可となる場合もあり得、そのような場合には、プログラマブルコントローラの設置場所まで赴き、ＯＳを入れ直さなければならなかった。
【０００７】
旧ソフトウェアを上書きすることによる不具合を解決するには、旧ソフトウェアを上書きすることなく、別エリアに格納させる方法が考えられる。しかし、この方法による場合、別エリアが新たに必要とされ、その分、大きな容量の補助記憶装置が新たに必要とされるから、システム全部の入れ替えでは、２倍の容量の補助記憶装置が必要となる。
【０００８】
本発明の目的は、運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、複数台のプログラマブルコントローラ相互間で、プログラマブルコントローラそれぞれに大きな補助記憶容量を必要とすることなく、動作チェック不良の場合には、運用ソフトウェアが自動的に再インストールされ得るソフトウェア自動入替え方法を提供することにある。
また、本発明の目的は、何れかのプログラマブルコントローラで運用ソフトウェアが更新、あるいはバージョンアップされた場合には、残りのプログラマブルコントローラでも、運用ソフトウェアが自動的に、更新、あるいはバージョンアップされ得るソフトウェア自動入れ替え方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明によるソフトウェア自動入替え方法は、運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、ｎ（ｎ：一般に、２以上の整数）台のプログラマブルコントローラ相互間で、該運用ソフトウェアを入替えするための方法であり、プログラマブルコントローラそれぞれに設けられている分散格納用補助記憶エリアには、運用ソフトウェアがｎ分割された際での、ｎ個の運用ソフトウェア部分それぞれが予め分散格納されることで、プログラマブルコントローラそれぞれでは、動作チェック結果が不良であることを契機として、運用ソフトウェアの再インストールが行われるようにしたものである。具体的に、プログラマブルコントローラそれぞれでは、自プログラマブルコントローラに分散格納されている運用ソフトウェア部分と、他プログラマブルコントローラそれぞれから収集された運用ソフトウェア部分とから復元される運用ソフトウェアが、運用ソフトウェア格納用補助記憶エリア上に格納されることによって、運用ソフトウェアの再インストールが行われるようにした。
【００１０】
また、本発明によるソフトウェア自動入替え方法は、運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、ｎ（ｎ：一般に、２以上の整数）台のプログラマブルコントローラ相互間で、該運用ソフトウェアを、更新、あるいはバージョンアップされたものと入替えするためのソフトウェア自動入替え方法であって、上記プログラマブルコントローラの何れかで、運用ソフトウェアの更新、あるいはバージョンアップが行われたことに伴い、他プログラマブルコントローラそれぞれでも、運用ソフトウェアの更新、あるいはバージョンアップが行われるようにしたものである。具体的には、運用ソフトウェアの更新、あるいはバージョンアップが行われたプログラマブルコントローラでの動作チェック結果が良であることを条件として、該プログラマブルコントローラにより、プログラマブルコントローラそれぞれに設けられている分散格納用補助記憶エリアには、更新、あるいはバージョンアップされた運用ソフトウェアがｎ分割された際での、ｎ個の運用ソフトウェア部分それぞれが分散格納されるようにした。
【００１１】
したがって、運用ソフトウェアの更新、あるいはバージョンアップが行われたプログラマブルコントローラ以外のプログラマブルコントローラそれぞれでは、自プログラマブルコントローラに分散格納されている運用ソフトウェア部分と、自プログラマブルコントローラ以外のプログラマブルコントローラそれぞれから収集された運用ソフトウェア部分とから構成される、更新、あるいはバージョンアップされた運用ソフトウェアが、運用ソフトウェア格納用補助記憶エリア上に格納されることによって、運用ソフトウェアの更新、あるいはバージョンアップが可能とされる。しかし、運用ソフトウェアの更新、あるいはバージョンアップが行われたプログラマブルコントローラでの動作チェック結果が不良である場合には、そのプログラマブルコントローラでは、自プログラマブルコントローラに分散格納されている、更新前、あるいはバージョンアップ前の運用ソフトウェア部分と、他プログラマブルコントローラそれぞれから収集された、更新前、あるいはバージョンアップ前の運用ソフトウェア部分とから復元される運用ソフトウェアが、運用ソフトウェア格納用補助記憶エリア上に格納されることによって、元の運用ソフトウェアへの復帰が可能とされているものである。
【発明の効果】
【００１２】
本発明によるソフトウェア入替え方法によれば、運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、複数台のプログラマブルコントローラ相互間で、プログラマブルコントローラそれぞれに大きな補助記憶容量を必要とすることなく、動作チェック不良の場合には、運用ソフトウェアが自動的に再インストールされ得、また、何れかのプログラマブルコントローラで運用ソフトウェアが更新、あるいはバージョンアップされた場合には、残りのプログラマブルコントローラでも、運用ソフトウェアが自動的に、更新、あるいはバージョンアップされ得る。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の一実施の形態について説明する。
まず本発明に係るプログラマブルコントローラの構成態様について説明する。その構成態様としては各種のものが考えられるが、一例として、ネットワーク上で分散監視制御用として使用される場合での構成態様を図２に示す。図示のように、複数の同一構成のプログラマブルコントローラ１００は同一グループ２００内のものとして、また、その運用ソフトウェアが同一として、ネットワーク（ＬＡＮ（Local Area Network）やインターネット等）３００を介して相互に接続された上、その配下におかれている設備４００がプログラマブルコントローラ１００により監視制御されている。グループ２００内のプログラマブルコントローラ１００相互間では、データの授受や状態監視が行われているが、このような事情は、グループ２００以外の他のグループ（図示せず）でも同様であり、グループ相互間もネットワーク３００を介して、接続可能となっている。本発明は、同一グループ２００内における複数のプログラマブルコントローラ１００相互間において、プログラマブルコントローラそれぞれでの補助記憶容量を徒に増大させることなく、その運用ソフトウェアを自動的に再インストールしたり、その運用ソフトウェアを自動的に、更新、あるいはバージョンアップする方法を提供しようというものである。
【００１４】
そのプログラマブルコントローラ１００の一例の概要構成を図３に示す。図示のように、プログラマブルコントローラ１００には、主記憶装置１０１と補助記憶装置１０２が備えられている。このうち、補助記憶装置１０２には、セットアップ用ＯＳ１０３や運用ＯＳ１０４、アプリケーション１０５、ＯＳを起動するブートローダ１１６が格納されており、ブートローダ１１６が、運用ＯＳ１０４，セットアップ用ＯＳ１０３のうち、何れを選択的に起動するかは、起動フラグ１１７の状態如何によっている。補助記憶装置１０２にはまた、分割データ１０６が格納されている。ここにいう分割データ１０６とは、運用ソフトウェア（運用ＯＳ１０４及びアプリケーション１０５）１１８全体を複数に分割した場合での、１つの運用ソフトウェア部分とされる。例えば、グループ内にプログラマブルコントローラ１００が４台あるとすれば、運用ソフトウェア１１８は４分割されることで、４つの運用ソフトウェア部分が生成されるが、これら４つの運用ソフトウェア部分それぞれが分割データとして、４台のプログラマブルコントローラ１００に対し、予め所定に割当て格納される。
【００１５】
さて、主記憶装置１０１については後述することにして、ここで、本発明の概要について説明しておく。まず運用ソフトウェアの再インストールについて説明する。グループ内にプログラマブルコントローラ１００がｎ台あるとすれば、運用ソフトウェア１１８はｎ分割されることで、ｎ個の運用ソフトウェア部分が生成されるが、これらｎ個の運用ソフトウェア部分それぞれが分割データとして、ｎ台のプログラマブルコントローラ１００に対し、所定に割当て格納されるが、この割当て格納状態を図１に示す。
【００１６】
図１に示すように、運用ソフトウェア１１８は分割データ１〜ｎから構成されているが、ｎ台のプログラマブルコントローラ１００それぞれには、それら分割データ１〜ｎが分散格納されていることが判る。このような状態で、分割データｘが格納されているプログラマブルコントローラ１００で、運用ソフトウェア１１８の再インストールが必要となったとすれば、そのプログラマブルコントローラ１００からの要求により、他のプログラマブルコントローラ１００からは、分割データ１〜ｎ（分割データｘを除く）がそのプログラマブルコントローラ１００に転送されるようになっている。したがって、それら分割データ１〜ｎ（分割データｘを除く）と分割データｘからは運用ソフトウェア１１８が復元され得、再インストールを行えるものである。このような事情は、他のプログラマブルコントローラ１００で、運用ソフトウェア１１８の再インストールが必要となった場合でも同様である。
【００１７】
また、例えば、分割データｘが格納されているプログラマブルコントローラ１００で、その運用ソフトウェア１１８がネットワークを介して、更新（あるいはバージョンアップ）された場合を想定すれば、更新済み運用ソフトウェア１１８´もｎ分割された上、ｎ個の分割データとして、ｎ台のプログラマブルコントローラ１００に対し、所定に割当て格納される。この割当て格納状態を図４に示す。
【００１８】
したがって、図５に示すように、分割データｙが格納されているプログラマブルコントローラ１００で運用ソフトウェア１１８が更新される場合には、そのプログラマブルコントローラ１００からの要求により、他のプログラマブルコントローラ１００からは、分割データ１〜ｎ（分割データｙを除く）がそのプログラマブルコントローラ１００に転送されるようにすればよい。それら分割データ１〜ｎ（分割データｘを除く）と分割データｙからは更新済み運用ソフトウェア１１８´が構成され得ることから、運用ソフトウェア１１８が更新が可能となる。このような更新動作は、他のプログラマブルコントローラ１００でも同様であり、それまでの運用ソフトウェア１１８が容易に、しかも、自動的に更新されることになる。
【００１９】
以上、本発明の概要について説明した。ここで、図３に戻り、主記憶装置１０１について説明すれば、この主記憶装置１０１には、以下の各種手段がソフトウェアとして格納されており、他には、フラグや各種の管理テーブルが設定されている。
・ブートローダによるＯＳ起動手段１２６：プログラマブルコントローラ１００自体の電源ＯＮ、あるいはプログラマブルコントローラ１００を再起動した際に、補助記憶装置１０２に格納されているブートローダ１１６によりＯＳの起動処理を行う。
・起動フラグセット手段１２０：ブートローダによるＯＳの起動手段１２６により起動されるＯＳを選択する。
・動作モードフラグ１１９：プログラマブルコントローラ１００の現在の動作モードを示す。
・動作モードセット手段１２１：その動作モードフラグ１１９を設定する。
・動作モード判別手段１２２：その動作モードフラグ１１９を参照して、現在の動作モードを判別する。
【００２０】
・ソフトウェア分割格納手段１０７：運用ソフトウェア１１８を、複数のプログラマブルコントローラ１００内の補助記憶装置１０２に分割された状態として格納する。
・分割管理テーブル１１５：その運用ソフトウェア１１８の、複数のプログラマブルコントローラ１００それぞれへの分割格納状態を管理する。
・バージョン管理テーブル１１４：運用ソフトウェア１１８のインストール及びバージョンアップ情報を管理する。
・ソフトウェア取得手段１０８：バージョン管理テーブル１１４及び分割管理テーブル１１５に基づき、運用ソフトウェア１１８のインストール、またはバージョンアップに必要とされる、分割された状態にある運用ソフトウェアを、各プログラマブルコントローラ１００から取得する。
・ソフトウェア転送手段１２５：ソフトウェア取得手段１０８による、他プログラマブルコントローラ１００からのソフトウェア取得要求を受け付け、分割された状態にある運用ソフトウェアを要求元プログラマブルコントローラに転送する。
・ソフトウェア復元手段１０９：取得された複数の、分割された状態にある運用ソフトウェアを纏まった運用ソフトウェア１１８として復元する。
【００２１】
・セットアップ起動手段１１０：運用ソフトウェア１１８のインストール、またはバージョンアップ要求を受け付け、インストール、またはバージョンアップ処理を起動する。
・システム再起動手段１１１：運用ソフトウェア１１８のインストール、またはバージョンアップ後に、その運用ソフトウェア１１８で再立ち上げを行う。
・動作チェック手段１１２：再起動後の動作健全性をチェックし、動作が正常か、異常かを判断する。
・再セットアップ起動手段１１３：動作チェック手段１１２により異常と判断された場合に、再度ソフトウェアのインストールを行う。
・ソフトウェア更新手段１２７：同一グループ内のプログラマブルコントローラ１００の運用ソフトウェア１１８のインストール、またはバージョンアップ処理を起動する。
・ソフトウェア更新指示手段１２３：同一グループ内のプログラマブルコントローラ１００に対し、運用ソフトウェア１１８のインストール、またはバージョンアップ処理を指示する。
・ソフトウェア更新指示受信手段１２４：ソフトウェア更新指示手段１２３からのソフトウェア更新指示を受け付け、運用ソフトウェア１１８のインストール、またはバージョンアップ処理を起動する。
【００２２】
以上、本発明に係るプログラマブルコントローラについて説明した。ここで、そのプログラマブルコントローラでの、ソフトウェア入替えを含む処理の一例でのフローについて説明する。この処理のフローを、図６を参照しつつ、説明すれば、以下のようである。
すなわち、プログラマブルコントローラ自体の電源がＯＮ、あるいはプログラマブルコントローラが再起動されると、図７に示すように、ブートローダによるＯＳの起動手段１２６によりＯＳの起動処理が開始される。まず起動手段１２６により起動フラグ１１７が参照されることで、起動されるべきＯＳが決定される（ステップＳ２０１）。この起動フラグ１１７は、その状態が起動フラグセット手段１２０により設定されているが（ステップＳ２５１）、何れにしても、その起動フラグ１１７の設定状態が運用ＯＳを示している場合には、起動フラグ１１７をセットアップ用ＯＳに設定した上（ステップＳ２０２）、運用ＯＳ１０４が起動される（ステップＳ２０４）。
【００２３】
運用ＯＳ１０４が起動されると、図８に示すように、動作チェック手段１１２により動作チェックが行われる。この動作チェックの結果がＯＫである場合は、図９に示すように、動作モード判別手段１２２により、動作モードフラグ１１９が参照されることで、動作モードが判別される。この動作モードフラグ１１９は、その状態が動作モードセット手段１２１により設定されているが（ステップＳ３５１）、何れにしても、動作モードが通常モードである場合には、図７に示すように、起動フラグセット手段１２０により起動フラグ１１７の状態は運用ＯＳとなるように設定された上、通常運用におかれる。
【００２４】
一方、動作チェック手段１１２による動作チェックの結果がＮＧである場合は、図１０に示すように、再セットアップ起動手段１１３が実行される。再セットアップ起動手段１１３は、起動フラグセット手段１２０をして、起動フラグ１１７の状態がセットアップ用ＯＳになるように設定し、図１１に示すように、システム再起動手段１１１をして、再起動前処理を行わせた上（ステップＳ８０１）、プログラマブルコントローラの再起動を行う（ステップＳ８０２）。プログラマブルコントローラが再起動されると、ブートローダによるＯＳの起動手段１２６は起動フラグ１１７を参照の上、ＯＳを起動するが、この場合、起動フラグ１１７の状態はセットアップ用ＯＳに設定されているので、セットアップ用ＯＳ１０３が起動される。セットアップ用ＯＳ１０３が起動されると、図９に示すように、動作モード判別手段１２２により動作モードが判別される。
【００２５】
その判別の結果、動作モードが通常モードであるか、更新中モードである場合には、図１２に示すように、ソフトウェア取得手段１０８により分割管理テーブル１１５を参照して、分割データが格納されているプログラマブルコントローラが分割データ要求先として取得された上（ステップＳ４０１）、これらプログラマブルコントローラには分割データ転送要求が送信される（ステップＳ４０２）。それらプログラマブルコントローラそれぞれでは、その分割データ転送要求が受信されれば（ステップＳ４０３）、その応答として、分割データ要求元プログラマブルコントローラに対しては、分割データが送信される（ステップＳ４０４）。これにより、分割データ要求元プログラマブルコントローラでは、分割データ要求先プログラマブルコントローラそれぞれから送信された分割データが受信される（ステップＳ４０５）。
【００２６】
そして、分割データを受信したプログラマブルコントローラでは、図１３に示すように、ソフトウェア復元手段１０９により分割データの復元処理が行われ（ステップＳ７０１）、復元されたデータ、即ち、運用ソフトウェアが運用ソフトウェア格納用補助記憶エリアに格納されることによって、運用ソフトウェア１１８の再インストールが行われる（ステップＳ７０２）。この再インストールが完了すると、起動フラグセット手段１２０により起動フラグ１１７が運用ＯＳに設定された上、システム再起動手段１１１によりプログラマブルコントローラは再起動される。プログラマブルコントローラが再起動されると、ブートローダによるＯＳの起動手段１２６により運用ＯＳ１０４が起動される。その後、動作チェック手段１１２による動作チェックの結果がＮＧである場合には、既述の方法で再セットアップが実行される。しかし、その動作チェックの結果がＯＫである場合は、動作モード判別手段により動作モードを判別し、通常モードである場合は、起動フラグセット手段１２０により起動フラグ１１７は運用ＯＳに設定された上、通常運用におかれる。以上のように、動作チェックの結果がＮＧである場合には、運用ソフトウェアの再インストールが自動的に行われている。
【００２７】
次に、運用ソフトウェアが更新、あるいはバージョンアップされる場合について説明すれば、以下のようである。
すなわち、運用ソフトウェアを更新、あるいはバージョンアップするには、まずグループ内の1台のプログラマブルコントローラ（ソフトウェア更新指示元、分割データ更新指示元、あるいは分割データ更新マスタに該当）に対して、更新、あるいはバージョンアップされた運用ソフトウェアが、例えばネットワークを介して、インストールされるようになっている。その後、そのプログラマブルコントローラは再起動された後、動作チェック手段１１２により動作チェックが行われる。もしも、その動作チェックの結果がＮＧである場合には、再セットアップ起動手段１１３が実行されることで、更新前、あるいはバージョンアップ前の運用ソフトウェアの再インストールが行われるようにする。
【００２８】
一方、動作チェックの結果がＯＫである場合は、図１４に示すように、ソフトウェア更新手段１２７が実行される。ソフトウェア更新手段１２７は、図９に示すように、動作モードセット手段１２１により動作モードフラグ１１９を更新マスタモードに設定し、次いで、起動フラグセット手段１２０により起動フラグ１１７をセットアップ用ＯＳに設定し、その後は、システム再起動手段１１１によりプログラマブルコントローラが再起動される。プログラマブルコントローラが再起動されると、ブートローダによるＯＳの起動手段１２６によりセットアップ用ＯＳ１０３が起動される。セットアップ用ＯＳが起動されると、動作モード判別手段１２２により動作モードが判別される。この場合、動作モードは更新マスタモードであるので、図１５に示すように、ソフトウェア分割格納手段１０７が実行される。
【００２９】
ソフトウェア分割格納手段１０７は、分割管理テーブル１１５上から分割データ更新対象プログラマブルコントローラを外し（ステップＳ５０１）、まず自身での分割データを更新した上（ステップＳ５０２）、分割データ更新対象プログラマブルコントローラそれぞれに分割データを送信する（ステップＳ５０３）。分割データ更新対象プログラマブルコントローラそれぞれでは、分割データ更新マスタプログラマブルコントローラから送信された分割データを受信した上（ステップＳ５０４）、分割データの更新を行う（ステップＳ５０５）。このようにして、全ての分割データ更新対象プログラマブルコントローラでの分割データの更新が完了したならば、分割データ管理テーブル１１５は、それら分割データ更新対象プログラマブルコントローラそれぞれが分割データを持つという内容に更新される（ステップＳ５０６）。そして、動作モードセット手段１２１によりグループ内の全プログラマブルコントローラの動作モードフラグを更新中モードに設定し、次いで、起動フラグセット手段１２０により起動フラグ１１７を運用ＯＳに設定し、その後は、システム再起動手段１１１により分割データ更新マスタプログラマブルコントローラが再起動される。
【００３０】
分割データ更新マスタプログラマブルコントローラが再起動されると、ブートローダによるＯＳの起動手段１２６により運用ＯＳが起動される。その後、動作チェック手段１１２により動作チェックが行われるが、万が一、動作チェックの結果がＮＧである場合は、既述の方法、すなわち、再セットアップ起動手段１１３により再セットアップ処理が行われる。この時点では、全てのプログラマブルコントローラでの分割データは、既に、更新、あるいはバージョンアップされた運用ソフトウェアのものとされるから、更新、あるいはバージョンアップされた運用ソフトウェアが再インストールされることになる。
【００３１】
一方、動作チェックの結果がＯＫである場合には、動作モード判別手段１２２により動作モードが判別されるが、更新中モードである場合は、図１６に示すように、ソフトウェア更新指示手段１２３が実行される。ソフトウェア更新指示手段１２３は、グループ内の他のプログラマブルコントローラに動作モードフラグの問い合せを行い（ステップＳ６０１）、その問い合せを受けたプログラマブルコントローラでは、その応答として、動作モード判別手段により動作モードが判別された上、分割データ更新指示元プログラマブルコントローラに動作モードフラグが返送される（ステップＳ６０２）。そのソフトウェア更新指示先プログラマブルコントローラからの動作モードフラグが更新中モードでないと判断された場合は（ステップＳ６０３）、ソフトウェア更新指示先プログラマブルコントローラを変更して（ステップＳ６０４）、動作モードフラグの問い合せを出す。また、ソフトウェア更新指示先プログラマブルコントローラからの返送が更新中モードである場合は、ソフトウェア更新指示先プログラマブルコントローラにはソフトウェア更新指示を出し（ステップＳ６０５）、次いで、動作モードセット手段１２１により動作モードフラグ１１９を通常モードに設定し、その後、起動フラグセット手段１２０により起動フラグ１１７は運用ＯＳに設定された上、通常運用におかれる。
【００３２】
一方、ソフトウェア更新指示を受けたソフトウェア更新指示先プログラマブルコントローラでは、図１７に示すように、セットアップ起動手段１１０が実行される。この実行により、起動フラグセット手段１２０により起動フラグ１１７がセットアップ用ＯＳに設定され、次いで、システム再起動手段１１１により再起動が行われる。このように、ソフトウェア更新指示先プログラマブルコントローラが再起動されると、ブートローダによるＯＳの起動手段１２６によりセットアップ用ＯＳが起動され、既述の方法で運用ソフトウェアの更新、あるいはバージョンアップを行い、運用ＯＳ１０４で再起動が行われる。運用ＯＳ１０４で起動されたプログラマブルコントローラは、動作チェック手段１１２によりその動作がチェックされるが、その動作チェック結果がＮＧである場合は、既述の方法で再セットアップが行われ、更新、あるいはバージョンアップされた運用ソフトウェアが再インストールされる。また、動作チェックの結果がＯＫである場合には、動作モード判別手段１２２により動作モードが判別される。この場合、動作モードは更新中モードであるので、既述の方法でソフトウェア更新指示が出される。以下、同様にして、グループ内の全プログラマブルコントローラでの運用ソフトウェアの更新、バージョンアップが行われる。
【００３３】
以上、説明したように、本発明による場合には、運用ＯＳ及びアプリケーションを共通の運用ソフトウェアとする、複数台のプログラマブルコントローラ相互間では、プログラマブルコントローラそれぞれに大きな補助記憶容量を必要とすることなく、動作チェック不良の場合には、運用ソフトウェアが自動的に再インストールされ得、また、何れかのプログラマブルコントローラで運用ソフトウェアが更新、あるいはバージョンアップされた場合には、残りのプログラマブルコントローラでも、運用ソフトウェアが自動的に、更新、あるいはバージョンアップされ得る。特に、最初に運用ソフトウェアが更新、あるいはバージョンアップされたプログラマブルコントローラでは、動作チェックの結果が不良である場合に、元の運用ソフトウェア、すなわち、更新前、あるいはバージョンアップ前の運用ソフトウェアがインストールされており、更新前、あるいはバージョンアップ前の状態に復帰可能となっている。
【００３４】
以上、本発明者によってなされた発明を実施の形態に基づき、具体的に説明したが、本発明は上記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変更可能であることはいうまでもない。
【図面の簡単な説明】
【００３５】
【図１】運用ソフトウェアの再インストール方法の概要を示す図である。
【図２】本発明に係るプログラマブルコントローラの一例での構成態様を示す図である。
【図３】そのプログラマブルコントローラの一例の概要構成を示す図である。
【図４】あるプログラマブルコントローラ１００で運用ソフトウェアが更新された場合での、分割データのプログラマブルコントローラそれぞれへの割当て格納状態を示す図である。
【図５】あるプログラマブルコントローラでの運用ソフトウェアの更新に伴う、他のプログラマブルコントローラでの運用ソフトウェアの更新方法の概要を示す図である。
【図６】本発明に係るプログラマブルコントローラでの、ソフトウェア入替えを含む処理の一例でのフローを示す図である。
【図７】ブートローダによるＯＳの起動処理を示す図である。
【図８】動作チェック手段による動作チェック処理を示す図である。
【図９】動作モード判別手段による動作モード判別処理を示す図である。
【図１０】再セットアップ起動手段による処理のフローを示す図である。
【図１１】システム再起動手段による処理のフローを示す図である。
【図１２】ソフトウェア取得手段、ソフトウェア転送手段それぞれでの処理のフローを示す図である。
【図１３】ソフトウェア復元手段による処理のフローを示す図である。
【図１４】ソフトウェア更新手段による処理のフローを示す図である。
【図１５】ソフトウェア分割格納手段による処理のフローを示す図である。
【図１６】ソフトウェア更新指示手段及びソフトウェア更新指示受信手段による処理のフローを示す図である。
【図１７】セットアップ起動手段による処理のフローを示す図である。
【符号の説明】
【００３６】
１００…プログラマブルコントローラ、１０１…主記憶装置、１０２…補助記憶装置、１０３…セットアップ用ＯＳ、１０４…運用ＯＳ、１０５…アプリケーション、１０６…分割データ、１１８…運用ソフトウェア、１１８´…更新済み運用ソフトウェア、３００…ネットワーク
【図１】
2005266939.tif 000003
【図２】
2005266939.tif 000004
【図３】
2005266939.tif 000005
【図４】
2005266939.tif 000006
【図５】
2005266939.tif 000007
【図６】
2005266939.tif 000008
【図７】
2005266939.tif 000009
【図８】
2005266939.tif 000010
【図９】
2005266939.tif 000011
【図１０】
2005266939.tif 000012
【図１１】
2005266939.tif 000013
【図１２】
2005266939.tif 000014
【図１３】
2005266939.tif 000015
【図１４】
2005266939.tif 000016
【図１５】
2005266939.tif 000017
【図１６】
2005266939.tif 000018
【図１７】
2005266939.tif 000019