(57)【特許請求の範囲】
【請求項１】
互いに状態監視を行い、一方が稼働系となり、他方が待機系となる２つのコントローラと、
前記２つのコントローラのうちの一方とＩＯ機器との間のデータ通信を仲介する第１のリモート入出力マスタと、
前記２つのコントローラのうちの他方と前記ＩＯ機器との間のデータ通信を仲介する第２のリモート入出力マスタと、
前記第１および第２のリモート入出力マスタと前記ＩＯ機器とが接続されるリモートバスと、を備え、
前記２つのコントローラの各々は、
自装置と同じ系のリモート入出力マスタに再稼働を指示する際に、バスマスタとして機能することを指示する片系立ち上げ通知を送信し、
前記第１および第２のリモート入出力マスタの各々は、再稼働の指示とともに前記片系立ち上げ通知を受信した場合に、他方のリモート入出力マスタとの調停を行わずに前記リモートバスのバスマスタとなって稼働を開始する
ことを特徴とする制御システム。
【請求項２】
前記２つのコントローラの各々は、
前記第１および第２のリモート入出力マスタの再稼働を行う際に、何れか一方の再稼働を優先させる制御を行う
ことを特徴とする請求項１に記載の制御システム。
【請求項３】
前記２つのコントローラの各々は、
前記第１および第２のリモート入出力マスタのうち、稼働系となっているコントローラに接続されている方の再稼働を優先させる
ことを特徴とする請求項１または請求項２に記載の制御システム。
【請求項４】
互いに状態監視を行い、一方が稼働系となり、他方が待機系となる２つのコントローラと、
前記２つのコントローラのうちの一方とＩＯ機器との間のデータ通信を仲介する第１のリモート入出力マスタと、
前記２つのコントローラのうちの他方と前記ＩＯ機器との間のデータ通信を仲介する第２のリモート入出力マスタと、
前記２つのコントローラの各々は、
前記第１のリモート入出力マスタと前記第２のリモート入出力マスタの再稼働を行う際に、何れか一方の再稼働を優先させる制御を行う
ことを特徴とする制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、産業施設に設置される各種機器の作動制御を行う制御システムに関する。
【背景技術】
【０００２】
この種の制御システムの一例としては、プロセスオートメーション（以下、ＰＡ）を実現するための制御システムが挙げられる。ＰＡとは、石油精製や製鉄など所謂素材産業における製品製造工程の自動化のことを言う。より詳細に説明すると、この種の製品製造工程には順次実行される複数のプロセスが含まれており、ＰＡとは、各プロセスにおける材料等の温度や圧力、流量を自動制御することをいう。ＰＡ用の制御システムは、各プロセスにおける材料等の温度や圧力、流量の自動制御を実現するためのコンピュータシステムである。この制御システムには、材料の温度等を計測するためのセンサやその計測結果に応じて材料の流量を調整するポンプ等の各種ＩＯ機器、それらＩＯ機器からの計測データの収集およびその収集結果に基づくＩＯ機器の作動制御のための演算を行うコントローラ、さらに、両者のデータ通信を仲介するリモート入出力マスタ等が含まれている。
【０００３】
制御システムによりＰＡが実現されると、制御システムの故障停止は製品の品質や生産効率に大きく影響する。そこで、制御システムの故障停止をできる限り回避するため、ＰＡ用の制御システムでは、各種機器の冗長化が行われることが多い。例えばコントローラとしてＡ系とＢ系の２つのコントローラを設けるコントローラ冗長化構成を採用すれば、コントローラの故障に起因する制御システムの故障停止を回避することができる。Ａ系のコントローラを稼働系、Ｂ系のコントローラを待機系として動作させている状況下で、Ａ系のコントローラに故障が発生しても、稼働系をＢ系に切り換えて処理を引き継ぐことで、制御システムの稼働を継続することができるからである。また、コントローラだけでなくリモート入出力マスタも冗長化する構成を採用すれば、リモート入出力マスタの故障に起因する制御システムの故障停止を回避することが可能になる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−２５４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
コントローラとリモート入出力マスタとをＡ系とＢ系とで冗長化した制御システムであっても、リモート入出力マスタに動作電力を供給する電源については冗長化されていない場合がある。この種の制御システムにおいて両系のリモート入出力マスタに動作電力を供給する電源が故障した場合には、両系においてリモート入出力マスタをコントローラに再接続して制御システムを復旧することになるが、この復旧の際に以下のような問題が発生する場合がある。
【０００６】
リモート入出力マスタは、コントローラとの接続を確立するのと同時に、ペアとなるリモート入出力マスタとＩＯ機器とを認識する立ち上げ処理を実行する。この立ち上げ処理に要する時間は、リモート入出力マスタに接続されるＩＯ機器が多いほど長くなる。そして、立ち上げ処理に要する時間が長くなるほど、制御システム全体の再稼働が遅れ、生産性が低下する。また、コントローラ及びリモート入出力マスタのハードウェアとしてのばらつきや設置環境に起因する外乱等によってＡ系の復旧に要する時間とＢ系の復旧に要する時間に差が生じる場合があり、従来の冗長化制御システムでは、上記時間差を吸収するためにリモート入出力マスタの立ち上げの際に一定の待ち合わせ時間が設けられていることが多い。しかし、このような待ち合わせ時間を設けると、その待ち合わせ時間の分だけ、制御システム全体の再稼働が遅れ、やはり生産性が低下する。
【０００７】
待ち合わせ時間の廃止もしくは短縮を行えば、待ち合わせ時間に起因する生産性の低下を回避することができるが、以下のような問題が生じる。例えば、待機系の立ち上げが先行するケースにおいて制御システム全体が復旧した際に稼働系／待機系の切り換えが発生する。一般に冗長化制御システムの運用管理では、稼働系／待機系の切り換えが発生した場合にその発生要因の特定が行われるが、上記のような切り換えは本来的には不必要な切り換えであり、その切り換え要因の特定に要する作業コストは全くの無駄である。システム復旧の際に常に稼働系の復旧を優先させるなど、復旧手順を工夫すれば、このような無駄な作業コストの発生を回避できるが、復旧手順が煩雑になるといった問題がある。
【０００８】
本発明は以上に説明した課題に鑑みて為されたものであり、コントローラとリモート入出力マスタとを冗長化した制御システムにおいて、システム復旧の際の復旧手順の煩雑化を招くことなく、制御システムが再稼働可能になるまでに要する時間を短縮する技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本発明は、以下の構成の制御システムを提供する。この制御システムは、互いに状態監視を行い、一方が稼働系となり、他方が待機系となる２つのコントローラと、これら２つのコントローラのうちの一方とＩＯ機器との間のデータ通信を仲介する第１のリモート入出力マスタと、上記２つのコントローラのうちの他方と上記ＩＯ機器との間のデータ通信を仲介する第２のリモート入出力マスタと、第１および第２のリモート入出力マスタと上記ＩＯ機器とが接続されるリモートバス、を含んでいる。つまり、上記制御システムは、コントローラとリモート入出力マスタとが２系統に冗長化された制御システムである。上記２つのコントローラの各々は、自装置と同じ系に属するリモート入出力マスタに再稼働を指示する際に、バスマスタとして機能することを指示する片系立ち上げ通知を送信する。そして、第１および第２のリモート入出力マスタの各々は、再稼働の指示とともに片系立ち上げ通知を受信した場合に、他方のリモート入出力マスタとの調停を行うことなく上記リモートバスのバスマスタとなって稼働を開始する。
【００１０】
本発明によれば、第１のリモート入出力マスタと第２のリモート入出力マスタのうち再稼働が先行する方が自動的にバスマスタとなり、当該リモート入出力マスタの属する系統では、コントローラとＩＯ機器との間のデータ通信を再開可能な状態、すなわち、制御システムとしての稼働が可能な状態となる。このため、片系のみでの稼働を許容するようにすれば、制御システムの稼働再開までの時間を従来よりも短縮することが可能になる。なお、第１および第２のリモート入出力マスタのうち、再稼働が遅れる方については、他方がバスマスタとなっているため、スレーブとして再稼働させるようにすれば良いことは言うまでもない。また、本発明によれば、片系立ち上げを指示するために制御システムの運用管理者が特別な作業を行う必要はなく、システム復旧の際の復旧手順が煩雑化することもない。
【００１１】
特許文献１には、リモートＩ／Ｏユニット、すなわち、本発明におけるリモート入出力マスタ、の各部に動作電力を供給する電源モジュールの故障に備えて外部電源モジュールを設けることが記載されている。しかし、特許文献１には、コントローラとリモート入出力マスタとが冗長化された制御システムにおいて両系のリモート入出力マスタを再稼働させる際に片系立ち上げを行うことについての記載はない。つまり、本願発明は特許文献１に開示の技術とは異なる技術である。
【００１２】
より好ましい態様においては、上記２つのコントローラの各々は、第１および第２のリモート入出力マスタの再稼働を行う際に、何れか一方の再稼働を優先させる制御を行う。このような態様によれば、前述した待ち合わせ時間を設ける必要がなくなり、制御システムが再稼働可能になるまでに要する時間を短縮することが可能になる。また、何れか一方のリモート入出力マスタの再稼働を優先させる制御が上記２つのコントローラによって自動的に行われるため、システム復旧の際の復旧手順が煩雑化することも無い。さらに、稼働系の再稼働を優先させるようにすれば、両系の再稼働が完了した時点で不要な稼働系／待機系の切り換えが発生することも無い。
【００１３】
また、上記課題を解決するために本発明は以下の構成の制御システムを提供する。この制御システムも、互いに状態監視を行い、一方が稼働系となり、他方が待機系となる２つのコントローラと、一方のコントローラとＩＯ機器との間のデータ通信を仲介する第１のリモート入出力マスタと、他方のコントローラと当該ＩＯ機器との間のデータ通信を仲介する第２のリモート入出力マスタと、を含んでいる。つまり、この制御システムも、コントローラとリモート入出力マスタとが冗長化された制御システムである。本発明の制御システムは、上記２つのコントローラに以下の制御を行わせることを特徴とする。すなわち、上記２つのコントローラの各々は、第１のリモート入出力マスタと第２のリモート入出力マスタの再稼働を行う際に、何れか一方の再稼働を優先させる制御を行う。
【００１４】
この制御システムにおいても前述した待ち合わせ時間を設ける必要がなく、制御システムが再稼働可能になるまでに要する時間を短縮することができる。また、稼働系の再稼働を優先させるようにすれば、稼働系および待機系の両方の再稼働が完了した時点で不要な稼働系／待機系の切り換えが発生することを回避できる。このように、コントローラとリモート入出力マスタとが冗長化された制御システムにおいて両系のリモート入出力マスタを再稼働させる際に何れか一方の再稼働を優先させることは特許文献１には記載されておらず、本願発明は特許文献１に開示の技術とは異なる技術である。
【発明の効果】
【００１５】
本発明によれば、コントローラとリモート入出力マスタとを冗長化した制御システムにおいて、システム復旧の際の復旧手順の煩雑化を招くことなく、制御システムが再稼働可能になるまでに要する時間を短縮することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態の制御システム１の構成例を示す図である。
【図２】同制御システム１に含まれるコントローラ１０の構成例を示す図である。
【図３】従来のコントローラの故障復旧処理における状態遷移を示す図である。
【図４】コントローラ１０の故障復旧処理における状態遷移を示す図である。
【図５】同制御システム１に含まれるリモート入出力マスタ３０の構成例を示す図である。
【図６】従来のリモート入出力マスタが実行するイニシャル処理の流れを示すフローチャートである。
【図７】リモート入出力マスタ３０が実行するイニシャル処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、図面を参照しつつ本発明の実施形態を説明する。
図１は、本発明の一実施形態の制御システム１の構成例を示す図である。制御システム１は、ＰＡ用のコンピュータシステムである。制御システム１では、コントローラとリモート入出力マスタとがＡ系およびＢ系の２つの系統で冗長化されている。図１では、コントローラ１０ＡがＡ系のコントローラであり、コントローラ１０ＢがＢ系のコントローラである。コントローラ１０ＡはＩＯネットワーク８０Ａに接続されており、コントローラ１０ＢはＩＯネットワーク８０Ｂに接続されている。ＩＯネットワーク８０Ａには、Ａ系のリモート入出力マスタであるリモート入出力マスタ３０Ａ＿１とリモート入出力マスタ３０Ａ＿２が接続されている。同様に、ＩＯネットワーク８０Ｂには、Ｂ系のリモート入出力マスタであるリモート入出力マスタ３０Ｂ＿１とリモート入出力マスタ３０Ｂ＿２が接続されている。
【００１８】
リモート入出力マスタ３０Ａ＿１とリモート入出力マスタ３０Ｂ＿１はリモートバス９０＿１に接続されており、リモートバス９０＿１にはＩＯ機器４０＿１とＩＯ＿機器５０＿１が接続されている。ＩＯ機器４０＿１およびＩＯ機器５０＿１の各々は例えばコントローラによる駆動制御の下で駆動するポンプ等の電動機、或いは温度等を計測しその計測値を示す計測データを出力するセンサである。リモート入出力マスタ３０Ａ＿１は、電源６０＿１からの電力の供給を受け、ＩＯ機器４０＿１或いはＩＯ機器５０＿１とコントローラ１０Ａとの間のデータ通信を仲介する中継装置である。同様に、リモート入出力マスタ３０Ｂ＿１も、電源６０＿１から電力の供給を受け、ＩＯ機器４０＿１或いはＩＯ機器５０＿１とコントローラ１０Ｂとのデータ通信を仲介する中継装置である。本実施形態では、リモート入出力マスタ３０Ａ＿１およびリモート入出力マスタ３０Ｂ＿１の各々に対して、共通の電源、すなわち、電源６０＿１から動作電力を供給したが、各々別個の電源から動作電力を供給しても良い。
【００１９】
リモート入出力マスタ３０Ａ＿２とリモート入出力マスタ３０Ｂ＿２はリモートバス９０＿２に接続されており、リモートバス９０＿２にはＩＯ機器４０＿２とＩＯ＿機器５０＿２が接続されている。ＩＯ機器４０＿２およびＩＯ機器５０＿２の各々も、ＩＯ機器４０＿１やＩＯ機器５０＿１と同様に電動機やセンサである。リモート入出力マスタ３０Ａ＿２は、電源６０＿２からの電力の供給を受け、ＩＯ機器４０＿２或いはＩＯ機器５０＿２とコントローラ１０Ａとの間のデータ通信を仲介する中継装置である。同様に、リモート入出力マスタ３０Ｂ＿２も、電源６０＿２から電力の供給を受け、ＩＯ機器４０＿２或いはＩＯ機器５０＿２とコントローラ１０Ｂとのデータ通信を仲介する中継装置である。なお、リモート入出力マスタ３０Ａ＿２およびリモート入出力マスタ３０Ｂ＿２についても、各々別個の電源により動作電力を供給するようにしても良い。
【００２０】
コントローラ１０Ａおよびコントローラ１０Ｂは何れもＤＣＳ（Distributed
Control System：分散型制御システム或いは分散型制御装置）である。コントローラ１０Ａは、電源６０Ａからの電力の供給を受け、ＩＯ機器から受信した計測データを用いて電動機の作動制御等を行うための演算を、予めインストールされたアプリケーションプログラムにしたがって実行する。同様に、コントローラ１０Ｂは、電源６０Ｂからの電力の供給を受け、ＩＯ機器から受信した計測データを用いて電動機の作動制御等を行うための演算を、予めインストールされたアプリケーションプログラムにしたがって実行する。詳細については後述するが、コントローラ１０Ａとコントローラ１０Ｂのハードウェア構成は同一である。以下では、コントローラ１０Ａとコントローラ１０Ｂの各々を区別する必要がない場合には「コントローラ１０」と表記する。リモート入出力マスタ３０Ａ＿ｎ（ｎ＝１または２）およびリモート入出力マスタ３０Ｂ＿ｎについても同様に各々を区別する必要がない場合には「リモート入出力マスタ３０」と表記する。
【００２１】
図１に示すようにコントローラ１０Ａとコントローラ１０Ｂは等値化ケーブル７０に接続されている。等値化ケーブル７０は、コントローラ１０Ａとコントローラ１０Ｂの間のデータ通信を仲介するコントローラ間通信手段の役割を果たす。制御システム１では、コントローラ１０Ａとコントローラ１０Ｂのうちの一方が稼働系として振る舞い、他方は待機系として振る舞う。本実施形態では、コントローラ１０Ａとコントローラ１０Ｂのうち先に電源を投入された方が稼働系として振る舞う。
【００２２】
本実施形態では、コントローラ１０Ａとコントローラ１０Ｂの各々は、各々の接続先のＩＯネットワークから受信した計測データを等値化ケーブル７０を介した通信により等値化し、等値化済の計測データを用いて、前述したアプリケーションプログラムにしたがった演算を実行する。そして、各コントローラ１０は、上記演算結果についても等値化ケーブル７０を介した通信により等値化し、稼働系となっている方は、等値化済の演算結果を電動機等へ送信する。ここで、計測データの等値化とは、稼働系のコントローラが受信した計測データで待機系のコントローラが受信した計測データを上書きすることをいい、演算結果の等値化とは待機系における演算結果を稼働系における演算結果で上書きすることを言う。
【００２３】
加えて、コントローラ１０Ａとコントローラ１０Ｂの各々は故障の有無を示す状態データを等値化ケーブル７０を介して他方へ送信する処理を周期的に実行し、互いに稼働状態の監視を行う。そして、稼働系に何らかの故障が発生した場合には、稼働系／待機系の切り換えが行われる。例えば、コントローラ１０Ａが稼働系となっている状況下でコントローラ１０Ｂがコントローラ１０Ａの故障を検知すると、以降、コントローラ１０Ｂは稼働系として振る舞う。一方、コントローラ１０Ａは、等値化ケーブル７０を介して受信した状態データを解析してコントローラ１０Ｂが稼働系としての動作を開始したことを検知すると、以降、待機系として振る舞う。前述した計測データおよび演算結果の等値化を行うのは、稼働系／待機系の切り換えの際に演算結果の突変が発生するのを回避するためである。
【００２４】
制御システム１では、リモート入出力マスタ３０Ａ＿ｎとリモート入出力マスタ３０Ｂ＿ｎは電源６０＿ｎを共有しており、電源６０＿ｎに故障が発生した場合には、当該電源６０＿ｎの修理等を行った後に、リモート入出力マスタ３０Ａ＿ｎをコントローラ１０Ａに再接続するとともにリモート入出力マスタ３０Ｂ＿ｎをコントローラ１０Ｂに再接続する復旧処理を行うことが必要となる。制御システム１では、この復旧処理にてコントローラ１０およびリモート入出力マスタ３０に本実施形態特有の処理を実行させることで、再稼働可能になるまでに要する時間が従来よりも短くなっており、この点に本実施形態の特徴がある。以下、本実施形態の特徴を顕著に示すコントローラ１０およびリモート入出力マスタ３０を中心に説明する。
【００２５】
図２は、コントローラ１０の構成例を示す図である。
コントローラ１０は、図２に示すように、ＩＯネットワーク通信部１１０、コントローラ間通信部１２０、および制御部１３０を有する。以下では、コントローラ１０ＡのＩＯネットワーク通信部１１０とコントローラ１０ＢのＩＯネットワーク通信部１１０とを区別する必要がある場合には、前者を「ＩＯネットワーク通信部１１０Ａ」と表記し、後者を「ＩＯネットワーク通信部１１０Ｂ」と表記する。コントローラ間通信部１２０および制御部１３０についても、コントローラ１０Ａにおけるものとコントローラ１０Ｂにおけるものを区別する必要がある場合には同様の表記とする。
【００２６】
ＩＯネットワーク通信部１１０とコントローラ間通信部１２０は何れもＮＩＣ（Network Interface Card）である。コントローラ間通信部１２０には等値化ケーブル７０が接続されている。コントローラ間通信部１２０は等値化ケーブル７０を介して受信したデータを制御部１３０に引き渡す一方、制御部１３０から引き渡されたデータを等値化ケーブル７０を介して他方のコントローラへ送信する。ここで、他方のコントローラとは、コントローラ１０Ａから見ればコントローラ１０Ｂのことであり、コントローラ１０Ｂから見ればコントローラ１０Ａのことである。
【００２７】
ＩＯネットワーク通信部１１０ＡはＩＯネットワーク８０Ａに接続されており、ＩＯネットワーク通信部１１０ＢはＩＯネットワーク８０Ｂに接続されている。ＩＯネットワーク通信部１１０は、接続先のＩＯネットワークを介して受信したデータを制御部１３０に引き渡す一方、制御部１３０から引き渡されたデータを接続先のＩＯネットワークへ送出する。ＩＯネットワーク通信部１１０がその接続先のＩＯネットワークから受信するデータの具体例としては、各種ＩＯ機器が出力する計測データや各種ＩＯ機器或いはリモート入出力マスタの動作状態を示す状態通知データが挙げられる。また、ＩＯネットワーク通信部１１０がその接続先のＩＯネットワークへ送出するデータの具体例としては各種ＩＯ機器に対する入力データ、すなわち各種ＩＯ機器に与える動作指令や、コントローラ１０の動作状態を自身と同じ系に属するリモート入出力マスタ３０に通知する状態通知データが挙げられる。
【００２８】
制御部１３０はＣＰＵ（Central Processing Unit）と揮発性メモリと不揮発性メモリとを含んでいる（図２では何れも図示略）。不揮発性メモリは例えばＲＯＭ（Read Only M
memory）やフラッシュＲＯＭである。この不揮発性メモリには、コントローラ１０特有の機能を上記ＣＰＵに実現させるためのプログラムであるファームウェアと各種アプリケーションプログラムが予め格納されている。揮発性メモリは例えばＲＡＭ（Random Access Memory）である。この揮発性メモリは上記ファームウェアやアプリケーションプログラムを実行する際のワークエリアとして利用される。また、上記揮発性メモリには、自装置の動作状態を管理するための各種フラグが格納される。揮発性メモリに格納されるフラグの具体例としては、自装置が稼働系として動作しているのか、それとも待機系として動作しているのかを示す稼働／待機フラグや、排他復旧要求フラグおよび排他復旧中フラグが挙げられる。例えば、コントローラ１０が稼働系として動作している場合には、稼働／待機フラグには“１”がセットされ、待機系として動作している場合には“０”がセットされる。なお、排他復旧要求フラグおよび排他復旧中フラグの詳細については後に明らかにする。
【００２９】
上記ファームウェアにしたがってＣＰＵを作動させることで実現される機能の具体例としては、図２に示すアプリケーション実行管理機能１３０１、等値化管理機能１３０２およびシステム管理機能１３０３が挙げられる。アプリケーション実行管理機能１３０１とは、予め定められたスケジュールにしたがって、或いは計測データの示す計測値が所定の閾値に達したなどの予め定められたイベントの発生を契機として、アプリケーションプログラムの実行を開始する等、各種アプリケーションプログラムの実行管理を行う機能である。等値化管理機能１３０２とは、計測データや演算結果データの等値化を行う機能である。そして、システム管理機能１３０３には、これらアプリケーション実行管理機能１３０１および等値化管理機能１３０２を統括的に管理する機能、他方のコントローラおよび自身の状態に応じて稼働／待機の切り換えを行う機能、および自装置に接続されているリモート入出力マスタ３０の故障を検出し、その再立ち上げを行う障害復旧機能が含まれている。
【００３０】
ファームウェアにしたがって制御部１３０のＣＰＵが実行する処理のうち、本実施形態の特徴が顕著に現れるのは障害復旧機能による処理（以下、障害復旧処理）であり、特に、障害復旧処理における状態遷移に本実施形態の特徴が現れる。以下では、本実施形態の特徴の理解を容易にするため、まず、従来のコントローラの障害復旧処理における状態遷移を説明する。
【００３１】
図３は、従来のコントローラの障害復旧処理における状態遷移を示す図である。図３に示すように、障害復旧処理における従来のコントローラの動作状態には、アイドル状態ＳＡ１００と、復旧処理中状態ＳＡ２００の２種類の状態がある。制御システムに含まれる各コントローラは一定周期など定期的に障害復旧処理を実行し、障害復旧処理を開始すると動作状態をアイドル状態ＳＡ１００へと遷移させる。アイドル状態ＳＡ１００では、コントローラは、接続先のＩＯネットワークへの新たなリモート入出力マスタの接続の有無を判定する。以下では、この判定処理のことを「加入判定」と呼ぶ。故障等により停止していたリモート入出力マスタ３０を再起動した場合には、この加入判定により当該再起動されたリモート入出力マスタが検出される。以下では、加入判定により検出されたリモート入出力マスタのことを「復旧対象のリモート入出力マスタ」と呼ぶ。アイドル状態ＳＡ１００にて復旧対象のリモート入出力マスタが無かった場合には、コントローラは今回の障害復旧処理を終了し、アプリケーションプログラム等の実行を行う。
【００３２】
これに対して、復旧対象のリモート入出力マスタが有った場合には、コントローラは、動作状態を復旧処理中状態ＳＡ２００へ遷移させる。復旧処理中状態ＳＡ２００では、コントローラは、復旧対象のリモート入出力マスタに対して中継装置としての動作に必要なパラメータを与える等の立ち上げ処理を実行し、当該リモート入出力マスタからのイニシャル完了通知の受信をもって当該リモート入出力マスタの再稼働完了を検出し、当該リモート入出力マスタについての立ち上げ処理を完了する。復旧対象のリモート入出力マスタが複数ある場合には、コントローラは、それら複数のリモート入出力マスタの各々についての立ち上げ処理をシリアルに実行する。そして、復旧対象のリモート入出力マスタの全てについて立ち上げ処理を完了すると、コントローラは動作状態を復旧処理中状態ＳＡ２００からアイドル状態ＳＡ１００へ遷移させる。
以上が従来のコントローラの障害復旧処理における状態遷移である。
【００３３】
次いで、コントローラ１０の障害復旧処理における状態遷移を説明する。
図４は、コントローラ１０の障害復旧処理における状態遷移を示す図である。図４と図３を対比すれば明らかように、本実施形態の障害復旧処理における状態遷移は、以下の３つの点が従来の障害復旧処理における状態遷移と異なる。第１に、アイドル状態ＳＡ１００に代えてアイドル状態ＳＢ１００を含む点である。第２に復旧処理中状態ＳＡ２００に代えて復旧処理中状態ＳＢ２００を含む点である。そして、第３に、復旧要求中状態ＳＢ１５０と追加復旧局加入待ち状態ＳＢ２５０を含む点である。
【００３４】
アイドル状態ＳＢ１００では、制御部１３０のＣＰＵは、復旧対象のリモート入出力マスタの有無の判定を行う。この点ではアイドル状態ＳＢ１００とアイドル状態ＳＡ１００に相違はない。ただし、アイドル状態ＳＢ１００は、上記加入判定に加えて、本実施形態の障害復旧処理における状態遷移を制御するための２種類のフラグの初期化を含む点がアイドル状態ＳＡ１００と異なる。本実施形態の障害復旧処理における状態遷移を制御するための２種類のフラグとは、前述した排他復旧要求フラグと排他復旧中フラグである。制御部１３０のＣＰＵは、アイドル状態ＳＢ１００への遷移を契機として排他復旧要求フラグと排他復旧中フラグに“０”をセットし、復旧対象のリモート入出力マスタの有無を判定する。復旧対象のリモート入出力マスタを検出すると、制御部１３０のＣＰＵは、動作状態を復旧要求中状態ＳＢ１５０に遷移させる。
【００３５】
復旧要求中状態ＳＢ１５０では、制御部１３０のＣＰＵは、排他復旧要求フラグを“１”に更新し、さらに、復旧対象のリモート入出力マスタの復旧の可否を判定する。復旧対象のリモート入出力マスタの復旧が可能であると判定された場合、コントローラ１０は、動作状態を復旧処理中状態ＳＢ２００へ遷移させる。これに対して、復旧可能ではないと判定された場合には、制御部１３０のＣＰＵは、動作状態を復旧要求中状態ＳＢ１５０のままとし、復旧可能との判定結果が得られるまで、上記判定を定期的に繰り返す。
【００３６】
本実施形態では、復旧対象のリモート入出力マスタの復旧の可否を判定する際の判定基準が稼働系と待機系とで異なり、この点にも本実施形態の特徴が現れている。より詳細に説明すると、稼働系のコントローラ１０では、制御部１３０のＣＰＵは、待機系のコントローラ１０における排他復旧中フラグが“０”である場合に、復旧対象のリモート入出力マスタを復旧可能と判定する。これに対して、待機系のコントローラ１０では、制御部１３０のＣＰＵは、稼働系のコントローラ１０における排他復旧要求フラグと排他復旧中フラグの両者が共に“０”である場合に、復旧対象のリモート入出力マスタを復旧可能と判定する。このように本実施形態では、待機系における判定基準は稼働系における判定基準よりも厳しく、稼働系のリモート入出力マスタの再稼働が優先されることになる。このように、稼働系のリモート入出力マスタの再稼働を優先させる理由については後に明らかにする。
【００３７】
復旧処理中状態ＳＢ２００では、制御部１３０のＣＰＵは、排他復旧中フラグを“１”に更新し、さらに、復旧対象のリモート入出力マスタの各々に対して再稼働を指示する処理（以下、立ち上げ処理）を実行する。この立ち上げ処理は、復旧対象のリモート入出力マスタに対して本実施形態特有の通知を行う点を除いて従来の立ち上げ処理と同様である。以下では、上記通知のことを「片系立ち上げ通知」と呼ぶ。この片系立ち上げ通知は、当該通知の送信先のリモート入出力マスタ３０に対して、当該リモート入出力マスタ３０に接続されているリモートバスにおけるデータの転送制御を行うバスマスタとして稼働開始することを指示する通知である。
【００３８】
制御部１３０のＣＰＵは、復旧対象の全てのリモート入出力マスタからイニシャル完了通知を受信すると、動作状態を次の状態へ遷移させる。本実施形態では、復旧処理中状態ＳＢ２００からの遷移先の状態は稼働系と待機系とで異なり、この点にも本実施形態の特徴が現れている。より詳細に説明すると、稼働系のコントローラ１０では、制御部１３０のＣＰＵは、復旧対象の全てのリモート入出力マスタからイニシャル完了通知の受信を契機として動作状態を追加復旧局加入待ち状態ＳＢ２５０へ遷移させる。これに対して、待機系のコントローラ１０では、制御部１３０のＣＰＵは、復旧対象の全てのリモート入出力マスタからイニシャル完了通知の受信を契機として動作状態をアイドル状態ＳＢ１００へ遷移させる。
【００３９】
追加復旧局加入待ち状態ＳＢ２５０では、制御部１３０のＣＰＵは、アイドル状態ＳＢ１００における場合と同様に復旧対象のリモート入出力マスタが有るか否かを判定し、該当するリモート入出力マスタが有った場合には、再度、動作状態を復旧処理中状態ＳＢ２００に遷移させる。追加復旧局加入待ち状態ＳＢ２５０への遷移が発生した時点から一定時間経過しても、復旧対象のリモート入出力マスタが検出されない場合には、コントローラ１０は動作状態をアイドル状態ＳＢ１００へ遷移させる。
以上がコントローラ１０の構成である。
【００４０】
次いで、リモート入出力マスタ３０の構成について説明する。
図５はリモート入出力マスタ３０の構成例を示すブロック図である。リモート入出力マスタ３０は、図５に示すように、ＩＯネットワーク通信部３１０、リモートバス通信部３２０、および制御部３３０を有する。以下では、リモート入出力マスタ３０Ａ＿ｎ（ｎ＝１〜２）のＩＯネットワーク通信部３１０およびリモート入出力マスタ３０Ｂ＿ｎのＩＯネットワーク通信部３１０の各々を区別する必要がある場合には、前者を「ＩＯネットワーク通信部３１０Ａ＿ｎ」と表記し、後者を「ＩＯネットワーク通信部３１０Ｂ＿ｎ」と表記する。リモートバス通信部３２０および制御部３３０についても、リモート入出力マスタ３０Ａ＿ｎにおけるものとリモート入出力マスタ３０Ｂ＿ｎにおけるものを区別する必要がある場合には同様の表記とする。
【００４１】
ＩＯネットワーク通信部３１０は、コントローラ１０におけるＩＯネットワーク通信部１１０と同様にＮＩＣである。ＩＯネットワーク通信部３１０Ａ＿ｎはＩＯネットワーク８０Ａに接続されており、ＩＯネットワーク通信部３１０Ｂ＿ｎはＩＯネットワーク８０Ｂに接続されている。ＩＯネットワーク通信部３１０は、接続先のＩＯネットワークから受信したデータを制御部３３０に引き渡す一方、制御部３３０から引き渡されたデータを接続先のＩＯネットワークへ送出する。
【００４２】
リモートバス通信部３２０Ａ＿１とリモートバス通信部３２０Ｂ＿１はリモートバス９０＿１に接続されており、リモートバス通信部３２０Ａ＿２とリモートバス通信部３２０Ｂ＿２はリモートバス９０＿２に接続されている。リモートバス通信部３２０は、バスマスタによる制御の下で接続先のリモートバスから受信したデータを制御部３３０に引き渡す一方、制御部３３０から引き渡されたデータを上記バスマスタによる制御の下でリモートバスへ送出する。
【００４３】
制御部３３０は、コントローラ１０における制御部１３０と同様である。すなわち、制御部３３０は、ＣＰＵと揮発性メモリと不揮発性メモリとを含んでいる（図５では何れも図示略）。不揮発性メモリには、リモート入出力マスタ３０特有の機能を上記ＣＰＵに実現させるためのファームウェアが予め格納されている。揮発性メモリは上記ファームウェアを実行する際のワークエリアとして利用される。上記ファームウェアにしたがってＣＰＵを作動させることで実現される機能の具体例としては、図５における入出力データ管理機能３３０１とシステム管理機能３３０２が挙げられる。
【００４４】
入出力データ管理機能３３０１とは、接続先のＩＯネットワークから受信したＩＯ機器宛てのデータをリモートバスを介してそのＩＯ機器へ転送する一方、リモートバスから受信したコントローラ宛てのデータを接続先のＩＯネットワークを介してその宛先へ転送する機能である。システム管理機能３３０２には、ＩＯネットワークを介して接続されたコントローラの状態情報を構築する機能、リモートバスに接続されたＩＯ機器および他のリモート入出力マスタ３０の状態情報を構築する機能、前述したバスマスタとしての機能或いは当該バスマスタによる転送制御に従うスレーブとしての機能、これら機能および入出力データ管理機能３３０１を統括的に管理する機能、およびコントローラ１０からの指示に応じて中継装置としての稼働を再開する障害復旧機能が含まれている。
【００４５】
ファームウェアにしたがって制御部３３０のＣＰＵが実行する処理のうち、本実施形態の特徴が顕著に現れるのは障害復旧機能による処理、特に、コントローラ１０から与えられるパラメータ等の設定を行うイニシャル処理である。以下では、本実施形態の特徴の理解を容易にするため、まず、従来のリモート入出力マスタにおけるイニシャル処理について説明する。
【００４６】
図６は、従来のリモート入出力マスタにおいて実行されるイニシャル処理の流れを示すフローチャートである。図６に示すようにイニシャル処理では、リモート入出力マスタは、コントローラから送信されてくるパラメータの受信を待ち受け（ステップＳＣ１００）、当該パラメータを受信すると（ステップＳＣ１００：Ｙｅｓ）、受信したパラメータの設定を行い、計時を開始する（ステップＳＣ１１０）。受信したパラメータの設定とは、揮発性メモリの所定の記憶領域に当該パラメータを書き込むことをいう。ステップＳＣ１１０に後続して実行されるステップＳＣ１２０では、リモート入出力マスタは、自装置とペアとなる他方の系のリモート入出力マスタとリモートバスを介して通信し、当該リモート入出力マスタにおけるパラメータ設定が完了したか否かを判定する。自装置とペアとなるリモート入出力マスタとは、同じリモートバスに接続され、かつ他の系に属するリモート入出力マスタのことをいう。以下では、自装置とペアとなるリモート入出力マスタのことを「ペア装置」と呼ぶ。ステップＳＣ１２０の判定結果が“Ｙｅｓ”であれば、リモート入出力マスタは、ステップＳＣ１３０の処理を実行する。逆に、ステップＳＣ１２０の判定結果が“Ｎｏ”であれば、リモート入出力マスタは、ステップＳＣ１４０の処理を実行する。
【００４７】
ステップＳＣ１２０の判定結果が“Ｙｅｓ”である場合に実行されるステップＳＣ１３０では、リモート入出力マスタは、自装置がバスマスタとなるか否かを判定する。より詳細に説明すると、ペア装置が既にバスマスタとなっている場合、或いは、ペア装置の状態が未確定であるものの自装置が待機系に属している場合にステップＳＣ１３０の判定結果は“Ｎｏ”となる。ステップＳＣ１３０の判定結果が“Ｎｏ”である場合には、リモート入出力マスタは、自装置の動作モードをスレーブに設定し、イニシャル完了通知をコントローラへ送信する（ステップＳＣ１５０）。これに対して、ステップＳＣ１３０の判定結果が“Ｙｅｓ”である場合には、リモート入出力マスタは、自装置の動作モードをマスタに設定し、イニシャル完了通知をコントローラへ送信する（ステップＳＣ１６０）。つまり、ステップＳＣ１３０、ＳＣ１５０およびＳＣ１６０の各処理は、１つのリモートバスに接続されている２つのリモート入出力マスタのうちの何れがバスマスタとなるかを調停するための処理である。
【００４８】
ステップＳＣ１２０の判定結果が“Ｎｏ”である場合に実行されるステップＳＣ１４０では、リモート入出力マスタは、タイムアウトが発生したか否かを判定する。より詳細に説明すると、リモート入出力マスタは、パラメータの設定を契機として開始した計時による計時時間が所定のタイムアウト値を上回った場合にタイムアウトが発生したと判定する。ステップＳＣ１４０の判定結果が“Ｎｏ”であれば、リモート入出力マスタは、ステップＳＣ１２０の処理を再度実行する。これに対して、ステップＳＣ１４０の判定結果が“Ｙｅｓ”であれば、リモート入出力マスタは、ステップＳＣ１６０の処理を実行し、以降、バスマスタとして振る舞う。
以上が従来のイニシャル処理の流れである。
【００４９】
次いでリモート入出力マスタ３０の制御部３３０が実行するイニシャル処理について説明する。図７は、制御部３３０のＣＰＵが実行するイニシャル処理の流れを示すフローチャートである。図７では、図６におけるものと処理内容が同一のステップには同一の符号が付されている。図７と図６を対比すれば明らかなように、制御部３３０のＣＰＵが実行するイニシャル処理では、ステップＳＣ１２０の判定結果が“Ｎｏ”である場合には、ステップＳ１３５の判定処理が実行され、このステップＳＣ１３５の判定結果が“Ｎｏ”である場合にステップＳＣ１４０の判定処理が実行される点が図６に示すイニシャル処理とことなる。以下、図６に示すイニシャル処理との相違点であるステップＳＣ１３５の判定処理を中心に説明する。
【００５０】
ステップＳＣ１３５では、制御部３３０のＣＰＵは、片系立ち上げであるか否かを判定する。より詳細に説明すると、ＣＰＵは再稼働の指示と同時に片系立ち上げ通知をコントローラ１０から受信していた場合に片系立ち上げであると判定する。前述したように、ステップＳＣ１３５の判定結果が“Ｎｏ”である場合には、ＣＰＵはステップＳＣ１４０の判定処理を実行する。これに対してステップＳＣ１３５の判定結果が“Ｙｅｓ”である場合には、ＣＰＵはステップＳＣ１６０の処理を実行する。つまり、片系立ち上げであると判定された場合には、ＣＰＵはペア装置との調停を行うことなくバスマスタとなって稼働中継装置としての稼働を開始する。
以上が本実施形態のイニシャル処理の流れである。
【００５１】
以上に説明した構成としたため、本実施形態の制御システム１では、電源６０＿ｎの故障に起因してリモート入出力マスタ３０Ａ＿ｎおよびリモート入出力マスタ３０Ｂ＿ｎの再稼働を行う場合、稼働系のリモート入出力マスタの再稼働が優先される。このため、待機系のリモート入出力マスタの再稼働が先行することはなく、従来の制御システムのように待ち合わせ時間を設けなくても、両系の再稼働完了後に無用な稼働系／待機系の切り換えが発生することはない。また、本実施形態では、稼働系のリモート入出力マスタの再稼働を優先させる制御がコントローラ１０Ａとコントローラ１０Ｂによって自動的に行われるため、システム復旧の際の復旧手順が煩雑化することも無い。
【００５２】
加えて、本実施形態では、優先的に再稼働され、かつ片系立ち上げを指示されるリモート入出力マスタ３０において実行されるイニシャル処理におけるステップＳＣ１２０の判定結果は“Ｎｏ”となり、ステップＳＣ１３５の判定が行われる。そして、このステップＳＣ１３５の判定結果は“Ｙｅｓ”となる。したがって、当該リモート入出力マスタ３０は、ペア装置との調停を行うことなく、換言すれば、ペア装置におけるパラメータ設定の完了を待つことなくバスマスタとなって稼働を再開する。当該リモート入出力マスタ３０はバスマスタとして稼働をするのであるから、ペア装置が稼働していなくても、リモートバスを介したデータ通信を何ら問題なく行え、制御システム１の再稼働が可能になる。このため、片系のみでの稼働が許容されていれば、ペア装置におけるパラメータ設定の完了を待たない分だけ、制御システム１の再稼働開始に要する時間を従来よりも短縮することができる。
【００５３】
以上本発明の一実施形態について説明したが、この実施形態に以下の変形を加えても勿論良い。
（１）上記実施形態ではＰＡ用の制御システムへの本発明の適用例を説明したが、ＦＡ（Factory Automation）用の制御システムに本発明を適用しても良い。ＦＡ用の制御システムであっても、制御システム１の再稼働開始に要する時間を短縮できることが好ましいことに変わりはないからである。また、上記実施形態では、コントローラ１０としてＤＣＳを用いたがプログラマブルロジックコントローラを用いても良い。一般にＰＡ用の制御システムでは信頼性確保の観点からコントローラとしてＤＣＳが用いられることが多いが、ＦＡ用の制御システムではコントローラとしてプログラマブルロジックコントローラが用いられることが多いからである。また、上記実施形態では、Ａ系およびＢ系の各系に２つのリモート入出力マスタ３０が含まれていたが、各系に含まれるリモート入出力マスタ３０の数は１つであっても良く、３つ以上であっても良い。さらに、上記実施形態では、リモートバス９０＿１およびリモートバス９０＿２の各々に２つのＩＯ機器が接続されていたが、１つのリモートバスに接続されるＩＯ機器の数は１つであっても良く、３つ以上であっても良い。さらに、リモートバス９０＿１に接続されるＩＯ機器の数とリモートバス９０＿２に接続されるＩＯ機器の数とが異なっていても良い。
【００５４】
（２）上記実施形態では、リモート入出力マスタ３０Ａ＿ｎおよびリモート入出力マスタ３０Ｂ＿ｎの再稼働を行う際にその時点で稼働系であった方の再稼働を優先する場合について説明したが、例えば原則的にＡ系を稼働系とし、Ｂ系を待機系とする場合には、電源故障等の発生時点において稼働系であったか否かを問わず、Ａ系の再稼働を優先させる（すなわち、Ａ系とＢ系のうち予め定められた方を優先させる）態様であっても良い。この場合、再稼働前の状態、すなわち、Ｂ系が稼働系、Ａ系が待機系となっている状態自体が異常な状態であり、両系の再稼働を契機としてその異常状態を解消することができるからである。
【００５５】
（３）上記実施形態では、リモート入出力マスタ３０Ａ＿ｎおよびリモート入出力マスタ３０Ｂ＿ｎの再稼働を行う際にその時点で稼働系であった方の再稼働を優先させる制御を、排他復旧要求フラグと排他復旧中フラグを用いて実現する場合について説明した。しかし、このような制御の実現態様は２種類のフラグを用いる態様には限定されない。例えば、アイドル状態ＳＢ１００において値が０に初期化されるカウンタを設け、復旧要求中状態ＳＢ１５０への遷移を契機として当該カウンタを１だけカウントアップし、復旧処理中状態ＳＢ２００への遷移を契機として当該カウンタをさらに１だけカウントアップする。そして、復旧要求中状態ＳＢ１５０における復旧の可否の判定基準を以下のようにすれば良い。すなわち、稼働系においては、待機系における上記カウンタの値が０または１であれば復旧可能と判定し、待機系においては、稼働系における上記カウンタの値が０である場合に復旧可能と判定するようにすれば良い。
【００５６】
（４）上記実施形態では、コントローラ１０側での第１の制御、すなわち、リモート入出力マスタ３０Ａ＿ｎおよびリモート入出力マスタ３０Ｂ＿ｎの再稼働を行う際にその時点で稼働系であった方の再稼働を優先させる制御と、リモート入出力マスタ３０側での第２の制御、すなわち、片系立ち上げを指示された場合に他方のリモート入出力マスタとの調停を行わずにバスマスタとなって即座に稼働を開始する制御、とを併用したが、第１の制御と第２の制御の何れか一方のみを行うようにしても良い。
【００５７】
例えば、第１の制御のみが行われる制御システムの具体例としては、以下の制御システムが挙げられる。この制御システムは、互いに状態監視を行い、一方が稼働系となり、他方が待機系となる２つのコントローラと、上記２つのコントローラのうちの一方とＩＯ機器との間のデータ通信を仲介する第１のリモート入出力マスタと、上記２つのコントローラのうちの他方と上記ＩＯ機器との間のデータ通信を仲介する第２の入出力マスタと、を含んでいる。そして、上記２つのコントローラの各々は、第１のリモート入出力マスタと第２のリモート入出力マスタの再稼働を行う際に、何れか一方の再稼働を優先させる制御を行う。このように第１の制御のみが行われる制御システムであっても、前述した待ち合わせ時間を設ける必要はなく、待ち合わせ時間を設けない分だけ、制御システムが再稼働可能になるまでに要する時間を短縮することができる。
【００５８】
また、第２の制御のみが行われる制御システムの具体例としては、以下の制御システムが挙げられる。この制御システムも、互いに状態監視を行い、一方が稼働系となり、他方が待機系となる２つのコントローラと、これら２つのコントローラのうちの一方とＩＯ機器との間のデータ通信を仲介する第１のリモート入出力マスタと、上記２つのコントローラのうちの他方と上記ＩＯ機器との間のデータ通信を仲介する第２のリモート入出力マスタと、を含んでおり、さらに、第１および第２のリモート入出力マスタと上記ＩＯ機器とが接続されるリモートバス、を含んでいる。上記２つのコントローラの各々は、自装置と同じ系に属するリモート入出力マスタに再稼働を指示する際に、他方のリモート入出力マスタとの調停を行わずにバスマスタとして機能することを指示する片系立ち上げ通知を送信する。そして、上記第１および第２のリモート入出力マスタの各々は、再稼働の指示とともに片系立ち上げ通知を受信した場合に、他方のリモート入出力マスタとの調停を行わずに前記リモートバスのバスマスタとなって稼働を開始する。このように第２の制御のみが行われる制御システムであっても、片系のみでの稼働か許容されているのであれば、制御システムが再稼働可能になるまでに要する時間を短縮することができる。
【００５９】
（５）上記実施形態では、本発明の特徴を顕著に示す状態遷移をＣＰＵに実現させるプログラム、すなわち、ファームウェアがコントローラ１０の不揮発性メモリに予めインストールされていたが、このプログラムをコンピュータ読み取り可能な記録媒体に書き込んで配布しても良く、また、インターネットなどの電気通信回線経由のダウンロードにより配布しても良い。このようにして配布されるファームウェアで既存のコントローラのファームウェアを上書きすることで、当該コントローラを上記実施形態のコントローラとして機能させることが可能になるからである。リモート入出力マスタ３０の不揮発性メモリにインストールされているファームウェアについても同様に、コンピュータ読み取り可能な記録媒体に書き込んで配布しても良く、また、インターネットなどの電気通信回線経由のダウンロードにより配布しても良い。
【符号の説明】
【００６０】
１…制御システム、１０Ａ，１０Ｂ…コントローラ、３０Ａ＿１，３０Ａ＿２，３０Ｂ＿１，３０Ｂ＿２…リモート入出力マスタ、４０＿１，４０＿２，５０＿１，５０＿２…ＩＯ機器、６０Ａ、６０Ｂ、６０−１，６０＿２…電源、７０…等値化ケーブル、８０Ａ，８０Ｂ…ＩＯネットワークケーブル，９０＿１，９０＿２…リモートバス。
【図１】
0006459796.tif 000002
【図２】
0006459796.tif 000003
【図３】
0006459796.tif 000004
【図４】
0006459796.tif 000005
【図５】
0006459796.tif 000006
【図６】
0006459796.tif 000007
【図７】
0006459796.tif 000008