JP2008077265A - プログラマブルコントローラのプログラム更新方法 - Google Patents

Abstract

【課題】複数のプログラマブルコントローラによる運転中のプログラム一括更新を可能にする。
【解決手段】
マルチコントローラにおけるユーザからの運転中プログラムの更新の要求は、ネットワークへの運転中更新の要求の一斉同報メッセージに変換され、メッセージ伝送の帯域にて全てのプログラマブルコントローラに通知される。このような構成において、従来の（１）リードポインタ≠ライトポインタと言う条件に、（２）RUN中更新要求の有無も判定要素として加える事により、複数のプログラマブルコントローラのプログラムをスキャンエンド中に一括更新する。
【選択図】図５

Description

本発明は、プログラマブルコントローラのユーザプログラム更新に関するものであり、特に、運転中の複数のプログラマブルコントローラにおける複数のプログラムを同時更新する手法に関する。

プログラマブルコントローラは、FA(Factory Automation)などの用途に使われるコンピュータであり、その適用システムは、ユーザの要求仕様により、24時間稼動など極力停止が望まれないシステムが多く存在する。しかしながら、システムで稼動するユーザプログラムは、ユーザの単純なプログラムミスや動作仕様の変更、機器の経年変化による設定値の変更など、さまざまな理由により、プログラムの更新が要求される。

これらの条件を満たすため、プログラマブルコントローラにおいては、コントローラの運転中のプログラム更新（以下RUN中更新と呼ぶ）機能が具備されているものがある。現在、一般的に行われているRUN中更新には、その変更範囲からおおよそ以下の3パターンが考えられる。
・プログラム内の1命令(ステップ)単位で命令を置き換える。

・複数あるプログラムのうちの1プログラムを全て変更する。
・ひとつのプログラマブルコントローラにある複数のプログラムを同時に変更する。
ところで、近年のプログラマブルコントローラのメモリ容量大型化、処理の高速化により、ひとつのコントローラが同時に扱えるプログラムの本数は増加してきており、複数プログラムのRUN中更新機能は、その必要度が高くなりつつある。

複数プログラムのRUN中更新については、例えば特許文献１に記載されている。特許文献１の実施の形態について、図６〜図１０を用いて以下に説明する。
図６は、特許文献１におけるプログラマブルコントローラ・システムの概略構成図である。図６において、コントローラ支援装置１１０は、ユーザが所望の制御プログラムを作成する為に入力を行う入力装置１１２と、この入力内容等を表示する表示装置１１１、及び所定のアプリケーションプログラムを記憶するための記憶媒体１１３等を有する。コンパイラ１０１は、コントローラ支援装置１１０で作成された制御プログラムを、プログラマブルコントローラ１０３で実行できるコードに変換する。このようにして変換したプログラムコードを伝送装置１０２を介してプログラマブルコントローラ１０３に転送し、プログラマブルコントローラ１０３はこれを格納する。

このような構成において、プログラマブルコントローラ１０３の制御プログラムの格納方法について説明する。
プログラマブルコントローラ１０３は、図７（ａ）に示すプログラム情報テーブル１２１と、図７（ｂ）に示すプログラム変更要求キュー１２２と、図７（ｃ）に示すプログラムメモリ１２３を有する。

図６のコンパイラ１０１で変換されプログラマブルコントローラ１０３にて実行可能なコードとなった制御プログラムは、伝送装置１０２を介してプログラマブルコントローラ１０３側にロードされると、図７（ｃ）のプログラムメモリ１２３上に展開される。プログラムメモリ１２３上に置かれる制御プログラムは、ここでは登録された順番に前詰で展開される。プログラムメモリ１２３に展開された制御プログラムの番号とその格納場所の先頭アドレスは、図７（ａ）に示すプログラム情報テーブル１２１のプログラム番号１２１ａ、格納アドレス１２１ｂにそれぞれ格納される。図７（ｂ）のプログラム変更要求キュー１２２は、RUN中に複数の制御プログラムを一括更新する機能を実現するための構成であり、リードポインタ１３１、ライトポインタ１３２を有する。これについて、図８を参照して説明する。

