JP3787359B2

JP3787359B2 - Distributed control system and control method of distributed control system

Info

Publication number: JP3787359B2
Application number: JP53160696A
Authority: JP
Inventors: 昌宏鹿山; 敏彦松田; 泰男諸岡; 弘昌山岡; 光明小林; 英二小林; 章宏大橋
Original assignee: 株式会社日立製作所
Priority date: 1995-04-21
Filing date: 1995-04-21
Publication date: 2006-06-21
Anticipated expiration: 2021-06-21
Also published as: WO1996033467A1

Description

発明の属する技術分野
本発明はネットワークに複数のコントローラとＩ／Ｏ装置が接続された、水平分散アーキテクチャの制御システムにおいて、各コントローラのタスク実行方式に関する。
従来の技術
ネットワークに複数のコントローラとＩ／Ｏ装置が接続された制御システムにおける各コントローラのタスク実行に関する従来手法としては、コントローラのそれぞれが実行するタスクをあらかじめ決定し、各コントローラは割当てられたタスクに対応したプログラムを固定的に実行する方法であった。
このとき信頼性を高める手法としては、各コントローラを多重化することにより、コントローラの出力を高信頼化したり、あるコントローラが動作不良をおこしたときのバックアップを可能にする方法があった。またコントローラの故障に伴うシステムのダウンタイムを最小化する目的で、数台のコントローラを一台のコントローラでバックアップする手法もあった。
各コントローラを協調動作させる手法としては、特開平5−342303号に記載されているように、コントローラのいそがしさの情報を伝える母線でコントローラ間を接続し、母線から得られる情報をもとに、いそがしいコントローラからそうでないコントローラにタスクの受け渡しをする方法があった。
発明が解決しようとする課題
上記従来技術には、次のような問題点があった。まずコントローラの実行タスクが固定された方式の場合、あるタスクはあらかじめ定められた特定のコントローラでしか実行できないため、そのコントローラが故障した場合に実行できないタスクが生じ、システム全体の動作に不都合が発生していた。これを回避するためにコントローラを多重化したり、バックアップ用のコントローラを備えた構成では、システムの動作は継続できるもののシステムが高価格となる問題があった。さらにこれらの手法では、信頼性の観点から各コントローラの負荷率の裕度を十分に取っておく必要があるため、平均的な負荷率が低くなり、結果的に必要以上の台数のコントローラを備えた高価格なシステムとなっていた。またコントローラの負荷率が不均一となり、極めて負荷率の低いコントローラがあることが無駄になる場合もあった。
タスクの受け渡しをコントローラ間で行う従来技術では、あるタスクが発生した時点でこれを実行するコントローラが決定されるため、この処理がオーバヘッドとなり、タスクの実行終了までの応答時間が長くなるため、制御システムの性能が低下する問題があった。
課題を解決するための手段
上記問題点は、以下の技術的手段により解決される。
まず、制御システムを安価で高信頼化する目的に関しては、制御対象の状態を取り込み、あらかじめ備えられたタスクを実行することにより決定された信号を該制御対象に出力することを繰り返すコントローラを複数備えるとともに、該複数のコントローラがネットワークで接続された分散制御システムにおいて、前記制御対象のタスクの起動関係を格納し、該タスクの起動関係に関する情報と該コントローラで現在実行中のタスクに関する情報に基づいて近々実行順序の来るタスクを特定するシステムシミュレータと、前記複数のコントローラより前記システムシミュレータにより前記特定されたタスクを実行するコントローラを決定するタスクブローカとを備えることにより解決される。
同様の目的は、コントローラのそれぞれにタスクを一括して格納し、各タスクがタスクブローカからの指示により選択的に起動される構成とすることによっても解決される。
さらに制御システムを高信頼化する目的に関しては、コントローラの異常を検知し、対応した処理の実行をシステムシミュレータとタスクブローカに指示する異常検知・処理手段を設けることにより実現される。
タスク格納手段には、コントローラが実行するタスクがロードモジュールの形で、一括してタスク毎に格納されている。システムシミュレータはタスクの起動関係を保持しており、コントローラから取り込んだ情報を基に現在稼働中のタスクを特定し、さらに各コントローラの負荷率のトレンドを特定する。タスクブローカはシステムシミュレータを起動し、次にコントローラで起動されるべきタスク、および各コントローラの負荷率を把握した後、それぞれのタスクを実行するコントローラを決定する。さらにタスクをいつまでにコントローラにダウンロードすればよいかを決定する。ネットワークスケジューラはネットワークのトラフィックを把握した後、各タスクを負荷分散装置からコントローラにダウンロードするタイミングを決定する。そして決定されたタイミングで、ロードモジュールを該当するコントローラにダウンロードする。
またコントローラのそれぞれにタスクを一括して格納する構成とした場合には、同様の処理の後、負荷分散装置からタスクの起動指令のみがネットワークを介してコントローラに伝えられる。コントローラではタスクブローカからの指示にしたがってタスクを順次起動する。
さらにどちらの構成においても、異常検知・処理手段はコントローラに異常が発生したことを検知すると、該当するコントローラが実行していたタスクを他のコントローラに振り分けるべく、システムシミュレータとタスクブローカを起動する。タスクブローカは、異常なコントローラが実行していたタスクの実行優先順位を最大に設定したうえで、システムシミュレータ出力にしたがって正常なコントローラに割当てるタスクを決定する。
発明の実施の形態
以下、本発明の実施例を図にしたがって詳細に説明する。第１図に、本発明が適用される負荷分散装置１００の構成、および負荷分散装置１００が用いられる制御システムの構成を示す。負荷分散装置１００は、システムシミュレータ101，タスクブローカ１０２，タスク格納手段１０３，ネットワークスケジューラ104，通信Ｉ／Ｆ１０５，ユーザがタスクの内容を入力したりシステムシミュレータ１１０のパラメータをセットしたりする入力手段１２０，負荷分散装置が取り込んだ信号や演算内容を表示する出力手段１２１から構成される。負荷分散装置１００は、コントローラ１３１〜１３３，Ｉ／Ｏ１４１〜１４３とともにネットワーク１３０に接続され、これらと信号の授受を行う。コントローラ１３１〜１３３は、制御対象１５０の状態をＩ／Ｏ１４１〜１４３，ネットワーク１３０を介して取り込み、適当な制御演算の後、制御対象を動作させる信号をネットワーク１３０Ｉ／Ｏ１４１〜１４３を経由して出力する。
次に負荷分散装置１００の全体の構成を説明し、その後、各部の動作を詳細に説明する。システムシミュレータ１０１は、コントローラシミュレータ１１０とタスクシミュレータ１１１からなり、コントローラシミュレータ１１０は各コントローラの現行の負荷率を取り込み、さらに後述するタスクシミュレータ１１１により近未来に実行終了となるタスクの負荷分を差し引くことにより、負荷率のトレンドを予測する。またタスクシミュレータ１１１は、コントローラ１３１〜１３３が実行するタスクの起動関係を格納しており、通信Ｉ／Ｆ１０５を介して取り込んだ現在起動中のタスクに関する情報を基に、タスクブローカ１０２の指示により、近未来に実行タイミングが来るタスクを時系列に抽出する。タスクブローカ１０２は、システム管理手段１１２，起動タスク選定手段１１３，コントローラ選定手段１１４からなる。システム管理手段１１２は、通信Ｉ／Ｆ１０５を介してコントローラ１３１〜１３３が実行したタスクが正常に終了したかどうかを管理するとともに、起動タスク選定手段１１３に対して周期的に起動をかける。起動タスク選定手段１１３はタスクシミュレータ１１１を起動し、近々に実行タイミングが来るタスクを抽出した後、コントローラ選定手段１１４を起動する。コントローラ選定手段１１４はコントローラシミュレータ１１０を起動し、各コントローラの現在の負荷率および負荷率のトレンドを検出した後、抽出したタスクに対して、タスクの実行を行うコントローラの選定を行う。システム管理手段１１２は、この結果を受けてネットワークスケジューラ１０４を起動する。ネットワークスケジューラ１０４は、ネットワーク１３０のトラフィックを通信Ｉ／Ｆ１０５を介して検出したうえで、各タスクのダウンロードのタイミングを決定する。そして決定されたタイミングでタスク格納手段１０３から、所定のタスクを抽出した後、ネットワーク１３０を介して割当てられたコントローラ131〜１３３にダウンロードする。ダウンロードされたタスクは実行タイミングが来るのを待ってコントローラ１３１〜１３３で実行され、実行後コントローラ131〜１３３はタスクが正常に終了したかどうかをシステム管理手段１１２に送信する。実行後のタスクは、必要に応じてタスク格納手段１０３に返送されたり、このタスクを次回実行するのに必要な情報のみがタスク格納手段１０３に返送される。また単に廃棄してもよい。
次に各部の動作を詳細に説明する。第２図に制御対象１５０の一例として、制御対象が熱間圧延プラントである場合の例を示す。第２図に示したのは熱間圧延プラントの一部で、補助ロール２１１により運ばれる鋼板２２０が、大雑把な圧延を行う粗仕上げプロセス２００，最終的な圧延を行う仕上げプロセス２０１でそれぞれ加工を受けた後、冷却プロセス２０２で冷やされ、ダウンコイラ２０３に巻き取られる。本実施例で、粗仕上げプロセス２００は２つの仕上げスタンド２０４，２０５からなり、各スタンドはロール２０６により鋼板の圧延を行う。同様に仕上げプロセス２０１は複数のスタンド２０７〜２０８からなり、ロール２０９が運ばれてくる鋼板２２０を圧延する。また冷却プロセス２０２は水を噴射する多数のノズル２１０からなり、鋼板２２１を７００〜９００℃程度から４００〜６００℃程度に冷却する。制御対象１５０を制御する信号は、コントローラ１３１〜１３３における演算により生成され、これらはＩ／Ｏ１４３，ネットワーク１３０を介して出力される。
次に本発明で実現された負荷分散装置１００の構成について詳細に説明する。第３図にタスク格納手段１０３の構成を示す。図は制御対象１５０を制御する処理が合計ｎ個のタスクで構成された例を示している。各タスクの内容として、たとえばタスク１は１番目の仕上げスタンドの定常時のロール速度を計算することと対応し、以下、タスク２，タスク３，…，タスクｉ，…，タスクｎに対応して、図に記載された内容が割付けられている。これらのタスクは、コントローラ131〜１３３でそのまま実行可能なロードモジュールの形で格納されている。
第４図はシステムシミュレータ１０１に備えられたコントローラシミュレータ１１０が実行するアルゴリズムである。コントローラシミュレータ１１０はＳ４−１で、常時、周期的に各コントローラ１３１〜１３３の負荷率を通信Ｉ／Ｆ１０５を介して検出し、把握している。第５図にコントローラ１３１〜１３３の構成の一例を示す。ＮＣＰ（Network Control Processor）５１０はネットワーク１３０と接続され、ここから得た信号をコントローラ内のローカルバス５１５を経由して、ＰＭ（Program Memory）５１１やＤＭ（Data Memory）５１３へ伝送する。CPU512はＳＭ（System Memory）５１４にしたがって動作し、ＰＭ５１１に書かれているプログラムを解読した後、ＤＭ５１３やNCP510と必要なデータを交換しながら制御を実行する。第６図にCPU512の動作モードの一例と負荷率の算出するのに必要な所量の計測方法を示す。図でCPU512の動作モードは主として、タスクの起動を待っている状態、ウォッチドグタイマをリセットする等のバックグラウンドタスクを実行している状態、およびＰＭ５１１に書かれたタスクを実行している状態の３通りにより構成される。図ではバックグラウンドタスクを実行した後タスク１を実行し、以下タスク待ち状態を経ながら次々とタスクを実行していく状態を示している。このとき得られた各タスクの実行時間ｔ１〜ｔｎ、およびトータルのタスク実行時間Ｔ０を用いて、負荷率Ｌ_ratioは例えば数式１の形で計算され、通信Ｉ／Ｆ１０５を介して負荷分散装置１００に送信される。

