(57)【特許請求の範囲】
【請求項１】
制御対象の状態を取り込み、あらかじめ備えられたタスクを実行することにより決定された信号を該制御対象に出力することを繰り返すコントローラを複数備えるとともに、該複数のコントローラがネットワークで接続された分散制御システムにおいて、
前記制御対象のタスクの起動関係を格納し、該タスクの起動関係に関する情報と該コントローラで現在実行中のタスクに関する情報に基づいて近々実行順序の来るタスクを特定するシステムシミュレータと、前記複数のコントローラより前記システムシミュレータにより前記特定されたタスクを実行するコントローラを決定するタスクブローカとを有し、
前記システムシミュレータは、各々のタスクをプロセスの進行と規定する互いの起動順序として関係づけた起動関係をタスク間を接続する有向枝で表現し、トークンの有無で該タスクが実行中であるかどうかを表現し、有向枝にしたがったトークンの遷移をトレースすることで、現在実行しているタスクを求めると共に、将来実行されるタスクを優先順位をつけて求め、前記各々のコントローラの現在の負荷率を求めると共に前記各々のコントローラの将来の負荷率を求め、前記タスクブローカは、前記求められた優先順位のうちの優先順位の高いタスクから順に、現在の負荷率及び将来負荷率が低下するコントローラに割当てることで、割当てるべきタスクと該割当てるべきタスクを実行するコントローラを決定することを特徴とする分散制御システム。
【請求項２】
制御対象の状態を取り込んであらかじめ備えられたタスクを実行することにより決定された信号を該制御対象に出力することを繰り返し、且つ、互いにネットワークで接続された複数のコントローラを制御する分散制御システムの制御方法において、
前記制御対象のタスクの起動関係を格納し、該タスクの起動関係に関する情報と該コントローラで現在実行中のタスクに関する情報に基づいて近々実行順序の来るタスクを特定し、前記複数のコントローラより前記特定されたタスクを実行するコントローラを決定し、
各々のタスクをプロセスの進行と規定する互いの起動順序として関係づけた起動関係をタスク間を接続する有向枝で表現し、トークンの有無で該タスクが実行中であるかどうかを表現し、有向枝にしたがったトークンの遷移をトレースすることで、現在実行しているタスクを求めると共に、将来実行されるタスクを優先順位をつけて求め、前記各々のコントローラの現在の負荷率を求めると共に前記各々のコントローラの将来の負荷率を求め、前記求められた優先順位のうちの優先順位の高いタスクから順に、現在の負荷率及び将来負荷率が低下するコントローラに割当てることで、割当てるべきタスクと該割当てるべきタスクを実行するコントローラを決定する分散制御システムの制御方法。
【発明の詳細な説明】
発明の属する技術分野
本発明はネットワークに複数のコントローラとＩ／Ｏ装置が接続された、水平分散アーキテクチャの制御システムにおいて、各コントローラのタスク実行方式に関する。
従来の技術
ネットワークに複数のコントローラとＩ／Ｏ装置が接続された制御システムにおける各コントローラのタスク実行に関する従来手法としては、コントローラのそれぞれが実行するタスクをあらかじめ決定し、各コントローラは割当てられたタスクに対応したプログラムを固定的に実行する方法であった。
このとき信頼性を高める手法としては、各コントローラを多重化することにより、コントローラの出力を高信頼化したり、あるコントローラが動作不良をおこしたときのバックアップを可能にする方法があった。またコントローラの故障に伴うシステムのダウンタイムを最小化する目的で、数台のコントローラを一台のコントローラでバックアップする手法もあった。
各コントローラを協調動作させる手法としては、特開平5−342303号に記載されているように、コントローラのいそがしさの情報を伝える母線でコントローラ間を接続し、母線から得られる情報をもとに、いそがしいコントローラからそうでないコントローラにタスクの受け渡しをする方法があった。
発明が解決しようとする課題
上記従来技術には、次のような問題点があった。まずコントローラの実行タスクが固定された方式の場合、あるタスクはあらかじめ定められた特定のコントローラでしか実行できないため、そのコントローラが故障した場合に実行できないタスクが生じ、システム全体の動作に不都合が発生していた。これを回避するためにコントローラを多重化したり、バックアップ用のコントローラを備えた構成では、システムの動作は継続できるもののシステムが高価格となる問題があった。さらにこれらの手法では、信頼性の観点から各コントローラの負荷率の裕度を十分に取っておく必要があるため、平均的な負荷率が低くなり、結果的に必要以上の台数のコントローラを備えた高価格なシステムとなっていた。またコントローラの負荷率が不均一となり、極めて負荷率の低いコントローラがあることが無駄になる場合もあった。
タスクの受け渡しをコントローラ間で行う従来技術では、あるタスクが発生した時点でこれを実行するコントローラが決定されるため、この処理がオーバヘッドとなり、タスクの実行終了までの応答時間が長くなるため、制御システムの性能が低下する問題があった。
課題を解決するための手段
上記問題点は、以下の技術的手段により解決される。
まず、制御システムを安価で高信頼化する目的に関しては、制御対象の状態を取り込み、あらかじめ備えられたタスクを実行することにより決定された信号を該制御対象に出力することを繰り返すコントローラを複数備えるとともに、該複数のコントローラがネットワークで接続された分散制御システムにおいて、前記制御対象のタスクの起動関係を格納し、該タスクの起動関係に関する情報と該コントローラで現在実行中のタスクに関する情報に基づいて近々実行順序の来るタスクを特定するシステムシミュレータと、前記複数のコントローラより前記システムシミュレータにより前記特定されたタスクを実行するコントローラを決定するタスクブローカとを備えることにより解決される。
同様の目的は、コントローラのそれぞれにタスクを一括して格納し、各タスクがタスクブローカからの指示により選択的に起動される構成とすることによっても解決される。
さらに制御システムを高信頼化する目的に関しては、コントローラの異常を検知し、対応した処理の実行をシステムシミュレータとタスクブローカに指示する異常検知・処理手段を設けることにより実現される。
タスク格納手段には、コントローラが実行するタスクがロードモジュールの形で、一括してタスク毎に格納されている。システムシミュレータはタスクの起動関係を保持しており、コントローラから取り込んだ情報を基に現在稼働中のタスクを特定し、さらに各コントローラの負荷率のトレンドを特定する。タスクブローカはシステムシミュレータを起動し、次にコントローラで起動されるべきタスク、および各コントローラの負荷率を把握した後、それぞれのタスクを実行するコントローラを決定する。さらにタスクをいつまでにコントローラにダウンロードすればよいかを決定する。ネットワークスケジューラはネットワークのトラフィックを把握した後、各タスクを負荷分散装置からコントローラにダウンロードするタイミングを決定する。そして決定されたタイミングで、ロードモジュールを該当するコントローラにダウンロードする。
またコントローラのそれぞれにタスクを一括して格納する構成とした場合には、同様の処理の後、負荷分散装置からタスクの起動指令のみがネットワークを介してコントローラに伝えられる。コントローラではタスクブローカからの指示にしたがってタスクを順次起動する。
さらにどちらの構成においても、異常検知・処理手段はコントローラに異常が発生したことを検知すると、該当するコントローラが実行していたタスクを他のコントローラに振り分けるべく、システムシミュレータとタスクブローカを起動する。タスクブローカは、異常なコントローラが実行していたタスクの実行優先順位を最大に設定したうえで、システムシミュレータ出力にしたがって正常なコントローラに割当てるタスクを決定する。
発明の実施の形態
以下、本発明の実施例を図にしたがって詳細に説明する。第１図に、本発明が適用される負荷分散装置１００の構成、および負荷分散装置１００が用いられる制御システムの構成を示す。負荷分散装置１００は、システムシミュレータ101，タスクブローカ１０２，タスク格納手段１０３，ネットワークスケジューラ104，通信Ｉ／Ｆ１０５，ユーザがタスクの内容を入力したりシステムシミュレータ１１０のパラメータをセットしたりする入力手段１２０，負荷分散装置が取り込んだ信号や演算内容を表示する出力手段１２１から構成される。負荷分散装置１００は、コントローラ１３１〜１３３，Ｉ／Ｏ１４１〜１４３とともにネットワーク１３０に接続され、これらと信号の授受を行う。コントローラ１３１〜１３３は、制御対象１５０の状態をＩ／Ｏ１４１〜１４３，ネットワーク１３０を介して取り込み、適当な制御演算の後、制御対象を動作させる信号をネットワーク１３０Ｉ／Ｏ１４１〜１４３を経由して出力する。
次に負荷分散装置１００の全体の構成を説明し、その後、各部の動作を詳細に説明する。システムシミュレータ１０１は、コントローラシミュレータ１１０とタスクシミュレータ１１１からなり、コントローラシミュレータ１１０は各コントローラの現行の負荷率を取り込み、さらに後述するタスクシミュレータ１１１により近未来に実行終了となるタスクの負荷分を差し引くことにより、負荷率のトレンドを予測する。またタスクシミュレータ１１１は、コントローラ１３１〜１３３が実行するタスクの起動関係を格納しており、通信Ｉ／Ｆ１０５を介して取り込んだ現在起動中のタスクに関する情報を基に、タスクブローカ１０２の指示により、近未来に実行タイミングが来るタスクを時系列に抽出する。タスクブローカ１０２は、システム管理手段１１２，起動タスク選定手段１１３，コントローラ選定手段１１４からなる。システム管理手段１１２は、通信Ｉ／Ｆ１０５を介してコントローラ１３１〜１３３が実行したタスクが正常に終了したかどうかを管理するとともに、起動タスク選定手段１１３に対して周期的に起動をかける。起動タスク選定手段１１３はタスクシミュレータ１１１を起動し、近々に実行タイミングが来るタスクを抽出した後、コントローラ選定手段１１４を起動する。コントローラ選定手段１１４はコントローラシミュレータ１１０を起動し、各コントローラの現在の負荷率および負荷率のトレンドを検出した後、抽出したタスクに対して、タスクの実行を行うコントローラの選定を行う。システム管理手段１１２は、この結果を受けてネットワークスケジューラ１０４を起動する。ネットワークスケジューラ１０４は、ネットワーク１３０のトラフィックを通信Ｉ／Ｆ１０５を介して検出したうえで、各タスクのダウンロードのタイミングを決定する。そして決定されたタイミングでタスク格納手段１０３から、所定のタスクを抽出した後、ネットワーク１３０を介して割当てられたコントローラ131〜１３３にダウンロードする。ダウンロードされたタスクは実行タイミングが来るのを待ってコントローラ１３１〜１３３で実行され、実行後コントローラ131〜１３３はタスクが正常に終了したかどうかをシステム管理手段１１２に送信する。実行後のタスクは、必要に応じてタスク格納手段１０３に返送されたり、このタスクを次回実行するのに必要な情報のみがタスク格納手段１０３に返送される。また単に廃棄してもよい。
次に各部の動作を詳細に説明する。第２図に制御対象１５０の一例として、制御対象が熱間圧延プラントである場合の例を示す。第２図に示したのは熱間圧延プラントの一部で、補助ロール２１１により運ばれる鋼板２２０が、大雑把な圧延を行う粗仕上げプロセス２００，最終的な圧延を行う仕上げプロセス２０１でそれぞれ加工を受けた後、冷却プロセス２０２で冷やされ、ダウンコイラ２０３に巻き取られる。本実施例で、粗仕上げプロセス２００は２つの仕上げスタンド２０４，２０５からなり、各スタンドはロール２０６により鋼板の圧延を行う。同様に仕上げプロセス２０１は複数のスタンド２０７〜２０８からなり、ロール２０９が運ばれてくる鋼板２２０を圧延する。また冷却プロセス２０２は水を噴射する多数のノズル２１０からなり、鋼板２２１を７００〜９００℃程度から４００〜６００℃程度に冷却する。制御対象１５０を制御する信号は、コントローラ１３１〜１３３における演算により生成され、これらはＩ／Ｏ１４３，ネットワーク１３０を介して出力される。
次に本発明で実現された負荷分散装置１００の構成について詳細に説明する。第３図にタスク格納手段１０３の構成を示す。図は制御対象１５０を制御する処理が合計ｎ個のタスクで構成された例を示している。各タスクの内容として、たとえばタスク１は１番目の仕上げスタンドの定常時のロール速度を計算することと対応し、以下、タスク２，タスク３，…，タスクｉ，…，タスクｎに対応して、図に記載された内容が割付けられている。これらのタスクは、コントローラ131〜１３３でそのまま実行可能なロードモジュールの形で格納されている。
第４図はシステムシミュレータ１０１に備えられたコントローラシミュレータ１１０が実行するアルゴリズムである。コントローラシミュレータ１１０はＳ４−１で、常時、周期的に各コントローラ１３１〜１３３の負荷率を通信Ｉ／Ｆ１０５を介して検出し、把握している。第５図にコントローラ１３１〜１３３の構成の一例を示す。ＮＣＰ（Network Control Processor）５１０はネットワーク１３０と接続され、ここから得た信号をコントローラ内のローカルバス５１５を経由して、ＰＭ（Program Memory）５１１やＤＭ（Data Memory）５１３へ伝送する。CPU512はＳＭ（System Memory）５１４にしたがって動作し、ＰＭ５１１に書かれているプログラムを解読した後、ＤＭ５１３やNCP510と必要なデータを交換しながら制御を実行する。第６図にCPU512の動作モードの一例と負荷率の算出するのに必要な所量の計測方法を示す。図でCPU512の動作モードは主として、タスクの起動を待っている状態、ウォッチドグタイマをリセットする等のバックグラウンドタスクを実行している状態、およびＰＭ５１１に書かれたタスクを実行している状態の３通りにより構成される。図ではバックグラウンドタスクを実行した後タスク１を実行し、以下タスク待ち状態を経ながら次々とタスクを実行していく状態を示している。このとき得られた各タスクの実行時間ｔ１〜ｔｎ、およびトータルのタスク実行時間Ｔ０を用いて、負荷率Ｌratioは例えば数式１の形で計算され、通信Ｉ／Ｆ１０５を介して負荷分散装置１００に送信される。
0003787359.tif 000002
ｔ１〜ｔｎおよびＴ0は、これらを計測する専用のハードウェアを設けて測定してもよいし、バックグラウンドタスクの中でソフトウェア的に計測してもよい。Ｓ４−１では送られてくる各コントローラ１３１〜１３３の負荷率Ｌratioの値を、逐次把握している。
コントローラシミュレータではＳ４−１を実行中に、タスクブローカ１０２からの指示によりＳ４−２およびＳ４−３が起動される。すなわちＳ４−２で、各コントローラ１３１〜１３３の現在の負荷率の値から負荷率の裕度を計算する。負荷率の裕度は、コントローラ１３１〜１３３の負荷能力から現在の負荷分を差し引き、さらにそれぞれのコントローラ１３１〜１３３に固定的に割付けられているタスクの負荷分を差し引いた値で与えられる。固定的に割付けられているタスクとしては、鋼板２２０の張力異常のときにロール速度を下げるために起動されるタスク等が考えられる。このように突発的に発生するため、事前に実行タイミングが設定できないタスクについては、コントローラ１３１〜１３３のいずれかあるいは複数に常駐させることになる。固定的に割付けられているタスクは突発的に実行されることが予想されるため、負荷率の裕度からは差し引くことになる。さらにＳ４−３でタスクシミュレータ１１１を起動し、後述する演算により現在起動中のタスクの中から近々終了するタスクを予測し、新たに実行開始となるタスクがないと仮定した場合の、各コントローラの負荷率のトレンドを予測する。Ｓ４−４で演算結果をタスクブローカ１０２に返送する。
第７図にタスクシミュレータ１１１が実行するアルゴリズムを示す。タスクシミュレータ１１１は、例えば第８図のような形で制御対象１５０で実行される各タスクの起動関係を格納している。第８図の内容はシステム構築時の運転方案を基に、ユーザが入力手段１２０から入力することにより構築される。またプログラミング言語が制御用言語として普及しつつあるＳＦＣ（Sequential Functional Chart）や高級言語であれば、ユーザのプログラムから自動的に編集することもできる。ここで第８図は、各タスクを同期ゲート８０４を介して有向枝８０３で接続した構成となっており、接続関係がタスクの起動・終了関係を示している。図中に黒丸で示したトークンは、現在稼働中のタスクを意味しており、図ではタスク１１，タスク１９，タスク１８，タスク５が実行状態にあることを意味している。またタスクとしては、タスク１０２，タスク１２２，タスク１２５のような、タスク切り換えの同期管理を行う入力待ちタスク８０１と、制御演算結果を制御対象へ出力したり制御指令の算出を行う演算タスク８０２の２種類が定義された例を示している。第６図が示しているタスクの接続関係は、まず並列して実行されるタスク２４とタスク５１の実行が終了した後、タスク１１２で鋼板の減速タイミングを検知すると、タスク１１とタスク１９が並行して起動される。さらにタスク１０２で鋼板抜けを検知したところで、タスク１１とタスク１９の処理を終了する。
さらにこのタイミングまでにタスク１８とタスク５を終了しておき、タスク１２５で鋼板の噛み込みを検知したタイミングでコントローラが実行すべきタスクが次へ遷移し、タスク７１とタスク８５が同時に起動される。第７図のＳ７−１では、通信Ｉ／Ｆ１０５を介して制御対象１５０およびコントローラ１３１〜１３３の現在の状態を逐次把握し、Ｓ７−２でトークン移行の要否を判定する。コントローラ１３１〜１３３で実行中のタスクが遷移した場合にはＳ７−３でトークン移行処理を行う。タスクシミュレータ１１１は、Ｓ７−１〜７−３の処理を常時繰り返し、第８図のトークンの配置を遷移していく。さらにタスクブローカ１０２からの指令によりＳ７−４とＳ７−５の処理が起動される。まずＳ７−４で、第８図に示したタスクの起動関係と現状のトークン分布を基に、次にトークンが移行されるべきタスクを時系列に抽出する。たとえば第８図の場合には、まずタスク１２５が抽出され、次にタスク７１とタスク８５が抽出される。次にＳ７−５で抽出結果をタスクブローカ１０２に返信し、通常の処理へ復帰する。またコントローラシミュレータ１１０からの指令によりＳ７−６〜Ｓ７−７が起動される。Ｓ７−６では、現在トークンのあるタスクを抽出し、これらのタスクがいつ終了するかを算出する。第８図の例では、タスク１１，タスク１９，タスク１８，タスク５が抽出される。ここでタスク１１，タスク１９は鋼板の抜けが検知されるまで周期的に繰り返し実行されるため、終了タイミングを正確に算出するのは困難であるが、タスク１８，タスク５については指令値を一回算出した後終了となるため、終了タイミングはタスクの演算量で機械的に算出できる。したがってタスク１８，タスク５についてはタスクの演算量をロードモジュールの大きさ等で算出する。またタスク１１，タスク１９については、鋼板の抜けるタイミングをラインの運転情報や過去の実績から見積ることにより、算出する。Ｓ７−７で算出する結果をコントローラシミュレータ１１０に返信する。
次にタスクブローカ１０２の動作アルゴリズムを示す。第９図にシステム管理手段１１２の実行内容を示す。システム管理手段１１２は通常Ｓ９−１〜Ｓ９−４の処理を行い、タイマ割込等により周期的にＳ９−５〜Ｓ９−８の処理を行う。まずＳ９−１で、新たなタスクの終了があったかどうかを、コントローラ１３１〜１３３からのタスク終了情報の送付の有無で判定する。タスク終了情報は、コントローラ１３１〜１３３でタスクが終了することに対応してタスクブローカへ送られ、少なくとも、コントローラ１３１〜１３３で実行されたタスクが正常に終了したか否か、異常があった場合にはその内容、さらに必要に応じて次回に引き継ぐべき情報、タスクの実行に要した時間等が記載されている。Ｓ９−２ではタスクの終了情報の解釈を行う。Ｓ９−３で、解釈の結果タスクが正常に終了したかどうかを判定する。タスクが異常終了した場合には、Ｓ９−４で出力手段１２１に異常があったこと、およびタスク終了情報から得た異常情報を表示し、Ｓ９−１に復帰する。Ｓ９−１〜９−４を実行中にタイマ割込等でＳ９−５〜Ｓ９−８の処理が起動された場合には、処理をＳ９−５に遷移する。まずＳ９−５で起動タスク選定手段１１３を起動し、現時点から近未来にかけて実行が予定されているタスクの抽出を行った後、Ｓ９−６で処理の終了を判定し、終了していればＳ９−７に処理を移行する。処理の終了は所定の個数のタスクが抽出できたことや、現在から所定の時間後までに実行される可能性のあるタスクをすべて抽出できたことで判定する。次にＳ９−７で、コントローラ選定手段１１４を起動し、抽出したタスクを実行するコントローラを決定する。Ｓ９−８で抽出したすべてのタスクに対してコントローラの割付けが終わったことを判定した後、Ｓ９−１〜Ｓ９−４の通常処理へ復帰する。
次に起動タスク選定手段１１３とコントローラ選定手段１１４で実行される処理について詳細に説明する。第１０図に起動タスク選定手段１１３が実行するアルゴリズムを示す。まずＳ１０−１でタスクシミュレータ１１１を起動し、直近に実行タイミングが来るタスクを抽出する。タスクシミュレータ１１１では、第７図で示したアルゴリズムにしたがってタスクの抽出を行う。Ｓ１０−２で新たに抽出したタスクがあったかどうかを判定し、あった場合には、Ｓ１０−３で各タスクに実行タイミングの順番により優先順位を付ける。
第１１図にコントローラ選定手段１１４が実行する処理を示す。最初にＳ１１−１でコントローラシミュレータ１１０を起動し、各コントローラの現在の負荷率および負荷率のトレンドを検出する。次にＳ１１−２で起動タスク選定手段１１３の出力を受け取り、優先順位の高いタスクから順に、現在の負荷率の低いコントローラに割当てて行く。また負荷率のトレンドから、近未来に負荷率が下がると予想されるコントローラに対しては、その時点で起動されるタスクを現在の負荷率に関係なく割付けてもよい。
ネットワークスケジューラ１０４では、タスクブローカ１１３の演算により得られた直近に実行すべきタスクと実行タイミング、およびこれらが実行されるコントローラの情報を基に、これらをコントローラ１３１〜１３３にダウンロードするタイミングを設定する。第１２図にネットワークスケジューラ１０４が実行する処理のフローチャートを示す。まずＳ１２−１で、新たにコントローラに割付けられたタスクについて、ダウンロード開始時刻のリミットを設定する。ダウンロードの終了リミットはタスクの実行開始に間に合うことで、開始リミットは終了リミットからダウンロードに必要な時間だけ遡った時刻になる。実際にはコントローラ１３１〜１３３は、第６図のタスク待ちの間を利用して順次ロードモジュールを受け付けていくため、ローディングに必要な時間に、ローディング先のコントローラがタスク実行に従事している時間を加算して決定される。次にＳ１２−２でネットワークのトラフィックを検出し、ダウンロード開始時刻のリミットまでのどのタイミングでタスクをコントローラ１３１〜１３３にダウンロードすれば、ネットワークのトラフィックを過大にすることなくダウンロードできるかを判定する。Ｓ１２−３でこれらの結果を基に、各タスクのダウンロードのタイミングを設定する。
次に本発明の第２の実施例として、各コントローラ１３１〜１３３にＴＭ（タスクメモリ）を設けた構成について説明する。実施例ではコントローラ１３１を例に説明する。TM1301はＰＭ５１１に代わって設けられており、同様にローカルバス５１５に接続される。CPU512はTM1301に書かれたプログラムを以下に示す手法で選択的に実行する。TM1301には、コントローラ１３１〜１３３で実行されるタスクが一括して蓄えられている。第１４図にTM1301の構成を示す。格納されている内容はタスク格納手段と同様で、タスク１〜タスクｎがコントローラ131〜１３３で実行可能な形で格納されている。負荷分散装置１００は第１の実施例と同様に動作するが、各タスクがすでにコントローラ１３１〜１３３に格納されているため、負荷分散装置１００からタスクに対応したロードモジュールをダウンロードする必要はない。したがってタスクブローカ１０２で起動すべきタスクの抽出と、抽出されたタスクの実行を行うコントローラの選定が終了した後には、これらを示す情報を該当するコントローラに送信する。第１５図にこの情報をコード化して送信する場合の例を示す。第１５図のタスク割当てコード１５０１は、一例としてコントローラ番号，タスク番号，起動タイミングを含んでいる。コントローラ番号はタスクが実行されるコントローラを特定する情報で、同時にタスク割当てコードの送信先を示す。タスク番号はTM1301の中のどのタスクを実行するかを示す情報である。また起動タイミングは、タスクの実行の開始がいつであるかを特定する。この他にも必要に応じてタスクの優先順位や、前回実行されたときの終了情報等を付加してもよい。タスク割当てコード１５０１は、コントローラ番号で示されたコントローラのみに送付してもよいし、コントローラ１３１〜１３３のすべてに送付してもよい。
本実施例ではコントローラ１３１〜１３３のそれぞれが、実行すべきタスクをすべて格納している方式としたが、同一のタスクが適当な複数のコントローラに格納されていれば同様の効果を得ることが可能となる。したがってタスク毎に格納するコントローラを取捨選択する方式も考えられる。
次に本発明の第３の実施例として、コントローラ１３１〜１３３のうち１台もしくは複数台が故障した場合に、コントローラが実行するタスクを再構成することにより、制御対象１５０への制御を継続するアルゴリズムを示す。第１６図は負荷分散装置１００にコントローラ１３１〜１３３の異常を検知し、対応した処置を行う異常検知・処理手段１６０１を設けてこれらを行う場合の実施例である。図において異常検知・処理手段１６０１は、通信Ｉ／Ｆ１０５を介してコントローラ１３１〜１３３から得られる信号によりコントローラに異常が発生したことを検知する。検知の手法としては、コントローラ１３１〜１３３が自己診断により異常の発生を知り、これを自主的に負荷分散装置１００に知らせる方法、異常検知・処理手段１６０１から各コントローラ１３１〜１３３に対して定期的にアライブ確認信号を出力し、これに対する応答を基に負荷分散装置１００の側で異常の発生を知る方法等、種々考えられる。異常を検知すると、異常検知・処理手段１４０１は異常処理を行う。ここではコントローラ１３１が故障した場合の例を示す。第１７図にこのときのアルゴリズムを示す。Ｓ１７−１で異常の発生を検知すると、Ｓ１７−２でコントローラシミュレータ１１０におけるコントローラ１３１の負荷率を１００％に固定した後、Ｓ１７−３でタスクブローカ１０２を起動する。タスクブローカ１０２の処理としては、基本的には第１および第２の実施例と同様のアルゴリズムを実行してもよいが、異常発生時のタスク切り換えの応答を高めるために、以下に示す手法で行うことが考えられる。第１８図に異常検知・処理手段１４０１が設けられた場合に、起動タスク選定手段１１３が実行する処理アルゴリズムを示す。まずＳ１８−１でタスクシミュレータ１１１を起動し、直近に実行タイミングが来るタスクを抽出する。タスクシミュレータ１１１では、第７図で示したアルゴリズムにしたがってタスクの抽出を行う。Ｓ１８−２で新たに抽出したタスクがあったかどうかを判定し、あった場合にはＳ１８−３で各タスクに実行タイミングの順番により優先順位を付ける。さらにＳ１８−４で、以上の演算結果を起動タスク格納手段１６０２に出力する。起動タスク格納手段１６０２を設けたことで、コントローラ１３１〜１３３に異常が検知されたとき、起動タスク選定手段１１３を再度起動する必要はなく、単に起動タスク格納手段１４０２を検索するのみでよい。したがってタスクを正常なコントローラに再分配する処理が簡略化される。
第１９図に、異常検知・処理手段１４０１に起動された後にシステム管理手段１１２が実行するアルゴリズムを示す。すなわちＳ１９−１で起動タスク格納手段１６０２から起動すべきタスクを抽出する。次にＳ１９−２でコントローラ１３１が実行していたタスクに最大の優先順位を付与する。この後Ｓ１９−３で、コントローラ選定手段１１４を起動する。コントローラ選定手段１１４は第１１図のアルゴリズムにしたがってタスクとコントローラの割付けを行う。割付けが終了したらＳ１９−４で、割付け結果を第１５図に示したタスク割当てコードの形で各コントローラ１３２〜１３３へ送付する。このとき最大の優先順位のタスクは即座に実行すべき起動タイミングが設定してある。各コントローラ１３２〜１３３は送られてきたタスクを、起動タイミングにしたがって順次実行していく。以上のようにして、コントローラ１３１のタスクはコントローラ１３２〜１３３に分配され、制御対象１５０に対する制御が継続される。さらにその他のコントローラが故障した場合であっても、正常なコントローラの演算能力の総和を超えなければ、制御の継続が可能となる。
各コントローラのＭＴＢＦ（Mean Time Between Failure）を外的ノイズによる誤動作を含めて１０-4／ｈ、ダウンタイムの平均値を１ｈと仮定すると、システムの信頼性および価格メリットは次のように定量化できる。価格メリットはコントローラの台数で評価する。従来のシステムの第１の例として１０台のコントローラが負荷率６０％で稼働しているシステム、本発明で実現された同様のシステム、従来システムの第２の例として（２×１０）台のコントローラからなる２重系のシステムを考える。従来システムの第１の例では、１０台のコントローラのいずれか一台が故障するとシステムが完全な形で動作できないため、システムの故障率はコントローラ単体の故障率と一致し、１０-4／ｈとなる。これに対して各コントローラは暫定的に８０％の負荷率で動作可能とすると、本発明で実現されたシステムでは、第１及び第２の実施例で記載したダイナミックな負荷の割付けにより、制御が継続可能なコントローラの台数は、
８０×１０／（６０×１０）＝７.５                        …（数式２）
となる。従って３台以上のコントローラの同時故障が起こった場合にのみシステム故障となるため、システムの故障率は近似的に、
10Ｃ3（１０-4）3＝１.２×１０-10                      …（数式３）
となり、同一のコントローラ数で信頼性が大幅に向上する。また、従来システムの第２の例では、２０台のコントローラの特定の２台に同時に故障が発生した場合にシステム故障となるため、システムの故障率は、
１０×（１０-4）2＝１.０×１０-7                      …（数式４）
となる。本発明では従来システムの第２の例に比べ、半分の台数のコントローラで高い信頼性のシステムを構築できる。本発明で実現されたシステムの故障率は、コントローラの台数をＮ，コントローラの故障率をｐ，ダウンタイムの平均値をＴ，通常運転時の平均負荷率をｆ1，瞬時的に実行可能な負荷率をｆ2とすると、一般的には、
NＣ[f2/f1]（ｐＴ）[f2/f1]                                …（数式５）
で表わされる。ただし［α］はαの整数部を示す。
本実施例では、コントローラ１３１〜１３３にTM1301を設けた第２の実施例の構成を例に、異常検知・処理手段１６０１の処理を説明したが、第１の実施例に対しても同様の形態で実現できる。
以上の実施例では、制御システムの中に負荷分散装置１００を専用に設ける構成としたが、プログラミング装置やシステム監視を行う装置と兼用し、安価にシステムを構築することも考えられる。また負荷分散装置１００は、ワークステーションやサーバ，パソコン等の汎用の計算機を用いて容易に実現できる。さらにコントローラの１つあるいは複数にシステムシミュレータ１０１とタスクブローカ１０２を備えることにより、負荷分散装置１００の処理を行わせることも可能である。
発明の効果
本発明によれば、コントローラが一台もしくは数台故障したとしても、他のコントローラが実行タスクの切り換えを高速に行い、処理を代替するため、制御が停止することはない。したがってシステムダウンを回避した高信頼な制御システムが実現される。またコントローラの負荷率を均一化できるため、過大な負荷率で動作するコントローラはなくなり、この点でもシステムを高信頼化できる。
またコントローラの処理の裕度が低く設定でき、したがって平均負荷率を高くできるため、全体としてコントローラの台数を削減した安価なシステム構築が可能となる。またコントローラ毎の多重化を行わなくてもこれと同等の信頼性が得られるため、同様にシステムを安価にできる。
さらにシステム構築時にコントローラを必要以上に備えておき、故障した場合には、このコントローラにタスクを割当てない処理を行うことにより、システムの動作を継続させることも可能となる。これによりコントローラの交換やこれにともなう保守作業を省略でき、システムのランニングコストが低減できる。
またシステムシミュレーションで起動間近と判定されたタスクが、コントローラで実行準備を整えておき、起動タイミングになると即座に実行開始となるため、タスクの実行に要するオーバヘッドを最小化できる。したがって従来の、コントローラが実行するタスクを固定的に割付け、これらをコントローラに常駐させる方式と同等の性能を得ることができ、システム性能が低下することはない。
【図面の簡単な説明】
第１図は本発明において実現された負荷分散装置の構成図である。
第２図は制御対象の構成図である。
第３図は本発明のタスク格納手段の構成である。
第４図は本発明のコントローラシミュレータが実行するアルゴリズムである。
第５図はコントローラの構成図である。
第６図はコントローラのＣＰＵの動作の一例である。
第７図は発明のタスクシミュレータが実行するアルゴリズムである。
第８図は本発明のタスクシミュレータが保持するタスクの起動関係である。
第９図は本発明のシステム管理手段が実行するアルゴリズムである。
第１０図は本発明の起動タスク選定手段が実行するアルゴリズムである。
第１１図は本発明のコントローラ選定手段が実行するアルゴリズムである。
第１２図はネットワークスケジューラが実行するアルゴリズムである。
第１３図はコントローラにタスクメモリを設けた構成図である。
第１４図はタスクメモリの構成である。
第１５図はタスク割当てコードのフォーマットである。
第１６図は異常検知・処理手段を設けた負荷分散装置の構成図である。
第１７図は異常検知・処理手段が実行するアルゴリズムである。
第１８図は異常検知・処理手段を設けた場合の起動タスク選定手段が実行するアルゴリズムである。
第１９図は異常検知・処理手段に起動された後にシステム管理手段が実行するアルゴリズムである。
符号の説明
１０１…システムシミュレータ、１０２…タスクブローカ、１０３…タスク格納手段、１３０…ネットワーク、１３１，１３２，１３３…コントローラ。
【図１】
0003787359.tif 000003
【図２】
0003787359.tif 000004
【図３】
0003787359.tif 000005
【図４】
0003787359.tif 000006
【図５】
0003787359.tif 000007
【図６】
0003787359.tif 000008
【図７】
0003787359.tif 000009
【図８】
0003787359.tif 000010
【図９】
0003787359.tif 000011
【図１０】
0003787359.tif 000012
【図１１】
0003787359.tif 000013
【図１２】
0003787359.tif 000014
【図１３】
0003787359.tif 000015
【図１４】
0003787359.tif 000016
【図１５】
0003787359.tif 000017
【図１６】
0003787359.tif 000018
【図１７】
0003787359.tif 000019
【図１８】
0003787359.tif 000020
【図１９】
0003787359.tif 000021