図８は、コントローラのRUN中に２つのプログラム（ＰＧ３とＰＧ９）の更新要求があった場合の例である。コントローラ支援装置１１０側において、プログラムＰＧ３及びＰＧ９の更新版（旧バージョン等と区別する為、以下、Ｐ Ｇ３’、ＰＧ９’と記す）が作成される。コントローラ支援装置１１０は、このプログラムＰＧ３’とＰＧ９’とを、プログラムの更新要求と共にプログラマブルコントローラ１０３側に送信する。これを受信したプログラマブルコントローラ１０３は、これら更新版の制御プログラム（ＰＧ３’、ＰＧ９’）を、更新前の制御プログラム（ＰＧ３、ＰＧ９）と入れ替える処理であるプログラム更新処理を行う必要があるが、RUN中であるので、一旦、図８（ｃ）に示すようにプログラムメモリ１２３の最後尾（格納済みプログラム領域の後）にこれら更新版の制御プログラム（ＰＧ３’、ＰＧ９’）を格納する。この格納処理の間は、制御処理等は既存の制御プログラム(ＰＧ３、ＰＧ９)によって動いているので、特に書き込みのタイミングを意識する必要はない。格納が完了したら、これらのプログラム番号(ＰＧ３、ＰＧ９)と、プログラムメモリ１２３における格納場所の先頭アドレス（ＡＤＲ５、ＡＤＲ６）とを、図８（ｂ）に示す通りプログラム変更要求キュー１２２に書き込むと共に、そのライトポインタ１３２を進める（インクリメントする）。尚、プログラム番号は、更新前であっても更新後であっても同じであり、上記ＰＧ３’、ＰＧ９’等の表記は、あくまでも本説明を分かり易くする為のものである。

次にこのプログラム変更要求キュー１２２を認識し、制御プログラムの更新処理（ つまり、プログラム情報テーブル１２１の格納内容の更新）を行うが、これは全ての制御プログラムの実行が行われていないタイミングで行う必要がある。通常のプログラマブルコントローラ１０３は、プログラムへのデータ入力処理→プログラムの実行→プログラムからの結果出力処理を1スキャンとし、スキャンとスキャンの間にプログラマブルコントローラ１０３のシステムプログラムが処理を行う(以下、スキャンエンド処理という)。従って、制御プログラムの更新処理は、スキャンエンド処理中に行う必要がある。

図９は、スキャンエンド処理から呼び出されるRUN中更新処理フローチャートである。以下、図９の処理について、図８、図１０も参照しつつ説明する。
図８の処理では、まず始めにプログラム変更要求キュー１２２のリードポインタ１３１とライトポインタ１３２とを比較して、両ポインタが指す位置が一致するか否かを判定する（ステップＳ１１１）。両ポインタの位置が同じならばプログラム変更要求がないことになるので、処理を終了する。

一方、両ポインタの指す位置が違っていれば、プログラム変更要求あるので、以下の処理を行う。
まず、リードポインタ１３１が示すアドレスに格納されているプログラム番号（図８（ｂ）の例では最初はＰＧ３）を、変数Ｉに代入する。また、プログラム情報テーブル１２１の先頭アドレス（図８（ａ）の例では仮にＰｔｒ＿１とする）を、変数Ｊに代入する（ステップＳ１１２）。

変数Ｊが示すアドレス（最初は先頭アドレスＰｔｒ＿１）に格納されているプログラム番号１２１ａと変数Ｉの値とが等しいか否かを判定する（ステップＳ１１３）。もし両者が不一致であれば、一致するまで繰返し変数Ｊの値を進めていく（ステップＳ１１４）。Jの値の進め方は、例えば、Ｊ＝Ｊ＋１(バイト)等とする。これは、プログラム情報テーブル１２１には１バイト単位でデータが格納されているとした場合である。

変数Ｊが示す位置のプログラム番号１２１ａと変数Ｉの値とが一致したら、当該プログラム番号１２１ａに対応する格納アドレス１２１ｂの値を、プログラム変更要求キュー１２２のリードポインタ１３１が示す位置の格納アドレスの
値によって更新する（ステップＳ１１５）。ここでは、上記の通り最初はＰＧ３であるので、図８（ａ）では格納アドレス１２１ ｂにＡＤＲ２が格納されていたが、図１０（ａ）のようにＡＤＲ５へと変更される。