ｔ１〜ｔｎおよびＴ₀は、これらを計測する専用のハードウェアを設けて測定してもよいし、バックグラウンドタスクの中でソフトウェア的に計測してもよい。Ｓ４−１では送られてくる各コントローラ１３１〜１３３の負荷率Ｌ_ratioの値を、逐次把握している。
コントローラシミュレータではＳ４−１を実行中に、タスクブローカ１０２からの指示によりＳ４−２およびＳ４−３が起動される。すなわちＳ４−２で、各コントローラ１３１〜１３３の現在の負荷率の値から負荷率の裕度を計算する。負荷率の裕度は、コントローラ１３１〜１３３の負荷能力から現在の負荷分を差し引き、さらにそれぞれのコントローラ１３１〜１３３に固定的に割付けられているタスクの負荷分を差し引いた値で与えられる。固定的に割付けられているタスクとしては、鋼板２２０の張力異常のときにロール速度を下げるために起動されるタスク等が考えられる。このように突発的に発生するため、事前に実行タイミングが設定できないタスクについては、コントローラ１３１〜１３３のいずれかあるいは複数に常駐させることになる。固定的に割付けられているタスクは突発的に実行されることが予想されるため、負荷率の裕度からは差し引くことになる。さらにＳ４−３でタスクシミュレータ１１１を起動し、後述する演算により現在起動中のタスクの中から近々終了するタスクを予測し、新たに実行開始となるタスクがないと仮定した場合の、各コントローラの負荷率のトレンドを予測する。Ｓ４−４で演算結果をタスクブローカ１０２に返送する。
第７図にタスクシミュレータ１１１が実行するアルゴリズムを示す。タスクシミュレータ１１１は、例えば第８図のような形で制御対象１５０で実行される各タスクの起動関係を格納している。第８図の内容はシステム構築時の運転方案を基に、ユーザが入力手段１２０から入力することにより構築される。またプログラミング言語が制御用言語として普及しつつあるＳＦＣ（Sequential Functional Chart）や高級言語であれば、ユーザのプログラムから自動的に編集することもできる。ここで第８図は、各タスクを同期ゲート８０４を介して有向枝８０３で接続した構成となっており、接続関係がタスクの起動・終了関係を示している。図中に黒丸で示したトークンは、現在稼働中のタスクを意味しており、図ではタスク１１，タスク１９，タスク１８，タスク５が実行状態にあることを意味している。またタスクとしては、タスク１０２，タスク１２２，タスク１２５のような、タスク切り換えの同期管理を行う入力待ちタスク８０１と、制御演算結果を制御対象へ出力したり制御指令の算出を行う演算タスク８０２の２種類が定義された例を示している。第６図が示しているタスクの接続関係は、まず並列して実行されるタスク２４とタスク５１の実行が終了した後、タスク１１２で鋼板の減速タイミングを検知すると、タスク１１とタスク１９が並行して起動される。さらにタスク１０２で鋼板抜けを検知したところで、タスク１１とタスク１９の処理を終了する。
さらにこのタイミングまでにタスク１８とタスク５を終了しておき、タスク１２５で鋼板の噛み込みを検知したタイミングでコントローラが実行すべきタスクが次へ遷移し、タスク７１とタスク８５が同時に起動される。第７図のＳ７−１では、通信Ｉ／Ｆ１０５を介して制御対象１５０およびコントローラ１３１〜１３３の現在の状態を逐次把握し、Ｓ７−２でトークン移行の要否を判定する。コントローラ１３１〜１３３で実行中のタスクが遷移した場合にはＳ７−３でトークン移行処理を行う。タスクシミュレータ１１１は、Ｓ７−１〜７−３の処理を常時繰り返し、第８図のトークンの配置を遷移していく。さらにタスクブローカ１０２からの指令によりＳ７−４とＳ７−５の処理が起動される。まずＳ７−４で、第８図に示したタスクの起動関係と現状のトークン分布を基に、次にトークンが移行されるべきタスクを時系列に抽出する。たとえば第８図の場合には、まずタスク１２５が抽出され、次にタスク７１とタスク８５が抽出される。次にＳ７−５で抽出結果をタスクブローカ１０２に返信し、通常の処理へ復帰する。またコントローラシミュレータ１１０からの指令によりＳ７−６〜Ｓ７−７が起動される。Ｓ７−６では、現在トークンのあるタスクを抽出し、これらのタスクがいつ終了するかを算出する。第８図の例では、タスク１１，タスク１９，タスク１８，タスク５が抽出される。ここでタスク１１，タスク１９は鋼板の抜けが検知されるまで周期的に繰り返し実行されるため、終了タイミングを正確に算出するのは困難であるが、タスク１８，タスク５については指令値を一回算出した後終了となるため、終了タイミングはタスクの演算量で機械的に算出できる。したがってタスク１８，タスク５についてはタスクの演算量をロードモジュールの大きさ等で算出する。またタスク１１，タスク１９については、鋼板の抜けるタイミングをラインの運転情報や過去の実績から見積ることにより、算出する。Ｓ７−７で算出する結果をコントローラシミュレータ１１０に返信する。
次にタスクブローカ１０２の動作アルゴリズムを示す。第９図にシステム管理手段１１２の実行内容を示す。システム管理手段１１２は通常Ｓ９−１〜Ｓ９−４の処理を行い、タイマ割込等により周期的にＳ９−５〜Ｓ９−８の処理を行う。まずＳ９−１で、新たなタスクの終了があったかどうかを、コントローラ１３１〜１３３からのタスク終了情報の送付の有無で判定する。タスク終了情報は、コントローラ１３１〜１３３でタスクが終了することに対応してタスクブローカへ送られ、少なくとも、コントローラ１３１〜１３３で実行されたタスクが正常に終了したか否か、異常があった場合にはその内容、さらに必要に応じて次回に引き継ぐべき情報、タスクの実行に要した時間等が記載されている。Ｓ９−２ではタスクの終了情報の解釈を行う。Ｓ９−３で、解釈の結果タスクが正常に終了したかどうかを判定する。タスクが異常終了した場合には、Ｓ９−４で出力手段１２１に異常があったこと、およびタスク終了情報から得た異常情報を表示し、Ｓ９−１に復帰する。Ｓ９−１〜９−４を実行中にタイマ割込等でＳ９−５〜Ｓ９−８の処理が起動された場合には、処理をＳ９−５に遷移する。まずＳ９−５で起動タスク選定手段１１３を起動し、現時点から近未来にかけて実行が予定されているタスクの抽出を行った後、Ｓ９−６で処理の終了を判定し、終了していればＳ９−７に処理を移行する。処理の終了は所定の個数のタスクが抽出できたことや、現在から所定の時間後までに実行される可能性のあるタスクをすべて抽出できたことで判定する。次にＳ９−７で、コントローラ選定手段１１４を起動し、抽出したタスクを実行するコントローラを決定する。Ｓ９−８で抽出したすべてのタスクに対してコントローラの割付けが終わったことを判定した後、Ｓ９−１〜Ｓ９−４の通常処理へ復帰する。
次に起動タスク選定手段１１３とコントローラ選定手段１１４で実行される処理について詳細に説明する。第１０図に起動タスク選定手段１１３が実行するアルゴリズムを示す。まずＳ１０−１でタスクシミュレータ１１１を起動し、直近に実行タイミングが来るタスクを抽出する。タスクシミュレータ１１１では、第７図で示したアルゴリズムにしたがってタスクの抽出を行う。Ｓ１０−２で新たに抽出したタスクがあったかどうかを判定し、あった場合には、Ｓ１０−３で各タスクに実行タイミングの順番により優先順位を付ける。
第１１図にコントローラ選定手段１１４が実行する処理を示す。最初にＳ１１−１でコントローラシミュレータ１１０を起動し、各コントローラの現在の負荷率および負荷率のトレンドを検出する。次にＳ１１−２で起動タスク選定手段１１３の出力を受け取り、優先順位の高いタスクから順に、現在の負荷率の低いコントローラに割当てて行く。また負荷率のトレンドから、近未来に負荷率が下がると予想されるコントローラに対しては、その時点で起動されるタスクを現在の負荷率に関係なく割付けてもよい。
ネットワークスケジューラ１０４では、タスクブローカ１１３の演算により得られた直近に実行すべきタスクと実行タイミング、およびこれらが実行されるコントローラの情報を基に、これらをコントローラ１３１〜１３３にダウンロードするタイミングを設定する。第１２図にネットワークスケジューラ１０４が実行する処理のフローチャートを示す。まずＳ１２−１で、新たにコントローラに割付けられたタスクについて、ダウンロード開始時刻のリミットを設定する。ダウンロードの終了リミットはタスクの実行開始に間に合うことで、開始リミットは終了リミットからダウンロードに必要な時間だけ遡った時刻になる。実際にはコントローラ１３１〜１３３は、第６図のタスク待ちの間を利用して順次ロードモジュールを受け付けていくため、ローディングに必要な時間に、ローディング先のコントローラがタスク実行に従事している時間を加算して決定される。次にＳ１２−２でネットワークのトラフィックを検出し、ダウンロード開始時刻のリミットまでのどのタイミングでタスクをコントローラ１３１〜１３３にダウンロードすれば、ネットワークのトラフィックを過大にすることなくダウンロードできるかを判定する。Ｓ１２−３でこれらの結果を基に、各タスクのダウンロードのタイミングを設定する。
次に本発明の第２の実施例として、各コントローラ１３１〜１３３にＴＭ（タスクメモリ）を設けた構成について説明する。実施例ではコントローラ１３１を例に説明する。TM1301はＰＭ５１１に代わって設けられており、同様にローカルバス５１５に接続される。CPU512はTM1301に書かれたプログラムを以下に示す手法で選択的に実行する。TM1301には、コントローラ１３１〜１３３で実行されるタスクが一括して蓄えられている。第１４図にTM1301の構成を示す。格納されている内容はタスク格納手段と同様で、タスク１〜タスクｎがコントローラ131〜１３３で実行可能な形で格納されている。負荷分散装置１００は第１の実施例と同様に動作するが、各タスクがすでにコントローラ１３１〜１３３に格納されているため、負荷分散装置１００からタスクに対応したロードモジュールをダウンロードする必要はない。したがってタスクブローカ１０２で起動すべきタスクの抽出と、抽出されたタスクの実行を行うコントローラの選定が終了した後には、これらを示す情報を該当するコントローラに送信する。第１５図にこの情報をコード化して送信する場合の例を示す。第１５図のタスク割当てコード１５０１は、一例としてコントローラ番号，タスク番号，起動タイミングを含んでいる。コントローラ番号はタスクが実行されるコントローラを特定する情報で、同時にタスク割当てコードの送信先を示す。タスク番号はTM1301の中のどのタスクを実行するかを示す情報である。また起動タイミングは、タスクの実行の開始がいつであるかを特定する。この他にも必要に応じてタスクの優先順位や、前回実行されたときの終了情報等を付加してもよい。タスク割当てコード１５０１は、コントローラ番号で示されたコントローラのみに送付してもよいし、コントローラ１３１〜１３３のすべてに送付してもよい。
本実施例ではコントローラ１３１〜１３３のそれぞれが、実行すべきタスクをすべて格納している方式としたが、同一のタスクが適当な複数のコントローラに格納されていれば同様の効果を得ることが可能となる。したがってタスク毎に格納するコントローラを取捨選択する方式も考えられる。
次に本発明の第３の実施例として、コントローラ１３１〜１３３のうち１台もしくは複数台が故障した場合に、コントローラが実行するタスクを再構成することにより、制御対象１５０への制御を継続するアルゴリズムを示す。第１６図は負荷分散装置１００にコントローラ１３１〜１３３の異常を検知し、対応した処置を行う異常検知・処理手段１６０１を設けてこれらを行う場合の実施例である。図において異常検知・処理手段１６０１は、通信Ｉ／Ｆ１０５を介してコントローラ１３１〜１３３から得られる信号によりコントローラに異常が発生したことを検知する。検知の手法としては、コントローラ１３１〜１３３が自己診断により異常の発生を知り、これを自主的に負荷分散装置１００に知らせる方法、異常検知・処理手段１６０１から各コントローラ１３１〜１３３に対して定期的にアライブ確認信号を出力し、これに対する応答を基に負荷分散装置１００の側で異常の発生を知る方法等、種々考えられる。異常を検知すると、異常検知・処理手段１４０１は異常処理を行う。ここではコントローラ１３１が故障した場合の例を示す。第１７図にこのときのアルゴリズムを示す。Ｓ１７−１で異常の発生を検知すると、Ｓ１７−２でコントローラシミュレータ１１０におけるコントローラ１３１の負荷率を１００％に固定した後、Ｓ１７−３でタスクブローカ１０２を起動する。タスクブローカ１０２の処理としては、基本的には第１および第２の実施例と同様のアルゴリズムを実行してもよいが、異常発生時のタスク切り換えの応答を高めるために、以下に示す手法で行うことが考えられる。第１８図に異常検知・処理手段１４０１が設けられた場合に、起動タスク選定手段１１３が実行する処理アルゴリズムを示す。まずＳ１８−１でタスクシミュレータ１１１を起動し、直近に実行タイミングが来るタスクを抽出する。タスクシミュレータ１１１では、第７図で示したアルゴリズムにしたがってタスクの抽出を行う。Ｓ１８−２で新たに抽出したタスクがあったかどうかを判定し、あった場合にはＳ１８−３で各タスクに実行タイミングの順番により優先順位を付ける。さらにＳ１８−４で、以上の演算結果を起動タスク格納手段１６０２に出力する。起動タスク格納手段１６０２を設けたことで、コントローラ１３１〜１３３に異常が検知されたとき、起動タスク選定手段１１３を再度起動する必要はなく、単に起動タスク格納手段１４０２を検索するのみでよい。したがってタスクを正常なコントローラに再分配する処理が簡略化される。
第１９図に、異常検知・処理手段１４０１に起動された後にシステム管理手段１１２が実行するアルゴリズムを示す。すなわちＳ１９−１で起動タスク格納手段１６０２から起動すべきタスクを抽出する。次にＳ１９−２でコントローラ１３１が実行していたタスクに最大の優先順位を付与する。この後Ｓ１９−３で、コントローラ選定手段１１４を起動する。コントローラ選定手段１１４は第１１図のアルゴリズムにしたがってタスクとコントローラの割付けを行う。割付けが終了したらＳ１９−４で、割付け結果を第１５図に示したタスク割当てコードの形で各コントローラ１３２〜１３３へ送付する。このとき最大の優先順位のタスクは即座に実行すべき起動タイミングが設定してある。各コントローラ１３２〜１３３は送られてきたタスクを、起動タイミングにしたがって順次実行していく。以上のようにして、コントローラ１３１のタスクはコントローラ１３２〜１３３に分配され、制御対象１５０に対する制御が継続される。さらにその他のコントローラが故障した場合であっても、正常なコントローラの演算能力の総和を超えなければ、制御の継続が可能となる。
各コントローラのＭＴＢＦ（Mean Time Between Failure）を外的ノイズによる誤動作を含めて１０^-4／ｈ、ダウンタイムの平均値を１ｈと仮定すると、システムの信頼性および価格メリットは次のように定量化できる。価格メリットはコントローラの台数で評価する。従来のシステムの第１の例として１０台のコントローラが負荷率６０％で稼働しているシステム、本発明で実現された同様のシステム、従来システムの第２の例として（２×１０）台のコントローラからなる２重系のシステムを考える。従来システムの第１の例では、１０台のコントローラのいずれか一台が故障するとシステムが完全な形で動作できないため、システムの故障率はコントローラ単体の故障率と一致し、１０^-4／ｈとなる。これに対して各コントローラは暫定的に８０％の負荷率で動作可能とすると、本発明で実現されたシステムでは、第１及び第２の実施例で記載したダイナミックな負荷の割付けにより、制御が継続可能なコントローラの台数は、
８０×１０／（６０×１０）＝７.５ …（数式２）
となる。従って３台以上のコントローラの同時故障が起こった場合にのみシステム故障となるため、システムの故障率は近似的に、
₁₀Ｃ₃（１０^-4）³＝１.２×１０^-10 …（数式３）
となり、同一のコントローラ数で信頼性が大幅に向上する。また、従来システムの第２の例では、２０台のコントローラの特定の２台に同時に故障が発生した場合にシステム故障となるため、システムの故障率は、
１０×（１０^-4）²＝１.０×１０^-7 …（数式４）
となる。本発明では従来システムの第２の例に比べ、半分の台数のコントローラで高い信頼性のシステムを構築できる。本発明で実現されたシステムの故障率は、コントローラの台数をＮ，コントローラの故障率をｐ，ダウンタイムの平均値をＴ，通常運転時の平均負荷率をｆ₁，瞬時的に実行可能な負荷率をｆ₂とすると、一般的には、
_NＣ_[f2/f1]（ｐＴ）^[f2/f1] …（数式５）
で表わされる。ただし［α］はαの整数部を示す。
本実施例では、コントローラ１３１〜１３３にTM1301を設けた第２の実施例の構成を例に、異常検知・処理手段１６０１の処理を説明したが、第１の実施例に対しても同様の形態で実現できる。
以上の実施例では、制御システムの中に負荷分散装置１００を専用に設ける構成としたが、プログラミング装置やシステム監視を行う装置と兼用し、安価にシステムを構築することも考えられる。また負荷分散装置１００は、ワークステーションやサーバ，パソコン等の汎用の計算機を用いて容易に実現できる。さらにコントローラの１つあるいは複数にシステムシミュレータ１０１とタスクブローカ１０２を備えることにより、負荷分散装置１００の処理を行わせることも可能である。
発明の効果
本発明によれば、コントローラが一台もしくは数台故障したとしても、他のコントローラが実行タスクの切り換えを高速に行い、処理を代替するため、制御が停止することはない。したがってシステムダウンを回避した高信頼な制御システムが実現される。またコントローラの負荷率を均一化できるため、過大な負荷率で動作するコントローラはなくなり、この点でもシステムを高信頼化できる。
またコントローラの処理の裕度が低く設定でき、したがって平均負荷率を高くできるため、全体としてコントローラの台数を削減した安価なシステム構築が可能となる。またコントローラ毎の多重化を行わなくてもこれと同等の信頼性が得られるため、同様にシステムを安価にできる。
さらにシステム構築時にコントローラを必要以上に備えておき、故障した場合には、このコントローラにタスクを割当てない処理を行うことにより、システムの動作を継続させることも可能となる。これによりコントローラの交換やこれにともなう保守作業を省略でき、システムのランニングコストが低減できる。
またシステムシミュレーションで起動間近と判定されたタスクが、コントローラで実行準備を整えておき、起動タイミングになると即座に実行開始となるため、タスクの実行に要するオーバヘッドを最小化できる。したがって従来の、コントローラが実行するタスクを固定的に割付け、これらをコントローラに常駐させる方式と同等の性能を得ることができ、システム性能が低下することはない。
【図面の簡単な説明】
第１図は本発明において実現された負荷分散装置の構成図である。
第２図は制御対象の構成図である。
第３図は本発明のタスク格納手段の構成である。
第４図は本発明のコントローラシミュレータが実行するアルゴリズムである。
第５図はコントローラの構成図である。
第６図はコントローラのＣＰＵの動作の一例である。
第７図は発明のタスクシミュレータが実行するアルゴリズムである。
第８図は本発明のタスクシミュレータが保持するタスクの起動関係である。
第９図は本発明のシステム管理手段が実行するアルゴリズムである。
第１０図は本発明の起動タスク選定手段が実行するアルゴリズムである。
第１１図は本発明のコントローラ選定手段が実行するアルゴリズムである。
第１２図はネットワークスケジューラが実行するアルゴリズムである。
第１３図はコントローラにタスクメモリを設けた構成図である。
第１４図はタスクメモリの構成である。
第１５図はタスク割当てコードのフォーマットである。
第１６図は異常検知・処理手段を設けた負荷分散装置の構成図である。
第１７図は異常検知・処理手段が実行するアルゴリズムである。
第１８図は異常検知・処理手段を設けた場合の起動タスク選定手段が実行するアルゴリズムである。
第１９図は異常検知・処理手段に起動された後にシステム管理手段が実行するアルゴリズムである。
符号の説明
１０１…システムシミュレータ、１０２…タスクブローカ、１０３…タスク格納手段、１３０…ネットワーク、１３１，１３２，１３３…コントローラ。TECHNICAL FIELD OF THE INVENTION
The present invention relates to a task execution method for each controller in a horizontal distributed architecture control system in which a plurality of controllers and I / O devices are connected to a network.
Conventional technology
As a conventional method for task execution of each controller in a control system in which a plurality of controllers and I / O devices are connected to a network, a task to be executed by each controller is determined in advance, and each controller corresponds to an assigned task. It was a way to run the program fixedly.
At this time, as a technique for improving the reliability, there is a method of making the controller output highly reliable by multiplexing each controller or enabling backup when a certain controller malfunctions. There was also a method of backing up several controllers with one controller in order to minimize system downtime due to controller failure.
As a method of operating each controller in a coordinated manner, as described in Japanese Patent Laid-Open No. 5-342303, the controllers are connected with a bus that conveys information about the urgency of the controller, and based on information obtained from the bus, There was a way to pass tasks from a busy controller to a non-busy controller.
Problems to be solved by the invention
The above prior art has the following problems. First, in the case where the execution task of the controller is fixed, a certain task can be executed only by a specific controller that is determined in advance. Therefore, if the controller fails, a task that cannot be executed occurs, resulting in inconvenience to the operation of the entire system. Was. In order to avoid this, in the configuration in which the controllers are multiplexed or the backup controller is provided, the system operation can be continued, but the system becomes expensive. Furthermore, in these methods, it is necessary to keep a sufficient margin of the load factor of each controller from the viewpoint of reliability, so the average load factor becomes low, resulting in having more controllers than necessary. It was an expensive system. In addition, the load factor of the controller becomes uneven, and it may be useless to have a controller with a very low load factor.
In the conventional technology in which tasks are transferred between controllers, the controller that executes a task is determined when a certain task occurs. This process is overhead, and the response time until the task execution ends is increased. There was a problem that system performance deteriorated.
Means for solving the problem
The above problems are solved by the following technical means.
First, for the purpose of making the control system inexpensive and highly reliable, a plurality of controllers are provided that repeatedly capture the state of the control target and output a signal determined by executing a task provided in advance to the control target. In addition, in a distributed control system in which the plurality of controllers are connected via a network, the activation relationship of the task to be controlled is stored, and based on information regarding the activation relationship of the task and information regarding a task currently being executed by the controller The problem is solved by including a system simulator that identifies a task that is about to be executed soon, and a task broker that determines a controller that executes the identified task by the system simulator from the plurality of controllers.
The same object can be solved by storing the tasks in each controller in a batch and selectively starting each task according to an instruction from the task broker.
Further, the purpose of making the control system highly reliable is realized by providing an abnormality detection / processing means for detecting an abnormality of the controller and instructing the system simulator and the task broker to execute the corresponding processing.
In the task storage means, tasks executed by the controller are collectively stored for each task in the form of a load module. The system simulator holds task activation relationships, identifies the currently active task based on the information fetched from the controller, and identifies the trend of the load factor of each controller. The task broker activates the system simulator, and then determines the controller to execute each task after grasping the task to be activated by the controller and the load factor of each controller. In addition, determine when the task should be downloaded to the controller. After grasping the network traffic, the network scheduler determines the timing for downloading each task from the load balancer to the controller. Then, the load module is downloaded to the corresponding controller at the determined timing.
Further, in a configuration in which tasks are collectively stored in each controller, only the task activation command is transmitted from the load balancer to the controller via the network after the same processing. The controller sequentially starts tasks according to instructions from the task broker.
Furthermore, in either configuration, when the abnormality detection / processing means detects that an abnormality has occurred in the controller, the system simulator and the task broker are activated in order to distribute the task being executed by the corresponding controller to the other controller. The task broker determines the task to be assigned to the normal controller according to the system simulator output, after setting the execution priority of the task executed by the abnormal controller to the maximum.
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 shows a configuration of a load distribution apparatus 100 to which the present invention is applied and a configuration of a control system in which the load distribution apparatus 100 is used. The load balancer 100 includes a system simulator 101, a task broker 102, a task storage unit 103, a network scheduler 104, a communication I / F 105, and an input unit 120 for a user to input task contents and set parameters of the system simulator 110. , And an output means 121 for displaying a signal and calculation contents taken in by the load balancer. The load balancer 100 is connected to the network 130 together with the controllers 131 to 133 and the I / Os 141 to 143, and exchanges signals with them. The controllers 131 to 133 fetch the state of the control target 150 via the I / O 141 to 143 and the network 130, and after appropriate control calculation, output a signal for operating the control target via the network 130 I / O 141 to 143. To do.
Next, the overall configuration of the load distribution apparatus 100 will be described, and then the operation of each unit will be described in detail. The system simulator 101 includes a controller simulator 110 and a task simulator 111. The controller simulator 110 captures the current load factor of each controller, and further subtracts the task load to be completed in the near future by the task simulator 111 described later. To predict the trend of the load factor. In addition, the task simulator 111 stores the activation relationship of tasks executed by the controllers 131 to 133, and based on the information about the currently activated task fetched via the communication I / F 105, the task broker 102 can Tasks whose execution timing comes in the near future are extracted in time series. The task broker 102 includes system management means 112, activation task selection means 113, and controller selection means 114. The system management unit 112 manages whether or not the tasks executed by the controllers 131 to 133 have been normally completed via the communication I / F 105 and periodically starts the startup task selection unit 113. The activated task selecting unit 113 activates the task simulator 111, extracts a task whose execution timing is coming soon, and then activates the controller selecting unit 114. The controller selection unit 114 activates the controller simulator 110, detects the current load factor of each controller and the trend of the load factor, and then selects a controller that executes the task for the extracted task. In response to this result, the system management unit 112 activates the network scheduler 104. The network scheduler 104 detects the traffic of the network 130 via the communication I / F 105 and determines the download timing of each task. Then, after a predetermined task is extracted from the task storage unit 103 at the determined timing, it is downloaded to the controllers 131 to 133 assigned via the network 130. The downloaded task is executed by the controllers 131 to 133 after the execution timing has come, and the post-execution controllers 131 to 133 transmit to the system management means 112 whether or not the task has been normally completed. The task after execution is returned to the task storage unit 103 as necessary, or only information necessary for executing this task next time is returned to the task storage unit 103. Alternatively, it may simply be discarded.
Next, the operation of each unit will be described in detail. FIG. 2 shows an example in which the control object is a hot rolling plant as an example of the control object 150. FIG. 2 shows a part of a hot rolling plant in which a steel plate 220 conveyed by an auxiliary roll 211 is processed in a rough finishing process 200 for rough rolling and a finishing process 201 for final rolling. After being received, it is cooled by the cooling process 202 and wound on the downcoiler 203. In this embodiment, the rough finishing process 200 includes two

