(57)【要約】【課題】データ処理装置内の手順要素とプログラマブル制御装置内で実行される位相論理との間のインタフェースを標準化するための方法及び構成を提供する。【解決手段】バッチ制御のための第１のデータ処理装置302を有するシステムであって、該データ処理装置内302で作動でき、かつバッチ処理のための第１の状態機械308に従って作動できるサーバプログラム306と、サーバプログラム306に結合されるとともに第１のデータ処理装置302に結合され、第１の状態機械308に実質的に同一である第２の状態機械318に従って作動できる位相論理モジュール316とを備えたものである。【選択図】  図３
2010092497.tif 000002
【特許請求の範囲】
【請求項１】
バッチ制御のためのバッチ処理システムであって、
第１のデータ処理装置と、
上記第１のデータ処理装置内で作動できるサーバプログラムと、
上記第１のデータ処理装置に接続されるプログラマブル制御装置と、
上記第１のデータ処理装置内の上記サーバプログラムに結合される位相論理モジュールとを備え、
上記サーバプログラムは、バッチ処理のための第１の状態機械モデルに従って位相処理を実行し、
上記位相論理モジュールは、上記第１の状態機械モデルに実質的に同一である第２の状態機械モデルに従ってプロセス制御を提供するように上記プログラマブル制御装置内で作動できる、バッチ処理システム。
【請求項２】
上記位相論理モジュールが、上記バッチの処理に関係する補助的な制御のためのソフト位相論理モジュールを含んでなる請求項１に記載のバッチ処理システム。
【請求項３】
上記ソフト位相論理モジュールがその内部で作動できる第２のデータ処理装置と、
上記ソフト位相論理モジュールを上記サーバプログラムに結合する、上記第１のデータ処理装置と上記第２のデータ処理装置との間の通信リンクとをさらに備えた請求項２に記載のバッチ処理システム。
【請求項４】
上記ソフト位相論理モジュールが、上記第２の状態機械モデルの状態と関係づけられた、少なくとも１つの、ユーザによって定義された状態処理要素を含む請求項２に記載のバッチ処理システム。
【請求項５】
上記ユーザによって定義された状態処理要素が、標準プログラミング言語を使用して定義されている請求項４に記載のバッチ処理システム。
【請求項６】
上記ユーザによって定義された状態処理要素が、順次機能チャートを使用して定義されている請求項４に記載のバッチ処理システム。
【請求項７】
上記位相論理モジュールを上記サーバプログラムに結合する、上記第１のデータ処理装置と上記プログラマブル制御装置との間の通信リンクとをさらに備え、
上記位相論理モジュールが、上記バッチ処理に関係づけられた基本制御タスクを実行するために上記プログラマブル制御装置の内部で作動できる請求項１に記載のバッチ処理システム。
【請求項８】
上記位相論理モジュールが、上記第２の状態機械モデルの状態に関係づけられた、少なくとも１つの、ユーザによって定義された状態処理要素を含む請求項７に記載のバッチ処理システム。
【請求項９】
上記ユーザによって定義された状態処理要素が、順次機能チャートとして定義されている請求項８に記載のバッチ処理システム。
【請求項１０】
データ処理装置と、
バッチの処理のために第１の状態機械モデルに従って位相処理を実行するように上記データ処理装置内で作動できるバッチサーバプログラムと、
上記データ処理装置に接続されるように設けられたプログラマブル制御装置と、
上記第１の状態機械モデルに実質的に同一である第２の状態機械モデルに従ってプロセス制御を提供するように上記プログラマブル制御装置内で作動できる位相論理モジュールとを備えたバッチ制御システム。
【請求項１１】
上記位相論理モジュールと、関係づけられたバッチサーバプログラムとの間の通信のために、上記プログラマブル制御装置に結合された通信リンクをさらに備えた請求項１０に記載のバッチ制御システム。
【請求項１２】
上記位相論理モジュールが、上記第２の状態機械モデルの状態に関係づけられた、少なくとも１つの、ユーザによって定義された状態処理要素を含む請求項１０に記載のバッチ制御システム。
【請求項１３】
上記ユーザによって定義された状態処理要素が、順次機能チャートとして定義されている請求項１２に記載のバッチ制御システム。
【請求項１４】
バッチサーバに結合され、バッチサーバプログラムがバッチの処理のために第１の状態機械モデルに従って位相処理を実行するプログラマブル制御装置と、
上記プログラマブル制御装置内で作動できる位相論理モジュールとを備え、
上記位相論理モジュールは、上記第１の状態機械モデルに実質的に同一である第２の状態機械モデルに従ってプロセス制御を提供する、バッチ処理システム。
【請求項１５】
上記位相論理モジュールが、上記第２の状態機械モデルに関係づけられた、少なくとも１つのユーザによって定義された状態処理要素を含んでいる請求項１４に記載のバッチ処理システム。
【請求項１６】
上記ユーザによって定義された状態処理要素が、順次機能チャートとして定義されている請求項１５に記載のバッチ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自動プロセス制御に関し、特に、状態機械モデルに従って作動できる位相論理モジュールが、プログラマブル制御装置内、又はデータ処理要素内で統合されている、バッチ処理制御用の改善されたシステム及びバッチ制御装置モジュールに関する。
【背景技術】
【０００２】
[バッチ処理]
多くの種類の産業上のプロセスがある。停止されるまで連続して運転され、典型的には操業開始から操業停止までの間に非常に大量の製品を生産するものもある。ワークステーション間を１つのユニットとして移動するが各パーツはその独自の本質(identity)を維持しているパーツのグループに対し作用する産業上のプロセスもある。
【０００３】
第３の型の産業プロセスは、１又は複数台の装置を使用して原材料に加工ステップを受けさせ、「バッチ(batch)」毎の製品を生産することを含むバッチプロセスである。調理は、家庭で実施されているバッチプロセスの一例である。生の食品が準備され、鍋の中に入れられ、調理法に指定されている時間、調理され、最後には食べる準備ができた１皿、つまり「バッチ」として終わる。
【０００４】
ポリ塩化ビニルの調製は、産業規模で実施されている一例である。ポリ塩化ビニルは、塩化ビニールのはるかに小さい分子を重合する、つまり「いっしょに接合する」ことにより作られる。これは、バッチ反応装置(reactor)を適切なレベルまで塩化ビニル、溶剤及び重合誘導物質の混合物で満たし、該混合物を反応装置内で加熱し、結果として生じるバッチを冷却し、残りの開始物質を除去することによってバッチを精製することにより達成される。
【０００５】
これらは、バッチプロセスの数例にしかすぎない。一般的には、多くの異なる種類のバッチプロセスがある。それらは、複数の他の製品及び非製品向けプロセスはもちろん、例えば、製品製造、流通、及び試験プロセスを含む。[バッチプロセス制御]一般的に、バッチプロセスを制御することは重要である。ある例では、料理が調理中に長時間コンロの上に放置されると、料理は燃焼し、結果として生じる食べ物のバッチが破壊されるであろう。別の例では、塩化ビニルの反応混合物が十分に長く反応されないと、塩化ビニルの産出量は不適切となり、お金が失われるだろう。バッチプロセスの制御は、危険な化学物質やそれに匹敵するものの生産が関与する場合に重大となる場合がある。
【０００６】
バッチプロセスを制御する１つの方法は、手動である。すなわち、一人又は複数人の作業者が、すべてが計画に沿って進行していることを確認するためにバッチプロセスのすべての状況を監視するという仕事を割り当てられる。しかしながら、これは単調で退屈な作業であり、気付かぬうち誤差が入り込むことがある。
【０００７】
以上の及びそれ以外の理由から、バッチ制御の分野における作業者は、このところしばらく、電子機器を使用することによりバッチプロセスの制御を自動化しようとしてきた。コンピュータ、プログラマブル制御装置(programmable controllers)、及びそれに匹敵する電子装置が、バッチプロセスの制御を自動化するために、多くのバッチ制御システム供給業者によって、インテリジェントフィールドデバイス（つまり、インテリジェントセンサ及び制御可能弁(controllable valves)）とともに使用されてきた。
【０００８】
インテリジェントセンサは、典型的には１台の装置上に配置され、その装置の状態に関し、プラント内の中央制御室に報告する。制御可能弁は、典型的には、１台の装置への入力、又は１台の装置からの出力を制御し、多くの場合、インテリジェントセンサから受け取った情報に基づき、中央制御室から制御することができる。
【０００９】
バッチ処理を自動化する努力が、バッチ処理に関与する業界の構成員、及びとりわけバッチ処理装置の供給業者によって規格委員会の形成をもたらした。これらの規格委員会の全般的な目的は、自動化されたバッチ処理の統一した規格を定義することであった。
【００１０】
１つのこのような規格は、プロセス制御の問題に関係する国際組織である、国際測定制御学会（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｏｃｉｅｔｙ ｆｏｒ Ｍｅａｓｕｒｅｍｅｎｔ ａｎｄ Ｃｏｎｔｒｏｌ）によって広められてきた。この規格は、バッチ制御第１部：モデル及び用語（Ｂａｔｃｈ Ｃｏｎｔｒｏｌ Ｐａｒｔ１：Ｍｏｄｅｌｓ ａｎｄ Ｔｅｒｍｉｎｏｌｏｇｙ）と題され、多くの場合、ＩＳＡ Ｓ８８．０１−１９９５規格（以下、本願では「Ｓ８８」と呼ぶ）と呼ばれている。
【００１１】
Ｓ８８．０１規格は、これらのモデル及びその要素(elements)を参照する際に使用するための用語だけではなく、自動化されているバッチプロセスで使用するための装置及び手順のモデルを定義している。Ｓ８８．０１規格は、大量の投入材料を、１台又は複数台の装置を使用して、限定された時間の期間に渡って、ある命じられたセットの処理活動にさらすことにより、限定された量の材料の生産に至るプロセスとして、「バッチプロセス」を定義している。「バッチ」は、バッチプロセスの一回の実行により生産されている、又は生産された材料として定義されている。
[手順モデル]
バッチ処理装置（つまり、弁、加熱器、混合機などの制御可能な要素）は、バッチを作るための手順に従って操作される。この出願においては、すべてのこのような装置は、装置、装置モジュール、処理装置、又は物理的要素と同義に呼ばれている。このような物理的要素を操作するための手順は、しばしば、Ｓ８８．０１規格によって「手順モデル」と呼ばれる。Ｓ８８．０１規格によれば、手順モデルは、手順の階層序列として構造化され、最高水準(level)はさらに低い水準のそれぞれを包含し、次に高水準はその下の水準のそれぞれを包含するなどとなる。この出願の目的のために特に重要なＳ８８．０１手順モデルの水準は、下がる順に、以下の通りである。すなわち、「手順(procedure)」、「単位手順(unit procedure)」、「動作(operation)」、「位相(phase)」である。
【００１２】
「手順要素」という用語は、本出願では、「手順」水準や手順モデルのそれ以外の単独の水準の実施形態又は実施だけではなく、Ｓ８８．０１手順モデルのこれらの水準のどの実施形態あるいは実施を呼ぶのにも使用される。
【００１３】
重要な最高水準の手順要素は、１つ又は複数の「単位手順」から構成され、「手順」と呼ばれる。順に、各単位手順は、１つ又は複数の「動作」から構成され、それらの「動作」は、順に、それぞれ１つ又は複数の「位相」から構成される。Ｓ８８．０１手順モデルは、他の階層水準の定義又は使用を排除しないし、各水準が特定のアプリケーションに存在することも要求しない。むしろ、Ｓ８８．０１規格は、自動化バッチプロセス制御に従った手順を記述するための幅広い標準化されたモデルを提供することを意図している。
【００１４】
図８は、Ｓ８８．０１規格により定義されている手順要素の階層関係を図に描いたものである。手順８００は、１つ又は複数の単位手順８０２から構成されている。各単位手順８０２は、１つ又は複数の動作８０４から構成されている。各動作８０４は、一般的には、１つ又は複数の位相８０６から構成されている。上述のように、各位相は、通常、バッチプロセスの所望の制御を実施するために、プロセスセル８２５と集合的に呼ばれる１つ又は複数のユニット(units)８２０（プロセス装置物理的要素の集合体）と通信可能に接続されている。また、上述のように、手順モデルの他のさらに高い水準の要素は、一般的には、さらに低い水準要素の抽象概念(abstractions)である（つまり、動作は、１つ又は複数の位相などの抽象概念である）。
[物理的要素と手順要素との連結(linkage)]
一般的には、手順要素は、パーソナルコンピュータ、ワークステーション、及びプログラマブル制御装置を含むデータ処理装置によって及びデータ処理装置において実行されるコンピュータプログラムとして与えられる。典型的な手順要素を実行すると、物理的要素を制御するために使用可能なデータ処理装置から電気的又は光学的な出力が生じる。該データ処理装置は、典型的には、その出力を、直接に、あるいは、ローカルエリアネットワーク又は広域ネットワークで間接的に、物理的要素に接続することにより、該物理的要素を制御するために使用可能なものである。
【００１５】
手順要素は、少なくとも１つの物理的要素に対し、「基本制御」を呼び出すことによって、その割り当てられたタスクを実行する。この種の制御は、物理的要素のある特定の所望の状態の確立、維持に専用のものである。基本制御は、例えば、貯留ビン要素内における材料の流れ、又は塩化ビニル反応装置要素内でにおける出発物質の加熱を開始又は維持するものである。
【００１６】
実際問題として、手順モデルの低い方の水準（つまり、位相）が、実際の物理的要素との実際の通信を実行し、それによって基本制御を呼び出したり、実行したりする。手順モデルのさらに高い水準は、本質的には、手順モデルの構成及び構造、ならびに物理的モデルをも改善するための抽象概念である。
[手順要素及び状態機械モデル]
状態機械モデル(state machine model)は、プロセス又は活動の状態(state)を記述するために一般的に使用される論理構造である。該モデルは、プロセス状態の間の遷移を引き起こす動作とともに、多くの該プロセス状態を記述又は定義する。あるプロセスの状態機械モデルは、その状態への初期遷移による特定の状態の下にあると言われている。ある特定のイベントが発生したり、ある特定のステータス(status；CPU及び周辺装置等の状態)が検知されると、状態機械モデルは、その特定のイベント又は検知されたステータスに対応する別の状態への遷移を行う。
【００１７】
状態機械モデルは、バッチプロセスの手順要素の動作を定義し及び実現するための有効な技法である。状態機械として定義され与えられた手順要素は、例えば、その関係づけられた状態機械が旧い状態から新しい状態へ遷移する場合に、作動を開始する。
【００１８】
Ｓ８８．０１規格は、標準状態機械モデルに従った手順要素の定義及び実現を許容する。Ｓ８８．０１規格はこのアプローチを命令しないが、それは、（さらに後述されるように）多様なベンダ(vndor；売り主)の製品の間でのより高度の相互運用性(interoperability)を可能にするために、プロセス制御業界で幅広く採用されてきた。状態機械モデルに従って手順要素が定義及び実現されているＳ８８．０１規格の現在の１つの商業的なアプリケーション(application)が、アリゾナ州８５０２９、フェニックス、ウェストデザートコーブアベニュー、２４２９（２４２９ Ｗｅｓｔ Ｄｅｓｅｒｔ Ｃｏｖｅ Ａｖｅｎｕｅ，Ｐｈｏｅｎｉｘ，Ａｒｉｚｏｎａ ８５０２９）にあるＰＩＤ社（ＰＩＤ，Ｉｎｃ．）のＯｐｅｎＢａｔｃｈTMという製品である。
【００１９】
ＯｐｅｎＢａｔｃｈでは、サーバプログラムが、手順要素を実行するデータ処理装置上で実行される。サーバプログラムは、１つ又は複数の状態機械モデルに従った手順要素の実行を調整する。手順、対応する単位手順、対応する動作、及び対応する位相は、サーバプログラムによってその各ステップを通して順次実行される。
【００２０】
位相がサーバプログラムによって起動されると、例えば、位相はプログラマブル制御装置内の位相論理インタフェースに起動要求を通信する。すると、プログラマブル制御装置は、位相に対する実際の状態論理を実行し、プロセス装置への通信により要求されたプロセス制御を実現する。
【００２１】
図７は、従来技術において現在知られている１つ又は複数の典型的な物理的要素と通信する典型的な位相を描いている。位相７０４は、データ処理装置７００上のバッチサーバプログラム７０２内で作動できる。状態機械モデル７０６は、ある標準状態モデルに従って、位相の動作を制御するために位相７０４内で作動できる。位相７０４は、通信経路７５０を介して１つ又は複数のプログラマブル制御装置７１０と通信する。プログラマブル制御装置７１０内のプログラミングされている命令が、プログラマブル制御装置７１０を使用する位相ごとに１つずつ、１つ又は複数の位相論理インタフェース(phase logic interface)７１２を与える。
【００２２】
各位相論理インタフェース７１２は、位相７０４との情報交換に、マッピングされた（写像された）レジスタ通信インタフェースを提供する。後述するマッピングされたレジスタ通信インタフェースは、多数のレジスタ７１８とレジスタの割当てのマップ７２０を含む。マッピングされたレジスタ７１８を通して交換される情報は、位相７０４内で作動している状態機械７０６と関連した所望の制御機能を実現するために、位相論理７１４によって用いられる。言い替えると、位相論理７１４は、データ処理装置内において、状態機械の動作を写す(mirror)ために、制御エンジニアにより設計されかつ与えられる。位相論理７１４と統合されている状態論理シーケンス７１６が、バッチプロセスを制御するのに必要な実際の制御シーケンスを実行する。
【発明の概要】
【発明が解決しようとする課題】
【００２３】
各製造メーカが、データ処理装置とプログラマブル制御装置との間で必要な情報を通信するために異なった手段及び方法を実現する場合に問題が生じる。このため、データ処理装置内の位相とプログラマブル制御装置内の位相論理インタフェースとの間の通信は、両方のプログラマブル制御装置が、本質的に同じ機能を実行したとしても、別のブランドのプログラマブル制御装置に必要とされる通信とは非常に異なる可能性がある。
【００２４】
その結果、プロセス制御設計エンジニアが、例えば、ある特定の位相がアレン−ブラッドリー（Ａｌｌｅｎ−Ｂｒａｄｌｅｙ）プログラマブル制御装置と通信できるようにするために大量のカスタムソフトウェアを設計、実現及び維持すると同時に、位相が例えばフィッシャー−ローズマウントシステムズ社（Ｆｉｓｈｅｒ−Ｒｏｓｅｍｏｕｎｔ ｓｙｓｔｅｍｓ Ｉｎｃ．）のＰＲＯＶＯＸプログラマブル制御装置と通信できるようにするためにまったく別個の大量のカスタムソフトウェアを設計、実現及び維持する必要があるということになる。この重複努力は、非効率的であり、無駄である。
【００２５】
さらに、従来技術において、多くの装置製造メーカに知られている共通通信インタフェースは、レジスタモデルである。位相論理インタフェースは、手順要素に対し、それ自身を、データ処理装置内の位相とプログラマブル制御装置内の位相論理インタフェースとの間で情報を交換するための、レジスタと読取り可能及び／又は書込み可能記憶場所(location)との大きなセットとして提供する。レジスタは、制御エンジニアによって、位相の制御に必要な側面に、論理的にマッピングされる（写像される）。位相の各レジスタに対し制御エンジニアによって定義される機能に対応する論理は、制御エンジニアによってプログラマブル制御装置の位相論理インタフェース内に与えられる。ある特定の位相によって使用されるレジスタのマップ(map；写像)は、制御エンジニアによって維持される。ある位相のレジスタのマッピングを文書化する上で役立つツールは存在するが、タスクは、主として手動タスクであって制御エンジニアの責任のままである。
【００２６】
バッチプロセスが変化し、進化するにつれて、レジスタマッピングのための文書が維持、更新されなければならない。これは、制御エンジニアにとっては、大部分が手動の別のプロセスである。さらに、１つのバッチプロセスに複数の位相がある場合、各位相は、その位相用の基本制御を実現するために、そのように論理的にマッピングされた多数のレジスタを使用する。大規模で複雑なバッチプロセスが、１つのバッチの生産に関与している、数千ではないにしろ数百の位相を定義することは普通のことである。各位相を文書化する有用なマップ、及び必要な制御を実行する上で使用されている、対応するレジスタを、作成し維持するというタスクは、実際には気力をくじくようなタスクである。
【００２７】
例えば、プログラマブル制御装置内の位相が、単独の位相に必要とされる制御シーケンスを実現するために、約１５のレジスタを活用することは典型的である。典型的なバッチプロセスは、１つのバッチの処理を実行するために約１００の位相を含む。従って、制御エンジニアには、最初に約１５００のレジスタを記述しているマップを定義し、維持する責任がある。さらに多くのプログラマブル制御装置が、さらに大きいバッチプロセスに使用される場合、及びさらに多くの位相が、さらに複雑なバッチプロセスに必要とされる場合に、マッピングされるレジスタ数は、相当大きくなりうる。
【００２８】
さらに、位相の状態機械モデルの様相は、その位相を実行しているデータ処理装置と、対応する装置モジュールのプログラマブル制御装置との間で通信されなければならない。本質的には、サーバプログラムの状態機械モデルの部分は、プログラマブル制御装置内で理解され、記憶される必要がある。これらの機能は多くの場合、プロセス制御エンジニアにより十分に理解されていないため、これが、さらにプログラミングとエンジニアリングのタスクを複雑にする。さらに、大部分のプログラマブル制御装置内で与えられている制御言語は、一般的には状態機械論理の実現には十分に適しておらず、一般的には異なった製造メーカによって開発されたプログラマブル制御装置の間では移送可能ではない。状態機械モデルを追跡するためのプログラム命令のいくつかは、位相ごとに制御論理を実現するために複写できるが、複製されるコードシーケンスは、しかしながら試験を必要とするだろう。命令シーケンスのそれぞれは、プログラマブル論理制御装置内で実現されている位相ごとの各状態でのバッチプロセスの適切な動作を保証するために、詳細な試験を必要とするだろう。
【００２９】
さらに、位相の処理で故障が発生すると、その位相を実行しているデータ処理装置と必要な基本制御を実行しているプログラマブル制御装置との間に適切な故障処理情報を通信するための標準技法が存在しないという点で、現在の技法には、問題が生じる。むしろ、再び、制御エンジニアは、独自の故障処理方法、及びそれに対応するプログラム命令、及び故障に関する制御情報を交換するための通信経路の設計及び維持を行う責任がある。
さらにまた、ある位相の処理が、規格外の装置での処理の実行を必要とする場合に、従来の技法には別の問題が生じる。例えば、位相は、その位相処理を実行するために一定の形式のユーザ（オペレータ）入力を必要とするかもしれない。その必要な入力は、キーボード、ディスプレイ、又はバーコードリーダーなどのユーザ入力装置から得ることができる。このような装置は、通常、データ処理装置内の位相と、プログラマブル制御装置内の位相論理インタフェースのと間で情報を交換する際に一般的に使用されているレジスタモデル通信規格を使用しない。それ故、現在の技法は、このような位相処理を実現するために、位相に対するさらに別の形式の通信及び処理を必要とする。
【００３０】
上記の議論から、位相制御情報及びそれに関連する状態と故障情報とを、データ処理装置内の手順要素（つまり、位相）とプログラマブル制御装置内の位相論理との間で通信するための改善された方法及び構造に対する必要性が存在することは明らかである。
【００３１】
本発明は、上記及びそれ以外の問題を解決し、それによってデータ処理装置内の手順要素（位相）とプログラマブル制御装置内で実行される位相論理との間のインタフェースを標準化するための方法及び構成を提供することにより、有用な技術の状態を前進させることを目的としている。
【課題を解決するための手段】
【００３２】
上記課題を解決するために、本発明のバッチ処理システム及びバッチ制御装置モジュールは、データ処理装置内で作動可能な位相の状態機械モデルに並行して作動し、かつ該状態機械モデルに実質的に同一である状態機械モデルに従って物理的要素の動作を規定する。
【００３３】
位相論理モジュール(Phase Logic Module(ＰＬＭ)）は、プログラマブル制御装置内に状態機械モデルを実現する。このＰＬＭは、データ処理装置内の位相と、プログラマブル制御装置内の位相論理との間に一貫したインタフェースを提供する。さらに、位相とＰＬＭとの間の通信インタフェースは、オブジェクト指向のソフトウェア設計を用い、それにより位相及びＰＬＭは、名前及び／又はＩＤ単位で関連付けられる。ＰＬＭオブジェクトの属性は、位相とＰＬＭとの間で必要な制御情報を通信するために使用される。通信プロトコルの詳細は、以下に説明される。本発明のこの観点は、制御エンジニアが、１つのバッチプロセス内の潜在的に大多数の位相のそれぞれに、潜在的に大多数のレジスタを記述する１つのレジスタマップを、最初に定義しかつ維持する必要性を排除する。
【００３４】
プログラマブル制御装置内のＰＬＭには、データ処理装置内の位相の状態機械モデルを写す状態機械が含まれる。従って、制御エンジニアは、データ処理装置内の位相により提供される現在の状態機械情報を追跡するために、プログラマブル制御装置でプログラミングされている命令を反復して実現する必要はない。むしろ、これらの命令は、制御エンジニアのシステム設計より前に、標準化されている方法でいったん与えられ、位相に対応する各ＰＬＭには単に具体化されるだけである。
【００３５】
さらに重要なことには、制御エンジニアは、特にサーバプログラムの状態機械の順序付けを写すために論理を設計する必要はない。むしろ、ＰＬＭの状態機械の様相(aspect)はあらかじめ決められており、制御エンジニアによって与えられる必要もなければ、制御エンジニアによって完全に理解される必要もない。むしろ、制御エンジニアは、標準状態機械モデルにおける状態間の各遷移に、バッチプロセスを制御するために必要とされる必須制御シーケンスを設計するだけである。このような制御シーケンスは、典型的には、順次機能チャート(sequentialfunction chart(ＳＦＣ)）、はしご形論理、構造化テキスト、あるいは制御エンジニアにとってよく知られているそれ以外のツール及び技法を使用して設計されている。
【００３６】
状態機械モデルを実現するＰＬＭの標準化されている部分は、ＰＬＭごとに複製されない。むしろ、単独の標準状態機械モデルは、そのそれぞれが、ある特定の位相のある特定の状態に必要とされる特殊な処理を表す複数のオブジェクト上で作動できる。それ故、本発明に従って与えられるバッチプロセスの試験要件は、プログラム命令の低減により低減される。状態機械を実現するプログラム命令は、その動作の各事例ごとに検証される必要がない標準モジュールとして設計されかつ実現される。
【００３７】
サーバプログラムによってデータ処理装置内で作動できる位相は、手順要素処理を記述する高水準プロトコルを使用してＰＬＭと通信する。通常は、サーバプログラムで与えられているように手順モデルのより高い水準によって手順要素に提供されている、状態遷移及びバッチプロセスに関係するそれ以外のパラメータは、本質的に、そっくりそのまま物理的要素に渡される。
【００３８】
本発明の別の観点は、プログラマブル制御装置以外のデバイスにおける位相処理（つまり、上記したようなユーザ対話位相）を実現するための状態機械に従って作動できるＰＬＭの実現を許容する。このような位相は、ここでは「ソフト位相」と呼ばれ、「ソフトＰＬＭ」と呼ばれるＰＬＭは、該デバイス内で上述の方法に類似する方法で作動する。ソフトＰＬＭは、サーバプログラム手順要素の状態機械と実質的に同一の状態機械に従って作動できる。ハードＰＬＭ（プログラマブル制御装置内で作動できるもの）の場合と同じように、ソフトＰＬＭは、状態遷移及びそれ以外のパラメータをサーバプログラムと交換する。
【００３９】
より詳しくは、ハードＰＬＭ及びソフトＰＬＭの両方とも、サーバプログラムの手順要素において与えられて状態機械と実質的に同一の状態機械に従って作動する。さらに、本発明に従ったＰＬＭは、従来の技法のレジスタモデルに比較して、さらに簡略な方法でサーバ内の手順要素と通信する。バッチ制御エンジニアは、標準作動状態のそれぞれに、ＰＬＭ内で所望の基本制御を実現するカスタムモジュールを設計する。標準状態機械自体、及び所望の制御タスクを遂行する、エンジニア（ユーザ）によって供給される要素は、組み合わされて、ＰＬＭを構成し、プログラマブル制御装置内で、又はソフトＰＬＭを実現するデータ処理装置内で作動できる。所望の処理を遂行するために必要とされるすべての必要な状態及びパラメータ情報は、サーバプログラムとの通信で受信される。
【図面の簡単な説明】
【００４０】
【図１】単独の位相と、嵌め込まれたＰＬＭが状態機械に従って作動できる本発明の装置モジュールとの間の基本制御関係を示すブロック図である。
【図２】Ｓ８８．０１規格に従って、及び本発明を実施するもっとも優れた現在知られているモードに従って、手順制御要素を記述する状態機械図である。
【図３】プログラマブル制御装置内のＰＬＭ内で作動できる状態機械モデルと通信するバッチサーバプログラム状態機械モデルを描いたブロック図である。
【図４】ユーザによって供給された要素が状態機械モデルの標準状態のそれぞれにおける論理を実現するために提供される、図３におけるようなＰＬＭの構造を示すブロック図である。
【図５】図４に示されるように、ＰＬＭ内におけるユーザによって供給された状態論理を記述するために使用され得る典型的な順次機能チャートを描いたものである。
【図６】単独の位相と、嵌め込まれたＰＬＭが状態機械に従って作動できる本発明のソフト位相との間の基本制御関係を示すブロック図である。
【図７】単独の位相と、それに対応する、従来技術において現在実践されている装置モジュールとの間の基本制御関係を示すブロック図である。
【図８】Ｓ８８手順モデルの要素の階層水準、及びＳ８８物理的モデルの要素の階層水準を示すブロック図である。
【発明を実施するための形態】
【００４１】
本発明は、多様な修正及び代替形式に影響を受け易いが、その特殊な実現例は、図面中の例証として示され、ここに詳細に説明されるであろう。しかしながら、本発明を開示されている特定の形式に制限することが意図されるのではなく、逆に本発明は、請求項により定められるような本発明の精神及び範囲に該当しているすべての修正、同等物、及び代替策を対象とすることが意図されることが理解される必要がある。
[分散バッチ処理の概要]
本出願の発明の概要は、図１及び図６に描かれている。
【００４２】
図１は、プログラマブル制御装置１０３内で作動できるＰＬＭ１００に、経路６６０を介して高水準の状態情報を提供する位相６１０（手順要素）を描いたブロック図である。より詳しくは、位相６１０は、状態機械１７０に従って作動できるのに対し、プログラマブル制御装置１０３内のＰＬＭ１００は、状態機械１０２に従って作動できる。上述のように、状態機械１０２は、状態機械１７０と実質的に同一である。２つの状態機械は、さらに以下に述べるように、高水準の状態情報の交換により経路６６０を介して通信する（通信リンク）。
【００４３】
従来の技法に比較すると、図１のＰＬＭ１００は、従来の装置モジュールとそれに対応する位相との間の通信に使用される非常に多数のレジスタをマッピングするための大量の文書化に対する必要性を除去する。むしろ、標準化された高水準のコマンド構造が使用され、以下にさらに詳細に説明される。
【００４４】
さらに、従来の技法に比較すると、ＰＬＭ１００は、標準的な、単独に実現された状態機械１０２を提供する。単独に実現された状態機械１０２は、１つ又は複数の状態論理シーケンス７１６で作動できる。言い替えると、各ＰＬＭ１００は、単独の状態機械１０２に従って作動する。しかしながら、各位相論理モジュール（PLM100)は、対応する位相６１０の各標準状態に要求される制御を実現するよう、制御エンジニアによって定義される独自の状態論理シーケンス７１６を含んでいる。
【００４５】
プログラマブル制御装置１０３は、ＰＬＭ１００内の状態機械１０２の指示を受けて作動しながら、プログラマブル制御装置Ｉ／Ｏ６７５と経路６７０を介して通信し、該プログラマブル制御装置Ｉ／Ｏ６７５は、所望の基本制御を遂行するために経路６８０を介してプロセス装置６８５と通信する。
【００４６】
上述のように、状態論理シーケンス７１６は、好ましくは、順次機能チャート（ＳＦＣ）、構造化テキスト、はしご形論理、又は当業者によく知られているようなその他の制御装置プログラミング言語として実現される。ＰＬＭ１００内の単独の標準状態機械１０２は、プログラマブル制御装置１０３とともに実現されているすべての位相に対して処理を遂行するために、１つ又は複数の状態論理要素７１６のそれぞれの代理として作動する。これは、従来技術で既に知られている状態機械モデルの、複数の、同様なしかし独立した設置を、試験する必要性を除去する。
【００４７】
図６は、ソフト位相１０４内で作動できるソフトＰＬＭ１０６に対し、経路１１２を介して高水準の状態情報を提供する、位相６１０（手順要素）を描いたブロック図である。より詳しくは、データ処理要素１０４内のソフトＰＬＭ１０６は状態機械１０８に従って作動できるのに対し、位相６１０は、状態機械１７０に従って作動できる。上述のように、状態機械１０８は、状態機械１７０と実質的に同一である。２つの状態機械は、さらに後述されるように、高水準の状態情報の交換により、経路１１２を介して通信する（通信リンク）。
【００４８】
図１に関して上述したように、図６のソフトＰＬＭ１０６は、標準的な、単独に実現された状態機械１０８を提供する。単独に実現された状態機械１０８は、各ソフトＰＬＭ１０６に対し独自(unique)である状態論理シーケンス７１６上で作動できる。図６のデータ処理装置では、状態論理シーケンス７１６は、好ましくは、当業者によく知られているような標準ソフトウェア要素として実現される。各ソフトＰＬＭ１０６内の単独の標準状態機械１０８は、データ処理装置１０４とともに実現されているすべての位相に対し処理を遂行するために、状態論理要素７１６に従って作動する。これは、従来技術で既に知られている状態機械モデルの、複数の、同様なしかし独立した設置を、試験する必要性を除去する。それから、データ処理装置１０４は、ソフトＰＬＭ１０６により必要とされる処理を遂行するために、経路３６０を介してデータ処理入出力装置３２２と通信する。
【００４９】
図３は、バッチ制御を実行するために本発明の教示に従って作動できる例示的なシステム３００を描いたものである。プロセスエンジニア又はそれ以外のユーザは、バッチクライアントプログラム３０４と対話することにより、データ処理装置３２４からバッチの処理を開始する。バッチクライアントプログラム３０４は、ユーザが、バッチのための処理を始動し、バッチの完了までの処理を制御することができるようにする、適切なユーザインタフェース（すなわちグラフィックユーザインタフェース、つまりＧＵＩ）を提供する。
【００５０】
バッチクライアントプログラム３０４は、プロセス間通信経路３５６を介して、バッチサーバプログラム（バッチ処理装置）３０６と通信する。バッチサーバプログラム３０６は、データ処理装置３０２上で作動でき、バッチクライアントプログラム３０４によって要求されたバッチを生産する責任を負う手順要素を始動し、監視する責任を持っている。従来技術で知られているように、バッチサーバプログラム３０６は、１つ又は複数の位相３０７を実現し、要求されているバッチを生産するための必要な処理ステップを実行する要素を含む。各位相３０７は、状態機械３０８に従って作動できる。さらに、複数のバッチサーバプログラム３０６が、製造企業又はその他のプロセス制御ネットワーク化された企業内で分散されていてもよい。このような分散されている環境における各バッチサーバプログラム３０６は、バッチプロセスの特定の部分集合(subset)又は企業内でのバッチ製造に責任を負っていることがある。
【００５１】
図３に示されるように、複数のこのようなバッチクライアントプログラム３０４は、普通、ワークステーション又はパーソナルコンピュータ、あるいは単にコンピュータと呼ばれているデータ処理装置３２４上で作動できる。さらに、当業者は、バッチクライアントプログラム３０４が、よく知られているネットワーク及び分散コンピューティング技法を介して通信している他のリモートワークステーション（図示せず）上で作動できることも容易に認識するであろう。反対に、バッチクライアントプログラム３０４は、バッチサーバプログラム３０６とともに１つのデータ処理装置上に、共同で格納されていてもよい。分散クライアント／サーバアプリケーションにおけるこのようなクライアント及びサーバプログラムの特定の分散は、当業者によく知られているように、大概不適切であり、分散プログラム及びデータ処理装置の多くの同等なトポロジー(topologies)が、本発明とともに使用されてよい。
【００５２】
当業者は、さらに、バッチクライアントプログラム３０４とバッチサーバプログラム３０６との間でのクライアント／サーバ通信を可能とするために、経路３５６を活用する多くのよく知られているプロセス間通信技法を認識するであろう。このようなプロセス間通信は、クライアント／サーバプログラム又はバッチプログラム３０４とバッチサーバプログラム３０６の両方が分散しているネットワークトポロジーの物理的な近接さに関係なく作動できる。
[分散バッチ処理の位相論理モジュール]
プログラマブル制御装置３１５は、ユーザワークステーション３０２内で作動できるバッチサーバプログラム３０６から受け取った手順指令に従ってバッチ製造プロセスで物理的な制御を提供する。本発明に従って、プログラマブル制御装置３１５は、嵌め込まれたＰＬＭ３１６を含んでいる。また、本発明に従って、ＰＬＭ３１６は、状態機械３１８に従って作動できる。特に、状態機械３１８は、バッチサーバプログラム３０６内で作動できる状態機械３０８と実質的に同一である。
【００５３】
さらに、本発明に従って、バッチサーバプログラム３０６内の状態機械３０８は、状態機械３１８と、経路３５０を介して、高水準の状態遷移及びバッチの処理に関するその他のパラメータ情報を交換する。
【００５４】
プログラマブル制御装置３１５内のＰＬＭ３１６は、プロセスエンジニアが、基本制御シーケンスの実行において状態情報を監視しかつ追跡する目的のためだけに大量のカスタムプログラミングを作成する必要性を除去するように、状態機械３１８に従って作動する。むしろ、本発明に従って、及び後述するように、状態論理モジュール(ＰＬＭ３１６)は、ＰＬＭ３１６内の特定の位相に対応する所望の基本制御を実行するよう、プログラマブル制御装置３１５と統合されている。それから、さらに、より低水準の基本制御コマンドが、経路３５２を介してプログラマブル制御装置プロセスＩ／Ｏ３２０に、及びそれから経路３６２を介してプロセス装置３４０に送信される。
【００５５】
図３に示されるように、複数のＰＬＭ３１６が、単独のプログラマブル制御装置３１５内に嵌め込まれていることがある。このような複数のＰＬＭ３１６のそれぞれが、バッチサーバプログラム３０６内の状態機械３０８に実質的に同一である状態機械３１８に従って作動する。さらに、このような複数のＰＬＭ３１６のそれぞれは、後述するように、そのそれぞれの位相に対する特定の基本制御シーケンスを実現するよう、ユーザによって供給された状態論理モジュールを含んでいる。
【００５６】
本発明を実施する、現在知られているもっとも優れたモードでは、プログラマブル制御装置３１５は、基本制御タスクを実行するようにプログラミングされる。プログラマブル制御装置３１５により実行される基本制御タスクは、ＰＬＭ３１６内で状態機械３１８と統合された、ユーザにより供給された状態論理要素に従っている。このようなタスクの順序付けも、ＰＬＭ３１６内の状態機械３１８に従っている。
【００５７】
データ処理装置３２６で作動できるソフトＰＬＭ３１０は、構造において、プログラマブル制御装置３１５内で作動できるＰＬＭ３１６と同様である。それらは、ソフトＰＬＭ３１０が、バッチサーバプログラム３０６の状態機械３０８に同一である状態機械３１２に従って作動できるという意味で同様である。ソフトＰＬＭ３１０は、機能及びそれにより実行される制御のタイプという点でＰＬＭ３１６とは異なる。特に、ＰＬＭ３１６は、上述のように、バッチ材料の物理的特性と属性、及び該バッチ材料を製造するためのプロセスに関する基本物理制御を提供した。対照的に、ソフトＰＬＭ３１０は、バッチの属性及び対応する製造プロセスの属性における物理的特性に、一般に間接的に関係する位相を実現する。このようなソフト位相の一例が、バッチ制御プロセスによって自動的には達成できない特定の属性や特性を決定するためにユーザ入力を得る位相である。さらに一般的には、ソフト位相は、バッチ及び該バッチを製造するためのプロセスに関係する、ユーザによって供給された情報を検証又は収集するために作動できる。従って、ソフトＰＬＭ３１０及びそれぞれの嵌め込まれている状態機械３１２は、経路３５８を介してバッチサーバプログラム３０６と交換されるコマンド及びパラメータに従って、経路３６０を介してユーザインタフェース装置３２２と対話する。
【００５８】
当業者は、ソフトＰＬＭ３１０が、図３に示されるようなバッチサーバから遠隔の分散コンピューティングデバイスで作動し得ること、あるいはバッチサーバプログラムと共同で格納され得ることを認識するであろう。よく知られているプロセス間通信技法は、種々のプロセスの物理的な近接さには関係なく、及びプロセスが分散されているデータ処理装置のトポロジーには関係なくこのような通信を可能とする。
[位相論理モジュール状態機械]
図２は、本発明に従った好ましい状態機械モデルを描いた状態機械図である。図２に描かれた状態機械はＩＳＡ Ｓ８８．０１規格において与えられた例示的な状態機械に準拠している。ＩＳＡ Ｓ８８．０１仕様に注記されているように、規格によって特定の状態機械モデルは要求されていない。むしろ、Ｓ８８．０１規格に記述されている状態機械モデルは、多くの有用なバッチプロセスを説明するための適切なモデルとして示唆されている。該規格は、種々の状態間の遷移だけではなく、モデル内の状態の追加又は削除を許容している。
【００５９】
上述のように、図２の状態機械モデルは、図３のバッチサーバプログラム３０６内、及びやはり図３に示されているプログラマブル制御装置３１５内に嵌め込まれているＰＬＭ３１６内の双方で実現されかつ嵌め込まれている。さらに、上記のように、ソフトＰＬＭ３１０（又は図６の１０６）もまた、実質的に同一である状態機械３１２（又は図６の１０８）に従って作動できる。
【００６０】
図２に示されている状態機械の動作の詳細は、以下の状態遷移表（表１）において与えられている。状態遷移表は、表の行内の状態機械の状態、及び表の列の遷移を引き起こすコマンドのそれぞれをリストしている。各行の各列との交差は、そこに新しい状態がリストされている場合には、状態機械が、対応するコマンドを受け取った後に、どの新しい状態に入るのかを示している。そのように新しい状態がリストされていない場合には、状態機械は新しい状態へ遷移しない。
【００６１】
状態機械モデル２００は、一般的に、アイドル状態２０２で初期化され、該アイドル状態２０２へリセットされる。遷移は、一般的に、取られるべき動作を示すコマンドに基づいて他の状態へなされる。このようなコマンドは、バッチサーバプログラム３０６内で作動できる状態機械３０８の場合には、例えば、バッチクライアントプログラム３０４を含む種々のソースから受け取られる。特に、ＰＬＭ３１０及び３１６内で本発明に従って作動できる状態機械３１２及び３１８に関しては、コマンド及びその他のパラメータが、データ処理装置３０２内でバッチサーバプログラム３０６から、それぞれ、経路３５０及び３５８を介して受け取られる。
【００６２】
ｓｔａｒｔコマンドは、運転状態２０４への遷移を引き起こす。運転状態２０４では、ユーザにより供給された状態論理が、バッチ材料が所望のパラメータに従って生産されるよう、適切なより低い水準の制御シーケンス（つまり、基本制御）を実行する。運転状態２０４にある間、ａｂｏｒｔコマンドは、打切り状態２０６及び最終的には打ち切られた状態２１８への遷移を引き起こす。同様に、ｓｔｏｐコマンドは、停止状態２０８、及び最終的には停止された状態２１６への遷移を引き起こす。ｈｏｌｄコマンドは、保持状態２２０、及び最終的には保持された状態２２２への遷移を引き起こす。運転状態２０４でバッチの所望の処理を完了すると、完了状態２１０への遷移が生じる。
【００６３】
完了状態２１０、打ち切られた状態２１８、及び停止された状態２１６は、全て、別のバッチプロセスを開始する準備を完了しているアイドル状態２０２に遷移を戻すために、リセットコマンドが要求される終端状態である。保持状態２２２は、運転状態２０４に戻ることによってバッチの処理が続行することがある中間状態である。具体的には、保持状態２２２から、ｒｅｓｔａｒｔコマンドが、再起動状態２２４、及び最終的には運転状態２０４への遷移を引き起こす。
【００６４】
【表１】
2010092497.tif 000003
上記状態機械表において、ＩＳＡ Ｓ８８．０１規格は、表の列として表の上部を横切ってリストされているコマンドの以下のような意味上の解釈を示唆している。
【００６５】
Ｓｔａｒｔ；手順要素に、正常な運転状態論理の実行を開始するように命令する。
【００６６】
Ｓｔｏｐ；手順要素に、停止状態論理を実行するように命令する。
【００６７】
Ｆａｉｌ／Ｈｏｌｄ；手順要素に、保持状態論理を実行するように命令する。
【００６８】
Ｒｅｓｔａｒｔ；手順要素に、再起動状態論理を実行し、安全に運転状態に戻るように命令する。
【００６９】
Ａｂｏｒｔ；手順要素に、打ち切り状態論理を実行するように命令する。
【００７０】
Ｒｅｓｅｔ；このコマンドは、終端状態からアイドル状態への遷移を引き起こし、新しいバッチの処理の始動を可能にする。ユーザによって供給されたどの状態論理も、このコマンド又はそれに対応する状態遷移には対応していない。
【００７１】
本発明の好ましい実施形態の上記状態機械においては、いくつかの状態及び遷移が、ＩＳＡ Ｓ８８．０１規格及び示唆の精神に留まりつつ、状態機械モデルを簡略化するために排除された。残ったコマンドの意味上の解釈は、表１に関して上述した通りである。追加のｆａｉｌコマンドは、上記に定義されたようにｈｏｌｄコマンドと同一に取り扱われる。ｆａｉｌコマンドは、バッチプロセスの処理での故障状態の検知を表す。従って、故障は、状態機械を実現する手順ＰＬＭに関して追加処理が発生しないように、処理を保持するためのユーザ要求と同じに処理される。
【００７２】
各ＰＬＭ内で実現されている状態機械における新しい状態への各遷移は、基礎バッチの処理を続行又は開始するよう、制御タスクを実行させる。上述の種々の状態に関係づけられた、ユーザによって供給された状態論理要素は、対応する状態への遷移が行われるときに実行される特定の処理を定義する。
【００７３】
図４は、ＰＬＭ３１０及び３１６、並びにそれぞれその中に嵌め込まれている状態機械３１２及び３１８の構造の付加的な詳細を与えるブロック図である。上述のように、ソフトＰＬＭ３１０とＰＬＭ３１６とは、そのそれぞれの状態機械３１２と３１８とのように、構造において同様のもである。さらに、上述のように、状態機械３１２及び３１８は、バッチサーバプログラム３０６内の状態機械３０８に実質的に同一である状態機械モデルを実現する。ソフトＰＬＭ３１０は、経路３５８及びサーバ通信要素４００を介してバッチサーバプログラム３０６と情報を交換する。同様の方法で、ＰＬＭ３１６は、経路３５０及びそれぞれのサーバ通信要素４００を介してバッチサーバプログラム３０６と通信する。
【００７４】
サーバ通信要素４００は、ＰＬＭ状態機械３１２及び３１８と、バッチサーバプログラム内の状態機械３０８との間のプロセス間通信に要求されるすべての必要な通信プロトコル及び情報を与える。通信に関連した情報における特殊なプロトコルのさらなる詳細は、以下に述べられる。
【００７５】
バッチサーバプログラム３０６から、サーバ通信要素４００を介して受信される情報は、状態機械制御要素４０２に転送される。状態機械制御要素４０２は、表１に関して上述した好ましい状態機械モデルを実現するために、基本的な状態機械制御及び処理を与える。ユーザによって供給された状態論理モジュール４０４ないし４１４は、表１の状態機械モデルの種々の特定の状態のそれぞれで実行される具体的な位相／状態処理を与える。
【００７６】
好ましい実施形態においては、ユーザ／エンジニアは、対応する状態へ遷移が行われるときに要求される低水準の処理を実行するプログラムされたモジュールを与える。特に、ユーザによって供給された運転状態論理モジュール４０４は、状態機械が図２の運転状態２０４で作動している間に、状態機械制御４０２によって実行される。ユーザによって供給された保持状態論理モジュール４０６は、状態機械が保持状態２２０で作動している間に、状態機械制御４０２によって実行される。ユーザによって供給された再起動論理モジュール４０８は、状態機械が再起動状態２２４で作動している間に、状態機械制御４０２によって実行される。ユーザによって供給された停止論理モジュール４１０は、状態機械が停止状態２０８で作動している間に状態機械制御４０２によって実行される。ユーザによって供給された打ち切り論理モジュール４１２は、状態機械が打ち切り状態２０６にある間に、状態機械制御４０２によって実行される。最後に、ユーザによって供給された故障監視論理モジュール４１４は、状態機械がどの状態で作動している間でも、状態機械制御４０２によって実行される。言い替えると、故障監視論理モジュール４１４は、状態機械３１２又は３１９の現在の状態に関係なく連続して作動できる。故障監視論理モジュール４１４は、各ＰＬＭ３１０又は３１６の作動中に故障状態がいつ生じるのかを判断するために作動できる。
【００７７】
状態論理モジュール４０４ないし４１４は、ソフトウェア又は他のプログラマブルモジュールという形でプロセス制御エンジニアによって供給される。これらは、典型的には、順次機能チャート、はしご形論理、構造化テキスト、又は制御エンジニアによく知られているそれ以外のツール及び技法を使用して設計される。さらに、Ｃ、Ｃ＋＋、Ｖｉｓｕａｌ Ｃ＋＋、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐａｓｃａｌ、Ａｄａなどを含むいくつかのよく知られたプログラミング言語のいずれも、ソフトＰＬＭの、ユーザによって定義された状態論理を構築するために使用され得る。
【００７８】
図５は、ユーザによって供給された「運転」状態論理モジュール４０４の一例を描いたものである。図５は、順次機能チャートの表現によって記述された運転状態論理モジュール４０４を示している。特に、要素５００は入口弁を開放するための処理を表すのに対し、要素５０２は、ステータス指示器(status indicator；状態指示器)が入口弁の開放状態を表すのを待つ処理を表す。次に、要素５０４及び５０６は、入口ポンプを起動する処理、及び入口ポンプが運転中であることを示すステータスを待つ処理を表す。要素５０８及び５１０は、入口ポンプに関係づけられたタンクの、所定の充填レベルまでの充填の完了を待つ処理を表す。それから、要素５１２及び５１４は、入口ポンプを停止する処理、及び入口ポンプの停止された状態を示すステータスを待つ処理を表す。それから、要素５１６及び５１８は、入口弁を閉鎖する処理、及び閉鎖が成功したことを示すステータスを待つ処理を表す。最後に、要素５２０及び５２２は、入口ポンプに関係づけられたタンク内で達成されている充填の実際のレベルを報告することにより、順次機能チャートを完了するための処理を表す。このような順次機能チャートは、バッチ制御又はプロセス制御の技術の当業者にはよく知られている。制御要素のシーケンスのこのような視覚的な表記は、市販されているコンピューティングツール及びソフトウェアツールによって、それぞれ、ＰＬＭ３１０又は３１６の中の状態機械３１２又は３１８の実行により該ＰＬＭ３１０又は３１６内で作動できる命令に変換される。
【００７９】
当業者は、図５に描かれている順次機能チャートが、図４のユーザによって供給された状態論理モジュール４０４ないし４１４を定義するために有効な例示的な任意のプログラミング言語又はその他のツールとしてだけ意図されていることを認識するであろう。状態論理モジュール４０４ないし４１４において、どのような制御動作のシーケンスも、エンジニアによって供給され得る。さらに、複数のよく知られているプログラミング技法のいずれも、特定の状態論理モジュールのために、順次機能のシーケンスをプログラミングすべく設計エンジニアによって使用され得る。
[サーバ／位相論理モジュールプロトコル]
本発明の通信プロトコルの態様は、バッチサーバプログラム内、及びＰＬＭ内で作動している実質的に同一の状態機械の間における情報交換を規定している。本質的に、該プロトコルは、バッチサーバプログラムとＰＬＭの状態機械との間における高水準の通信を規定する。バッチサーバプログラムは、要求されたコマンドによる状態遷移、及びＰＬＭ内に格納された状態機械に送信されるステータスを通信する。ステータス及びその他の情報が、ＰＬＭからバッチサーバプログラムに戻される。コマンドは、一般的には、オペレータ入力及びその他の入力並びにパラメータに従ってバッチサーバプログラムの状態機械により実行される状態変化を示している。
【００８０】
バッチサーバプログラムとＰＬＭとの間で交換される情報は、属性の中の値を読み書きすることによって通信される。該属性は、必要とされる通信を達成するために要求されたとおりに、サーバプログラム又はＰＬＭによって読み込まれたり、書き込まれたりする場所に過ぎない。この好ましい実施形態は、制御エンジニアによく知られているレジスタモデル構造を綿密に模倣する。それ故、この構造は、本技法に精通している制御エンジニアによって容易に学習されかつ理解される。しかしながら、上述のように、本発明の方法及び構造は、サーバプログラムとプログラミング制御装置との間の通信に、数百又は数千のレジスタのマッピングを必要としない。むしろ、所定の属性の１つのセットが、プログラマブル制御装置のＰＬＭ内で実現され作動できる単独の標準的な状態機械と関連して、この目的（サーバプログラムとプログラミング制御装置との間の通信）に役立つ。
【００８１】
サーバプログラムとＰＬＭとの間のすべての通信は、好ましくはサーバプログラムによって制御される。情報は、ＰＬＭによって使用される属性値を書き込むことによって要求されたとおりに、サーバプログラムからＰＬＭに伝送される。ＰＬＭから戻されるステータス及びその他の情報は、ＰＬＭによって適切な属性の中に書き込まれ、サーバプログラムによって読み取られる。サーバプログラムは、ＰＬＭ内の重要な属性値が修正されると、（ソフトウェアの通信層を介して）通知される。
【００８２】
好ましい、最も優れた、現在知られている本発明の実施モードにおいては、以下の属性が、バッチサーバプログラムとＰＬＭの状態機械との間で交換される。
ＢＣＯＭＭＡＮＤ
ＢＣＯＭＭＡＮＤ属性は、コマンドをＰＬＭに送信するために、バッチサーバプログラム（以下、ＳＥＲＶＥＲという）によって書き込まれる。属性部分（つまり、下位バイト）がコマンドコードを与えるのに対し、別の部分（つまり、上位バイト）がＳＥＲＶＥＲとＰＬＭとの間の信頼できる通信を保証するために使用されるシーケンス番号を与える。
【００８３】
より詳しくは、ＳＥＲＶＥＲは、下位バイト中に実際のコマンド値／識別子を、上位バイト中のＩＤ値を有するようにしてコマンドをＰＬＭに送信する。コマンド及びＩＤは、ＢＣＯＭＭＡＮＤ属性中に値を記憶することにより「送信」される。ＰＬＭはコマンドを受け取るとともに、コマンドが受け取られたというＳＥＲＶＥＲに対するフラグとして、下位バイトをゼロにクリアする。ＳＥＲＶＥＲは、最終的に、ＢＣＯＭＭＡＮＤの下位バイトがそのようにクリアされたことを検出し、それによって、ＰＬＭがコマンドを受け取り、処理したことを理解する。
【００８４】
例示的なコマンドは、ａｂｏｒｔ、ｈｏｌｄ、ｓｔｏｐ、ｒｅｓｅｔ、ｒｅｓｔａｒｔ及びｓｔａｒｔを含む。その他のコマンドは、ＰＬＭの試験及びデバッグにおいて有効であり得る。例えば、ｓｉｎｇｌｅ＿ｓｔｅｐコマンドは、同時に実行される１つの低水準の基本制御（あるいはそれ以外の低水準のステッピング（ｓｔｅｐｐｉｎｇ））によりＰＬＭのユーザによって供給された状態論理モジュールをデバッグするのに有効であり得る。あるいは、例えば、ｄｏｗｎｌｏａｄコマンドは、ＳＥＲＶＥＲを通して開発ワークステーションからＰＬＭ状態機械に新しいＰＬＭを新規にダウンロードするために有効であり得る。ＰＬＭが故障を検出し、（後述されるように）ｆａｉｌ＿ｉｎｄｅｘステータス属性を設定すると、ＳＥＲＶＥＲはｃｌｒｆａｉｌコマンドを送信し、「ラッチされている」故障状態をクリアする。なお、ａｃｋｒｅｑ及びｃｌｒｒｅｑなどの他のコマンドを、プロトコルのハンドシェイク(handshake)のペース調整及び信頼性を提供するために、ＳＥＲＶＥＲとＰＬＭとの間で使用してもよい。
ＢＳＴＡＴＵＳ
ＢＳＴＡＴＵＳ属性は、ＰＬＭの状態機械の現在の状態を反映するためにＰＬＭによって書き込まれる。ＳＥＲＶＥＲは、特定のＰＬＭの現在の状態を判断するために、この属性を読み取る。属性中に符号化されている状態は、表１に関して上述した通りである。
ＲＥＱＵＥＳＴ／ＲＥＱＤＡＴＡ１−５
ＲＥＱＵＥＳＴ属性及びＲＥＱＤＡＴＡ１−５属性は、ＳＥＲＶＥＲからの情報又はサービスを要求するために、ＰＬＭによって書き込まれる。ＳＥＲＶＥＲは要求に応答すると、ＲＥＱＵＥＳＴ属性をクリアし、要求の完了を示す。
【００８５】
好ましい実施形態においては、ＳＥＲＶＥＲからのサービスに対するＰＬＭによる要求は、以下の一般的なカテゴリに分かれる。
【００８６】
【表２】
2010092497.tif 000004
当業者は、上記に対する修正だけではなく上記表２に追加されることがある無数のそれ以外の要求を認識するであろう。
ＦＡＩＬ＿ＩＮＤＥＸ
この属性は、ＰＬＭの処理における故障の発生をＳＥＲＶＥＲに示すためにＰＬＭ（つまり、ユーザによって供給された故障監視状態論理モジュール）によって書き込まれる。ＳＥＲＶＥＲは、ＰＬＭ内の状態をクリアするためのｃｌｒｆａｉｌコマンド（及び最終的にはＰＬＭ状態機械を初期化し直すためのｒｅｓｅｔコマンド又はその他のコマンド）を、上記のように送信する。特定のタイプの故障及び該故障を表すコードは、ＰＬＭエンジニアの設計選択肢の問題である。
ＵＮＩＴ
ＵＮＩＴ属性は、それがＰＬＭと「接続する」ときにＳＥＲＶＥＲによって書き込まれる。複数のサーバが１つの特定のＰＬＭを使用する（つまり、異なったバッチを生産するために物理モデル装置を操作する）ので、この属性は、ＰＬＭに現在接続されているＳＥＲＶＥＲのＩＤを表す。
ＯＷＮＥＲ
この属性は、そのＳＥＲＶＥＲがそのＰＬＭを現在使用している（つまりそのＯＷＮＥＲ）なのか、別のユーザがそのＰＬＭを現在使用している（つまりそのＯＷＮＥＲ）なのかをＳＥＲＶＥＲに知らせるために、ＰＬＭによって書き込まれる。
ＳＴＥＰ＿ＩＮＤＥＸ
この属性は、それがユーザによって供給された状態論理モジュールのステップを通して順序付けされるにつれてＰＬＭによって書き込まれる。各ステップを識別するために使用される特定のコードは、設計選択肢の問題である。ＰＡＵＳＥこの属性は、ＰＬＭに、ある位相のある状態の現在の処理を一時停止するように指示するためにＳＥＲＶＥＲによって書き込まれる。
ＰＡＵＳＥＤ
この属性は、要求された一時停止が実際に達成されたことを、ＳＥＲＶＥＲに示すためにＰＬＭによって書き込まれる。ＳＥＲＶＥＲからのＰＡＵＳＥ属性は、ただちに達成されるのとは対照的に、次の機会に達成されてもよい。ＰＬＭ内の論理は、実行されている特殊処理に基づき、処理を一時停止することがいつ安全であるのかを決定する。
ＳＩＮＧＬＥ＿ＳＴＥＰ
この属性は、次のステップへの処理を続行するようにＰＬＭに命令するためにＳＥＲＶＥＲによって書き込まれる。処理の「ステップ」間の境界は、特殊な処理及びその安全性要件に基づいて、ＰＬＭによって決定される。
ＴＩＭＥ
この属性は、位相状態がアイドル状態から変化してから経過した時間を示す、ＰＬＭによって書き込まれる数値である。ＰＬＭが完了状態に遷移すると、時間値は増加を停止する（時間を、位相実行により消費された状態にしておく）。ｒｅｓｅｔコマンドは、該属性をゼロに戻す。
ＳＴＡＲＴ＿ＴＩＭＥ
この属性はＰＬＭによって書き込まれ、ＰＬＭが１つの特定の状態にある間に増加し、それによって現在の状態における経過時間を示す。
ＢＡＴＣＨ＿ＩＤ
この属性は、ＳＥＲＶＥＲによって書き込まれ、現在処理中のバッチのＩＤ値（つまり、文字列）を供給する。
ＷＡＴＣＨＤＯＧ
ＳＥＲＶＥＲは、定期的に、この属性中にゼロ以外の値を書き込み、ＰＬＭは、ゼロ以外の値を検出した場合にそれをゼロにクリアする。従って、この属性は、ＳＥＲＶＥＲが故障したＰＬＭを検出する（及びＰＬＭが故障したＳＥＲＶＥＲを検出する）ための監視機能を提供する。
ＸＣＯＭＭＡＮＤ
ある状況においては、ＰＬＭの命令を受けて作動している位相が、ＳＥＲＶＥＲによってよりむしろオペレータによって制御される（つまり、手動で制御される）ことがある。ＳＥＲＶＥＲがＢＣＯＭＭＡＮＤ及びそのシーケンス番号バイトを使用することに干渉するのを回避するために、ＸＣＯＭＭＡＮＤ属性は、ＰＬＭの作動を手動により制御するためにオペレータによって使用される。
【００８７】
当業者は、ＳＥＲＶＥＲとＰＬＭとの間の通信に同様の機能性を提供する上述の好ましいプロトコルに対する多くの変更及び追加を認識するであろう。上述した好ましい実施形態は、主に、それが制御エンジニアがすでに精通しているレジスタモデル通信の構造に似ている点で有益と見なされる。それ故、本発明のこのプロトコルは、本技法に精通している制御エンジニアによってさらに容易に学習される。
【００８８】
本発明は、図面及び上記説明において図解され説明されたが、このような図及び説明はその性質上例示的であり、制限的ではないと見なされなければならず、好ましい実施形態及びそのマイナーな変形だけが示され、説明されたこと、及び本発明の精神に該当するすべての変更及び修正が、保護されるよう望まれることが理解される。
【符号の説明】
【００８９】
１００ 位相論理モジュール
１０２,１７０ 状態機械
１０３ プログラマブル制御装置
１０４ データ処理装置
１０６ ソフトＰＬＭ
１０８ 状態機械
１１２ 経路
２００ 状態機械論理モデル
２０２ アイドル状態
２０４ 運転状態
２０６ 打ち切り状態
２０８ 停止状態
２１０ 完了状態
２１６ 停止された状態
２１８ うち切られた状態
２２０ 保持状態
２２２ 保持された状態
２２４ 再起動状態
３００ バッチ制御を実行するための本発明の教示に従って作動可能な例示的システム
３０２ データ処理装置
３０４ バッチクライアントプログラム
３０６ バッチサーバプログラム（バッチ処理装置）
３０７ 位相
３０８,３１２，３１８ 状態機械
３１０ ソフトＰＬＭ
３１５ プログラマブル制御装置
３１６ ＰＬＭ（位相論理モジュール）
３２０ プログラマブル制御装置Ｉ／Ｏ
３２２ ユーザインタフェース装置（データ処理入出力装置）
３２４,３２６ データ処理装置
３４０ プロセス装置
３５０，３５２，３５６,３５８，３６０，３６２ 経路
４００ サーバ通信要素
４０２ 状態機械制御
４０４ 運転論理モジュール
４０６ 保持論理モジュール
４０８ 再起動論理モジュール
４１０ 停止論理モジュール
４１２ 打ち切り論理モジュール
４１４ 故障監視論理モジュール
５００,５０２，５０４，５０６，５０８，５１０，５１２，５１４，５１６，５１８，５２０，５２２ 要素
６１０ 位相
６６０，６７０,６８０ 経路
６７５ プログラマブル制御装置Ｉ／Ｏ
６８５ プロセス装置
７００ データ処理装置
７０２ バッチサーバ
７０４ 位相
７０６ 状態機械
７１０ ＰＬＣ
７１２ 位相論理インタフェース
７１４ 位相論理
７１６ 状態論理モジュール
７１８ レジスタ
７２０ レジスタマップ
７５０ 経路
８００ 手順
８０２ 単位手順
８０４ 動作
８０６ 位相
８２０ ユニット
８２５ プロセスセル
【図１】
2010092497.tif 000005
【図２】
2010092497.tif 000006
【図３】
2010092497.tif 000007
【図４】
2010092497.tif 000008
【図５】
2010092497.tif 000009
【図６】
2010092497.tif 000010
【図７】
2010092497.tif 000011
【図８】
2010092497.tif 000012