変更後、リードポインタ１３１を次に進める（ステップＳ１１６）。そして、再びステップＳ１１１の処理に戻り、リードポインタ１３１とライトポインタ１３２が一致するまで、上記ステップＳ１１２〜Ｓ１１６の処理を繰返し実行する。図８（ｂ）の例では、上記ＰＧ３以外にＰＧ９があるので、ＰＧ９についても上記処理を実行することで、図１０（ａ）、（ｂ）に示す状態になり、スキャンエンド処理を終了する。

上記の一連の処理が完了したときのプログラムメモリ等の状態を示したものが図１０である。図１０（ａ）のプログラム情報テーブル１２１は、ＰＧ３とＰＧ９に対応する格納アドレス１２１ｂがそれぞれＡＤＲ５とＡＤＲ６に更新され、図１０（ｂ）のプログラム変更要求キュー１２２は、リードポインタ１３１の位置がライトポインタ１３２の位置と一致している。更新後のプログラム情報テーブル１２１の内容により、図１０（ｃ）のプログラムメモリ１２３において、変更前のプログラムＰＧ３とＰＧ９が格納されている領域１４１，１４２は、空き領域として管理されることになる。

なお、特に図示していないが、プログラムメモリ１２３には、格納している各プログラムの最後を示す各ポインタが用意されている。よって、図１０（ａ）のプログラム情報テーブル１２１には、例えばプログラムＰＧ１の格納領域の先頭アドレス（ＡＤＲ１）のみが記憶されていても、上記ポインタによって、ＡＤＲ１〜ＡＤＲ２までの記憶領域に、プログラムＰＧ１が格納されていることが分かるようになっている。

以上、特許文献１には、複数プログラムの一括更新の方法が示されている。
特開２００６−２０２２３３号公報

近年では、システムの拡張性や、並列処理によるシステム全体処理の高速化、あるいはコントローラ単位での機能分割による構造化設計などの観点から、ひとつの制御システムにおいて複数のコントローラを配置し、これらを協調動作させて、一つのシステムを運用するマルチコントローラ方式を採用したプログラマブルコントローラシステムが登場している。このようなプログラマブルコントローラの一例として、出願人の製品であるMICREX-SXシリーズがある。このようなマルチコントローラ方式の制御システムでは、各プログラマブルコントローラ間で協調しながらシステムをコントロールするため、ユーザプログラムの修正は、複数のプログラマブルコントローラのプログラムに及ぶ可能性があるにもかかわらず、上記特許文献１のRUN中更新の方法では、高々一つのプログラマブルコントローラのプログラム変更までに限られており、複数のプログラマブルコントローラにまたがるプログラムの修正においては、一度システムを停止してから、全てのプログラマブルコントローラに対して修正したプログラムを格納し、システムを再起動する必要が生じる。

本発明は、複数のプログラマブルコントローラによって構成される制御システムのユーザプログラムを、システムを停止させずに更新することを目的とする。

上記の課題を解決する手段として、本発明は以下のように構成する。
第１に、複数のプログラマブルコントローラと1或いは複数の入出力モジュールとプログラマブルコントローラ支援装置とで構成される制御システムにおけるコントローラのプログラム更新方法であって、前記支援装置は前記プログラマブルコントローラ全てに更新用ユーザプログラムを送信した後、任意のタイミングでユーザプログラム更新要求を送信し、前記プログラマブルコントローラは、受信した前記更新用ユーザプログラムを一時メモリに格納した後、前記支援装置から更新要求を受けた時点がスキャンエンド中のときはユーザプログラムを前記一時メモリに格納した前記更新用ユーザプログラムに更新し、更新要求を受けた時点がスキャン処理中のときは次のスキャンエンドのときにユーザプログラムを前記一時メモリに格納した前記更新用ユーザプログラムに更新する方法。

第２に、ユーザプログラム更新要求を、前記プログラマブルコントローラへの割り込み信号にて制御する方法。

本発明により、これまで実現することのできなかった複数のプログラマブルコントローラによって構成される制御システムにおける、ユーザプログラムの同時RUN中更新が可能となる。これにより、複数のプログラマブルコントローラによって構成される制御システムのユーザプログラムを、システムを停止させずに更新可能になる。このことにより、システムの運転中にユーザプログラムの更新が随時実施可能になり、制御システムのダウンタイム等の無駄時間の削減にもつながる。