finishing stands

204 and 205, and each stand rolls a steel sheet by a roll 206. Similarly, the finishing process 201 includes a plurality of stands 207 to 208 and rolls the steel plate 220 on which the roll 209 is carried. The cooling process 202 includes a large number of nozzles 210 that inject water, and cools the steel plate 221 from about 700 to 900 ° C. to about 400 to 600 ° C. Signals for controlling the controlled object 150 are generated by calculations in the controllers 131 to 133, and these are output via the I / O 143 and the network 130.
Next, the configuration of the load distribution apparatus 100 realized by the present invention will be described in detail. FIG. 3 shows the configuration of the task storage means 103. The figure shows an example in which the process for controlling the control target 150 is composed of a total of n tasks. As the contents of each task, for example, task 1 corresponds to calculating the steady roll speed of the first finishing stand, and hereinafter corresponds to task 2, task 3,..., Task i,. The contents described in the figure are assigned. These tasks are stored in the form of load modules that can be executed by the controllers 131 to 133 as they are.
FIG. 4 shows an algorithm executed by the controller simulator 110 provided in the system simulator 101. In S4-1, the controller simulator 110 periodically detects and grasps the load factor of each of the controllers 131 to 133 via the communication I / F 105. FIG. 5 shows an example of the configuration of the controllers 131-133. An NCP (Network Control Processor) 510 is connected to the network 130 and transmits a signal obtained therefrom to a PM (Program Memory) 511 and a DM (Data Memory) 513 via a local bus 515 in the controller. The CPU 512 operates in accordance with an SM (System Memory) 514. After decoding a program written in the PM 511, the CPU 512 executes control while exchanging necessary data with the DM 513 and the NCP 510. FIG. 6 shows an example of the operation mode of the CPU 512 and a method for measuring the quantity necessary for calculating the load factor. In the figure, the operation mode of the CPU 512 is mainly in a state of waiting for task activation, a state of executing a background task such as resetting the watchdog timer, and a state of executing a task written in PM511. It consists of three ways. In the figure, the task 1 is executed after executing the background task, and the tasks are successively executed while waiting for the task. Using the execution times t1 to tn of each task obtained at this time and the total task execution time T0, the load factor L _ratio Is calculated, for example, in the form of Equation 1 and transmitted to the load balancer 100 via the communication I / F 105.