以下、本発明を実施するための最良の形態について、図面を参照しながら説明する。
図１は、本例で用いられるマルチコントローラ（複数のプログラマブルコントローラ）の構成の一例を説明したものである。パソコン１１は一般的なパソコンであり、このパソコン１１にはプログラマブルコントローラを支援する図示しない支援ツールが格納されている。パソコン１１と支援対象のプログラマブルコントローラ１２は、ケーブル１６で接続されている。また、プログラマブルコントローラ１２〜１４と制御対象となる入出力モジュール１５は、制御用ネットワーク１７で接続されている。

制御用ネットワーク１７の一例としては、前述のMICREX-SXシリーズで使用しているSXバスなどがある。SXバスはリング型のトポロジを持ち、トークンバス方式の独自通信方式を使用することで、プログラマブルコントローラと入出力モジュール間のデータ交換を行っている。リング上のマスタ局はデータの送受信を行い、スレーブ局がその送受信データに基づき自局宛のデータを更新する。通常、マスタ局をプログラマブルコントローラ、スレーブ局を入出力モジュールとする。

マスタ局は入出力データのみならず、プログラマブルコントローラ間のアプリケーションデータの交換や、システム起動・停止・リセットなどのシステム全体の制御のため、メッセージのやり取りを行う。これらのデータをリング上で伝送することで、システムとしてタイミングの同期を計りつつ、データの更新を行っている。
図２は、ネットワーク上を流れるデータフローの一例を説明したものである。ここでは説明を容易にするために、
プログラマブルコントローラ２台と、入出力モジュール２台とする。また、データフレームもデータ部のみを記載しているが、実際のデータではネットワーク制御データやエラーチェック用データなどが前後に付随する。

SXバス２１はリング型のトポロジを持つため、各モジュールを一巡した後、元に戻る構成となる。データやメッセージは図中の矢印の方向に流れるものとすると、プログラマブルコントローラ２２→入力モジュール２３→プログラマブルコントローラ２４→出力モジュール２５→プログラマブルコントローラ２２の順にデータが流れる。
プログラマブルコントローラ２２は、ネットワークへのデータ出力タイミングとなったら、内部で行った演算結果とプログラマブルコントローラ２４へのメッセージを格納したデータフレーム２６を出力する。このとき必要であれば入力の要求も合わせて格納する。このデータを受け取った入力モジュール２３は、入力要求を確認し、データフレーム２６に入力データを格納したデータフレーム２７を出力する。データフレーム２７を受け取ったプログラマブルコントローラ２４は、内部で行う演算のため更新された入力データと自局宛のメッセージをプログラマブルコントローラ内部のＲＡＭ２１１へコピーし、データフレーム２８を下流へ送信する。出力モジュール２５は、データフレーム２８を受け取り、自局宛の出力データをモジュール内部のＲＡＭ２１２へコピーし、データフレーム２９を下流へ送信する。出力モジュール２５は、コピーしたＲＡＭ２１２のデータをモジュールに接続された機器へ出力する。このようにして、SXバス２１に接続されたモジュールはデータの交換を実施する。

図３は、SXバス上で使用するプログラマブルコントローラの概略ハードウェア構成を説明したものであり、制御ネットワーク関連部分のみ記載している。プログラマブルコントローラ３１は、ユーザアプリケーションを実行するＣＰＵ３２のほかにSXバス３６を制御するための専用ＬＳＩ３４を持つ。ＣＰＵ３２と専用ＬＳＩ３４は内部バス３３で通信し、データの送受信バッファを持つＲＡＭ３５を共用する。ここで、ＲＡＭ３５をアクセスする際の調停回路も専用ＬＳＩ３４に含まれているため、ＣＰＵ３２はＲＡＭ３５に専用ＬＳＩ３４を経由して接続されている。

SXバス３６からデータが入力される場合は、ＣＰＵ３２からのアクセスを抑制し、ＲＡＭ３５のバッファへデータを格納する。逆にSXバス３６へデータを出力する場合も、ＣＰＵ３２からのアクセスを抑制し、ＲＡＭ３５上の出力バッファからSXバス３６へデータを出力する。専用ＬＳＩ３４によって送受信されるバッファとユーザプログラムが演算の結果を反映する入出力メモリ領域は、SXバス３６へのデータの送受信中に不用意にユーザプログラムによって変更されることを防ぐため、別領域として定義している。