t1-tn and T ₀ May be measured by providing dedicated hardware for measuring them, or may be measured by software in a background task. In S4-1, the load factor L of each controller 131-133 sent _ratio The value of is sequentially grasped.
In the controller simulator, S4-2 and S4-3 are activated by an instruction from the task broker 102 while executing S4-1. That is, in S4-2, the tolerance of the load factor is calculated from the current load factor value of each of the controllers 131-133. The margin of the load factor is given by a value obtained by subtracting the current load from the load capability of the controllers 131 to 133 and further subtracting the load of tasks fixedly assigned to the controllers 131 to 133. As a task that is fixedly assigned, a task that is activated to lower the roll speed when the tension of the steel plate 220 is abnormal can be considered. Because of such a sudden occurrence, a task whose execution timing cannot be set in advance is resident in one or a plurality of controllers 131 to 133. Since tasks that are fixedly assigned are expected to be executed unexpectedly, the task is subtracted from the load factor margin. Furthermore, the task simulator 111 is activated in S4-3, a task that is about to be completed is predicted from among the currently activated tasks by the calculation described later, and it is assumed that there is no task to be newly started. Predict the trend of load factor. In S4-4, the calculation result is returned to the task broker 102.
FIG. 7 shows an algorithm executed by the task simulator 111. The task simulator 111 stores the activation relationship of each task executed on the control object 150 in the form as shown in FIG. 8, for example. The contents of FIG. 8 are constructed by the user inputting from the input means 120 based on the driving plan at the time of system construction. If the programming language is an SFC (Sequential Functional Chart) or high-level language that is becoming popular as a control language, it can be automatically edited from a user program. Here, FIG. 8 shows a configuration in which each task is connected by a directed branch 803 via a synchronization gate 804, and the connection relationship indicates the task start / end relationship. A token indicated by a black circle in the figure means a task that is currently in operation, and in the figure, means that task 11, task 19, task 18, and task 5 are in an execution state. The tasks include an input waiting task 801 that performs synchronous management of task switching, such as task 102, task 122, and task 125, and a calculation task 802 that outputs a control calculation result to a control target and calculates a control command. An example in which two types are defined is shown. The task connection relationship shown in FIG. 6 is that the task 11 and the task 19 are parallel when the task 24 and the task 51, which are executed in parallel, are finished and then the steel plate deceleration timing is detected in the task 112. Is started. Furthermore, when a missing steel sheet is detected in task 102, the processing of task 11 and task 19 is terminated.
Furthermore, the task 18 and the task 5 are finished by this timing, and the task to be executed by the controller is transitioned to the next at the timing when the engagement of the steel sheet is detected in the task 125, and the task 71 and the task 85 are started simultaneously. . In S7-1 of FIG. 7, the current state of the control target 150 and the controllers 131 to 133 is sequentially grasped via the communication I / F 105, and the necessity of token transfer is determined in S7-2. When a task being executed by the controllers 131 to 133 is changed, token transfer processing is performed in S7-3. The task simulator 111 constantly repeats the processes of S7-1 to 7-3, and transitions the token arrangement of FIG. Further, the processes of S7-4 and S7-5 are activated by a command from the task broker 102. First, in S7-4, based on the task activation relationship and the current token distribution shown in FIG. 8, the tasks to which tokens are to be transferred next are extracted in time series. For example, in the case of FIG. 8, the task 125 is extracted first, and then the tasks 71 and 85 are extracted. In step S7-5, the extraction result is returned to the task broker 102, and the process returns to normal processing. Further, S7-6 to S7-7 are activated by a command from the controller simulator 110. In S7-6, a task with a current token is extracted, and when these tasks are finished is calculated. In the example of FIG. 8, task 11, task 19, task 18, and task 5 are extracted. Here, since task 11 and task 19 are repeatedly executed periodically until a steel plate dropout is detected, it is difficult to accurately calculate the end timing. Since the process is terminated after being calculated once, the end timing can be mechanically calculated by the amount of task computation. Therefore, for task 18 and task 5, the task calculation amount is calculated based on the size of the load module. In addition, the tasks 11 and 19 are calculated by estimating the timing at which the steel sheet is removed from the line operation information and past results. The result calculated in S7-7 is returned to the controller simulator 110.
Next, an operation algorithm of the task broker 102 is shown. FIG. 9 shows the execution contents of the system management means 112. The system management unit 112 normally performs the processes of S9-1 to S9-4, and periodically performs the processes of S9-5 to S9-8 by a timer interrupt or the like. First, in S9-1, whether or not a new task has been completed is determined based on whether or not task completion information has been sent from the controllers 131 to 133. The task end information is sent to the task broker in response to the task being completed by the controllers 131 to 133, and at least whether the task executed by the controllers 131 to 133 has been normally completed or not. Describes the contents, information to be taken over next time if necessary, time required for executing the task, and the like. In step S9-2, task end information is interpreted. In step S9-3, it is determined whether the task has been normally completed as a result of interpretation. If the task is abnormally terminated, the output means 121 is abnormal in S9-4 and the abnormality information obtained from the task completion information is displayed, and the process returns to S9-1. If the processing of S9-5 to S9-8 is activated by a timer interrupt or the like during execution of S9-1 to 9-4, the processing proceeds to S9-5. First, the activated task selection unit 113 is activated in S9-5, and after the task scheduled to be executed from the present time to the near future is extracted, the end of the process is determined in S9-6. The process is shifted to -7. The end of the process is determined based on the fact that a predetermined number of tasks have been extracted and that all tasks that may be executed after a predetermined time have been extracted. In step S9-7, the controller selection unit 114 is activated to determine a controller that executes the extracted task. After determining that the assignment of the controllers has been completed for all the tasks extracted in S9-8, the process returns to the normal process of S9-1 to S9-4.
Next, processing executed by the activated task selection unit 113 and the controller selection unit 114 will be described in detail. FIG. 10 shows an algorithm executed by the activated task selecting means 113. First, in step S10-1, the task simulator 111 is activated, and a task with the latest execution timing is extracted. The task simulator 111 extracts tasks according to the algorithm shown in FIG. In S10-2, it is determined whether or not there is a newly extracted task. If there is, a priority is assigned to each task in the order of execution timing in S10-3.
FIG. 11 shows a process executed by the controller selection unit 114. First, the controller simulator 110 is activated in S11-1, and the current load factor and load factor trend of each controller are detected. Next, in S11-2, the output of the activated task selection means 113 is received and assigned to the controller with the current low load factor in order from the task with the highest priority. In addition, a task activated at that time may be assigned to a controller whose load factor is expected to drop in the near future from the trend of the load factor regardless of the current load factor.
In the network scheduler 104, based on the information of the task to be executed most recently obtained by the calculation of the task broker 113, the execution timing, and the controller on which these are executed, the timing for downloading them to the controllers 131 to 133 is set. . FIG. 12 shows a flowchart of processing executed by the network scheduler 104. First, in S12-1, a download start time limit is set for a task newly assigned to the controller. The download end limit is in time for the start of the task execution, and the start limit is a time that is back from the end limit by the time required for download. Actually, the controllers 131 to 133 sequentially accept the load modules while waiting for the task shown in FIG. 6, so that the loading destination controller is engaged in task execution during the time required for loading. It is determined by adding. Next, network traffic is detected in S12-2, and it is determined at what timing until the download start time limit the task can be downloaded to the controllers 131 to 133 without excessive network traffic. In S12-3, the download timing of each task is set based on these results.
Next, as a second embodiment of the present invention, a configuration in which TMs (task memories) are provided in the controllers 131 to 133 will be described. In the embodiment, the controller 131 will be described as an example. TM1301 is provided in place of PM511 and is similarly connected to the local bus 515. The CPU 512 selectively executes the program written in the TM 1301 by the following method. In TM1301, tasks executed by the controllers 131 to 133 are collectively stored. FIG. 14 shows the configuration of TM1301. The stored contents are the same as the task storage means, and tasks 1 to n are stored in a form that can be executed by the controllers 131 to 133. The load balancer 100 operates in the same manner as in the first embodiment. However, since each task is already stored in the controllers 131 to 133, it is not necessary to download a load module corresponding to the task from the load balancer 100. Therefore, after the extraction of the task to be activated by the task broker 102 and the selection of the controller that executes the extracted task are completed, information indicating these is transmitted to the corresponding controller. FIG. 15 shows an example in which this information is encoded and transmitted. The task assignment code 1501 in FIG. 15 includes a controller number, a task number, and activation timing as an example. The controller number is information for identifying the controller on which the task is executed, and simultaneously indicates the transmission destination of the task assignment code. The task number is information indicating which task in TM1301 is executed. The activation timing specifies when the execution of the task starts. In addition to this, task priorities, end information when executed last time, and the like may be added as necessary. The task assignment code 1501 may be sent only to the controller indicated by the controller number, or may be sent to all of the controllers 131 to 133.
In this embodiment, the controllers 131 to 133 each store all tasks to be executed. However, if the same task is stored in a plurality of appropriate controllers, the same effect can be obtained. It becomes. Therefore, a method of selecting a controller to be stored for each task is also conceivable.
Next, as a third embodiment of the present invention, when one or more of the controllers 131 to 133 fail, the control of the control target 150 is continued by reconfiguring the task executed by the controller. Indicates the algorithm. FIG. 16 shows an embodiment in which the load distribution apparatus 100 is provided with an abnormality detection / processing unit 1601 that detects abnormalities in the controllers 131 to 133 and performs corresponding measures. In the figure, an abnormality detection / processing unit 1601 detects that an abnormality has occurred in the controller based on signals obtained from the controllers 131 to 133 via the communication I / F 105. As a detection method, the controller 131 to 133 knows the occurrence of an abnormality through self-diagnosis and voluntarily informs the load distribution apparatus 100 of this, and the abnormality detection / processing unit 1601 periodically sends the controller 131 to 133 with respect to each controller 131 to 133. Various methods are conceivable, such as a method of outputting an alive confirmation signal and knowing the occurrence of an abnormality on the side of the load balancer 100 based on a response to the signal. When an abnormality is detected, the abnormality detection / processing unit 1401 performs an abnormality process. Here, an example when the controller 131 has failed is shown. FIG. 17 shows the algorithm at this time. When the occurrence of an abnormality is detected in S17-1, the load ratio of the controller 131 in the controller simulator 110 is fixed to 100% in S17-2, and then the task broker 102 is activated in S17-3. As the processing of the task broker 102, basically the same algorithm as in the first and second embodiments may be executed. However, in order to increase the task switching response when an abnormality occurs, the following method is used. It is possible to do it. FIG. 18 shows a processing algorithm executed by the activated task selection unit 113 when the abnormality detection / processing unit 1401 is provided. First, in S18-1, the task simulator 111 is activated, and a task with the latest execution timing is extracted. The task simulator 111 extracts tasks according to the algorithm shown in FIG. In S18-2, it is determined whether or not there is a newly extracted task. If there is, a priority is assigned to each task in the order of execution timing in S18-3. Further, in S18-4, the above calculation result is output to the activated task storage means 1602. By providing the activation task storage unit 1602, when an abnormality is detected in the controllers 131 to 133, it is not necessary to activate the activation task selection unit 113 again, and it is only necessary to search the activation task storage unit 1402. Therefore, the process of redistributing tasks to normal controllers is simplified.
FIG. 19 shows an algorithm executed by the system management unit 112 after being activated by the abnormality detection / processing unit 1401. That is, in S19-1, a task to be activated is extracted from the activated task storage unit 1602. Next, in S19-2, the highest priority is assigned to the task executed by the controller 131. Thereafter, in S19-3, the controller selection unit 114 is activated. The controller selection means 114 assigns tasks and controllers according to the algorithm shown in FIG. When the assignment is completed, the assignment result is sent to the controllers 132 to 133 in the form of the task assignment code shown in FIG. 15 in S19-4. At this time, the task with the highest priority is set with the start timing to be executed immediately. Each of the controllers 132 to 133 sequentially executes the transmitted task according to the activation timing. As described above, the task of the controller 131 is distributed to the controllers 132 to 133, and the control of the control target 150 is continued. Furthermore, even if other controllers fail, control can be continued if the sum of the computation capacities of normal controllers is not exceeded.
10 MTBF (Mean Time Between Failure) of each controller including malfunction due to external noise ^-Four Assuming that the average downtime is 1h, the reliability and price merit of the system can be quantified as follows. The price merit is evaluated by the number of controllers. As a first example of a conventional system, a system in which ten controllers are operating at a load factor of 60%, a similar system realized by the present invention, and a second example of a conventional system (2 × 10) Consider a dual system consisting of controllers. In the first example of the conventional system, if any one of the 10 controllers fails, the system cannot operate completely. Therefore, the failure rate of the system matches the failure rate of the single controller. ^-Four / H. On the other hand, if each controller is tentatively operable at a load factor of 80%, in the system realized by the present invention, control can be performed by the dynamic load allocation described in the first and second embodiments. The number of controllers that can be continued is
80 × 10 / (60 × 10) = 7.5 (Expression 2)
It becomes. Therefore, since system failure occurs only when three or more controllers fail simultaneously, the system failure rate is approximately
_Ten C _Three (10 ^-Four ) ^Three = 1.2 × 10 ^-Ten ... (Formula 3)
Thus, reliability is greatly improved with the same number of controllers. In the second example of the conventional system, a system failure occurs when a failure occurs in two specific 20 controllers at the same time.
10 x (10 ^-Four ) ² = 1.0 × 10 ^-7 ... (Formula 4)
It becomes. In the present invention, a highly reliable system can be constructed with half the number of controllers as compared with the second example of the conventional system. The failure rate of the system realized by the present invention is that the number of controllers is N, the failure rate of the controller is p, the average value of downtime is T, the average load rate during normal operation is f ₁ , The load factor that can be executed instantaneously f ₂ Then, in general,
_N C _{[f2 / f1]} (PT) ^{[f2 / f1]} ... (Formula 5)
It is represented by [Α] represents the integer part of α.
In the present embodiment, the processing of the abnormality detection / processing means 1601 has been described by taking the configuration of the second embodiment in which TM1301 is provided in the controllers 131 to 133 as an example, but the same configuration is applied to the first embodiment. Can be realized.
In the above embodiment, the load distribution device 100 is dedicatedly provided in the control system. However, it is also conceivable to construct a system at a low cost by using it as a programming device or a system monitoring device. The load balancer 100 can be easily realized by using a general-purpose computer such as a workstation, a server, or a personal computer. Further, by providing one or more controllers with the system simulator 101 and the task broker 102, it is also possible to cause the load balancer 100 to perform processing.
The invention's effect
According to the present invention, even if one or several controllers fail, the control does not stop because other controllers perform switching of execution tasks at high speed and substitute processing. Therefore, a highly reliable control system that avoids system down is realized. In addition, since the load factor of the controller can be made uniform, there is no controller operating at an excessive load factor, and the system can be highly reliable in this respect as well.
In addition, since the processing margin of the controller can be set low, and thus the average load factor can be increased, it is possible to construct an inexpensive system with the total number of controllers reduced. In addition, since the same reliability can be obtained without performing multiplexing for each controller, the system can be similarly made inexpensive.
Furthermore, it is possible to continue the operation of the system by preparing a controller more than necessary at the time of system construction and performing a process in which no task is assigned to the controller if a failure occurs. As a result, replacement of the controller and maintenance work associated therewith can be omitted, and the running cost of the system can be reduced.
In addition, a task that is determined to be about to be started up by the system simulation is prepared for execution by the controller, and the execution starts immediately at the start timing, thereby minimizing the overhead required for executing the task. Therefore, it is possible to obtain the same performance as a conventional method in which tasks executed by the controller are fixedly allocated and these are made resident in the controller, and the system performance is not lowered.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a load distribution apparatus realized in the present invention.
FIG. 2 is a configuration diagram of a control target.
FIG. 3 shows the structure of the task storage means of the present invention.
FIG. 4 shows an algorithm executed by the controller simulator of the present invention.
FIG. 5 is a block diagram of the controller.
FIG. 6 shows an example of the operation of the CPU of the controller.
FIG. 7 shows an algorithm executed by the task simulator of the invention.
FIG. 8 shows task activation relationships held by the task simulator of the present invention.
FIG. 9 shows an algorithm executed by the system management means of the present invention.
FIG. 10 shows an algorithm executed by the activated task selection means of the present invention.
FIG. 11 shows an algorithm executed by the controller selection means of the present invention.
FIG. 12 shows an algorithm executed by the network scheduler.
FIG. 13 is a configuration diagram in which a task memory is provided in the controller.
FIG. 14 shows the configuration of the task memory.
FIG. 15 shows a task assignment code format.
FIG. 16 is a block diagram of a load distribution apparatus provided with abnormality detection / processing means.
FIG. 17 shows an algorithm executed by the abnormality detection / processing means.
FIG. 18 shows an algorithm executed by the activated task selection means when the abnormality detection / processing means is provided.
FIG. 19 shows an algorithm executed by the system management means after being activated by the abnormality detection / processing means.
Explanation of symbols
DESCRIPTION OF SYMBOLS 101 ... System simulator, 102 ... Task broker, 103 ... Task storage means, 130 ... Network, 131, 132, 133 ... Controller.