図４は、SXバスの処理とユーザプログラム処理を説明したものであり、送受信したデータとユーザアプリケーションの入出力メモリとの、データ交換のタイミングを示している。点線で囲んだ、上段のユーザプログラム処理４７、下段のバス処理４６、それぞれに対して、左から右への時系列が流れている。
ユーザアプリケーションは、入力モジュールからのデータを取り込み、演算を実行した後、出力モジュールにデータを送ることで一連の演算処理を完了する。この一連の処理を行う期間をスキャン４０１と呼ぶ。また、スキャンとスキャンの間の期間をスキャンエンド４０２と呼び、この期間ではコントローラの管理（異常監視やシステム制御処理）を行う。

スキャン開始までにSXバスから入力データをアプリケーションに提供するため、まず入力データ読み込み４１にて入力データーを読み込み、アプリケーションの入力データ領域４５にコピーする。その後、アプリケーションの出力データ領域４４から前回の出力データを出力データ書き出し４２にてバッファへ書き出す。これらの出力処理から次の入力処理までの空き時間にメッセージ伝送４３にてメッセージを送受信する。通常のメッセージはコントローラ間で1対1の通信となるので、送信相手局番を指定して発信されるが、特殊な局番を指定することにより、全局に対してメッセージを送ることができる（例えば、システムの起動、停止はこのようなメッセージを使用する）。

なお、データ読み込み、書き出し、メッセージ伝送の一連の処理は、バス帯域４０３で示されるように、一定サイクルで繰り返される。
SXバス３６上では、入力データ読み込み４１、出力データ書き出し４２、メッセージ伝送４３の各データが一つの塊となって、コントローラおよび入出力モジュールを順次通過する。また、SXバス３６はリング型のトポロジなので、自身の出したメッセージが正常に戻ってきたならば、全てのプロセッサにメッセージが送られたことが分かる。

次に、本発明で用いるプログラマブルコントローラ単体のRUN中更新方法について説明する。プログラマブルコントローラ単体におけるRUN中更新方法は、例えば、図７〜図１０おける従来例を用いても構わない。ここでは、従来例と対応する部分は同一の符号を用い、異なる点を説明していく。
RUN中更新の一連の動作はダウンロードフェーズと切り替えフェーズとからなる。ダウンロードフェーズとは、コントローラ支援装置１１０からコントローラの運転中にプログラムのダウンロードが行われると、プログラムメモリ１２３の空き領域にプログラムを格納し、プログラム変更要求キュー１２２にプログラム情報を格納する動作である。

切り替えフェーズとは、ダウロードフェーズに引き続きなされる処理で、コントローラのスキャンエンド処理中でプログラム変更要求キュー１２２のリードポインタ１３１とライトポインタ１３２を比較し、これが異なっていた場合、RUN中更新の要求ありとして、プログラム情報テーブル１２１の内容を更新する動作である。
本発明では、前記切り替えフェーズにて、RUN中更新を行うか行わないかの判断をキューのリードポインタ１３１、ライトポインタ１３２の不一致だけでなく、ユーザからのRUN中更新の要求の有無もあわせて判定しRUN中更新を行う。即ち、図５のステップＳ５１で示すように従来の（１）リードポインタ≠ライトポインタと言う条件に加え、（２）RUN中更新要求の有無も判定要素としている。

このとき、ユーザからのRUN中更新の要求は、更新対象となる全てのコントローラに更新用プログラムをダウンロードした上で、ユーザがコントローラ支援装置１１０より発行する。発行されたRUN中更新の要求は、コントローラ支援装置１１０が接続されたプログラマブルコントローラ１２において、ネットワークへのRUN中更新の要求の一斉同報メッセージに変換し、図４のメッセージ伝送４４の帯域にて全てのプログラマブルコントローラに通知される。

SXバスは前述のようにリング型のトポロジであって、送信されたメッセージは次のデータが送信されるまでの間に全てのプログラマブルコントローラに送られる。各プログラマブルコントローラでは、スキャン４０１においてRUN中更新要求メッセージを受け取るので、その次のスキャンエンド４０２において、図５に示すスキャンエンド処理を実施することができる。このスキャンエンド処理で行う作業は、テーブルの登録データの更新だけなので、スキャンエンド４０２の処理期間内で十分に実行可能である。よって、次のスキャン４０１においてはメッセージを送信したコントローラを含め、全てのコントローラのプログラムが切り替えられている。

本実施例では、使用するネットワークとしてSXバスを挙げたが、これは発明を制限するものではなく、制御システム内の複数のプログラマブルコントローラに対して、一定の期間内に一斉同報通信が可能であればどのようなネットワークであっても構わない。即ち、プログラマブルコントローラのアプリケーションの実行時間帯域が、スキャン４０１とスキャンエンド４０２の処理から構成されており、一斉同報通信がプログラマブルコントローラのスキャン４０１の処理期間内に他の全てのプログラマブルコントローラに通知できればよい。従って、ネットワークのトポロジがリング型である必要はなく、バス型、スター型などのネットワークでもよい。

また、プログラムRUN中更新の要求のメッセージは、事前に準備されている更新用プログラムと現在運転中のプログラムについて、更新切り替えのタイミングを通知するだけのメッセージであるので、ネットワークを用いたメッセージでなくともよい。例えば、プログラマブルコントローラ間を割込み信号線で接続し、RUN中更新要求割込みを発行することで代用しても構わない。

マルチコントローラの構成の一例を示す説明図 ネットワーク上を流れるデータフローの一例を示す説明図 プログラマブルコントローラの概略ハードウェア構成の説明図 バス処理とユーザプログラム処理の説明図 本発明のRUN中更新処理フローチャート プログラマブルコントローラシステムの概略構成図 （ａ）プログラム情報テーブル、（ｂ）プログラム変更要求キュー、（ｃ）プログラムメモリ、の構成をそれぞれ示す説明図 RUN中に2つのプログラム更新要求があった場合のデータ格納状況を示す説明図 従来技術のRUN中更新処理フローチャート RUN中に2つのプログラム更新要求があり、RUN中更新処理実行後のデータ格納状況を示す説明図

符号の説明

１１…パソコン
１２、１３、１４、２２、２４、３１、１０３…プログラマブルコントローラ
１５…入出力モジュール
２３…入力モジュール
２５…出力モジュール
１６…ケーブル
１７…制御用ネットワーク
２１、３６…SXバス
２６、２７、２８、２９…データフレーム
２１１、２１２、３５…ＲＡＭ
３２…ＣＰＵ
３３…内部バス
３４…専用ＬＳＩ
４１…入力データ読み込み
４２…出力データ書き出し
４３…メッセージ伝送
４４…出力データ領域
４５…入力データ領域
４６…バス処理
４７…ユーザプログラム処理
４０１…スキャン
４０２…スキャンエンド
４０３…バス帯域
Ｓ５１、Ｓ１１１〜Ｓ１１６…RUN中更新処理のステップ
１０１…コンパイラ
１０２伝送装置…コンパイラ
１０３…プログラマブルコンロトーラ
１１１…表示装置
１１２…入力装置
１１３…記憶媒体
１２１…プログラム情報テーブル
１２１ａ…プログラム番号
１２１ｂ…格納アドレス
１２２…プログラム変更要求キュ―
１２３…プログラムメモリ
１３１…リードポインタ
１３２…ライトポインタ

Claims (2)

1. 複数のプログラマブルコントローラと1或いは複数の入出力モジュールとプログラマブルコントローラ支援装置とで構成される制御システムにおけるコントローラのプログラム更新方法であって、
   前記支援装置は前記プログラマブルコントローラ全てに更新用ユーザプログラムを送信した後、任意のタイミングでユーザプログラム更新要求を送信し、
   前記プログラマブルコントローラは、受信した前記更新用ユーザプログラムを一時メモリに格納した後、前記支援装置から更新要求を受けた時点がスキャンエンド中のときはユーザプログラムを前記一時メモリに格納した前記更新用ユーザプログラムに更新し、更新要求を受けた時点がスキャン処理中のときは次のスキャンエンドのときにユーザプログラムを前記一時メモリに格納した前記更新用ユーザプログラムに更新すること、
   を特徴とするコントローラのプログラム更新方法。
2. 請求項１に記載のコントローラのプログラム更新方法において、
   ユーザプログラム更新要求を、前記プログラマブルコントローラへの割り込み信号にて制御すること、
   を特徴とするコントローラのプログラム更新方法。

Images