Claims

A distributed control system including a plurality of controllers that repeatedly capture a state of a control target and output a signal determined by executing a task provided in advance to the control target, and the plurality of controllers are connected via a network In
A system simulator for storing a start relationship of the tasks to be controlled and identifying a task that is about to be executed in the near future based on information on the start relationship of the task and information on a task currently being executed by the controller; and the plurality of controllers A task broker that determines a controller that executes the task specified by the system simulator;
The system simulator expresses an activation relationship in which each task is defined as a mutual activation order that defines the progress of the process as a directional branch connecting the tasks, and whether the task is being executed with or without a token. By expressing whether or not and tracing the transition of the token according to the directed edge, the task currently being executed is obtained, and the task to be executed in the future is obtained with priority, and the current A load factor is obtained and a future load factor of each controller is obtained, and the task broker decreases the current load factor and the future load factor in order from the highest priority task among the obtained priority orders. by assigning a controller, dispersion and determines the controller to perform the task to apply the task and該割be assigned Your system.

A distributed control system that repeatedly outputs a signal determined by capturing a state of a control target and executing a task provided in advance to the control target and controlling a plurality of controllers connected to each other via a network. In the control method,
Stores the activation relationship of the task to be controlled, identifies the task that is about to be executed in the near future based on the information regarding the activation relationship of the task and the information regarding the task currently being executed by the controller, and identifies the task from the plurality of controllers. Determine the controller that will perform the task
Representing the activation relationship in which each task is defined as the mutual activation order that defines the progress of the process as a directional branch connecting the tasks, expressing whether the task is being executed by the presence or absence of a token, By tracing the token transitions according to the directional branch, the task currently being executed is obtained, the tasks to be executed in the future are given priorities, and the current load factor of each controller is obtained. The future load factor of each controller is obtained, and the tasks to be assigned are assigned by assigning the current load factor and the controller with a lower future load factor in order from the highest priority task among the obtained priority orders. A control method of a distributed control system for determining a controller that executes a task to be assigned.