JP2006139773A - プロセスコントロールシステムにおける装置調停方法およびシステム - Google Patents

Abstract

【課題】プロセスコントロールシステムにおける装置調停方法およびシステムの提供。
【解決手段】バッチ管理は、ユーザから、リソースへの要求を受取り（ブロック３００）、要求されたリソースのタイプがローカルかまたはグローバルかを判断する（ブロック３０２）。該リソースタイプがローカルならば、バッチ管理は、該リソースが入手可能であるかを判断するためにローカル装置アービトレータ（ＬＡＲ）にエリアについて問合せる（ブロック３０４）。該リソースタイプがグローバルならば、該リソースに適したグローバル装置アービトレータ（ＧＡＲ）に問合せる（ブロック３０６）。ＬＡＲまたはＧＡＲが該リソースが入手可能であるかを判断し（判断ブロック３０８）、該リソースが入手可能ならば、バッチ管理は、要求を承認し（ブロック３１０）、該要求されたリソースが入手不可能ならば、要求を拒否する（ブロック３１２）。
【選択図】図６

Description

本発明は、プロセスコントロールシステムに係り、より詳細には、バッチ処理アービトレーション（調停）に関する。

今日の社会においてコンピュータはその重要性を増すばかりであるが、これは、プロセスコントロールシステムにおけるコンピュータにも当てはまる。プロセスコントロールシステムは、バルブ、アクチュエータ、トランスミッタ、流量メータ、および他の処理コントロール及びモニタデバイスの動作をコントロールし、モニタする。

一般に、工場や他の生産プラントは、様々な製品を作るために使用される。例えば、テキサス州、オースチンのエマーソンプロセスマネージメント（Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ，ＬＬＰ）によって提供されるプロセスコントロールシステムなどのプロセスコントロールシステムは、製品を製造し、または、工程をコントロールする（例えば、製薬や発電所のコントロール）工場及び／又はプラントにおいて広く使用される。プロセスコントロールシステムは、例えば、石油及びガスの掘削及び処理工程などの自然資源の採取においても使用される。事実上のいかなる製造工程、資源採取工程、その他が一つ以上のプロセスコントロールシステムの適用を介して自動化され得る。

プロセスコントロールシステムによってコントロールされる他の一般的な製造工程は、バッチ処理である。一般に、バッチ処理は、材料を作るためのレシピを含む。例えば、バッチ処理は、一般に、薬剤や他の物質を製造するための製薬及び化学工業に使用される。一般に、バッチ処理を記述するレシピは、所望される物質の作り方を示す。例えば、ある特定の薬剤は、最初に二つの化学薬品を混合し、次に、この混合物を加熱することによって、作られる。レシピ全体は、たった一つの物質を作るために数百もの工程を経ることもある。レシピは、使用すべき材料、その割合、該材料は加熱すべきかまたは冷却すべきか、および所望される物質を生成するためにどの装置を必要とされるかを示すこともある。

バッチ処理は、しばしば、レシピ実行中のプラントにおいてデバイスの使用を管理することを含む。このようなシステムを管理することの繁雑性によって、多数のデバイスが、プロセスコントロールシステムの処理能力をオーバーロード（過負荷）し得ることから、以前より、プロセスコントロールシステムは、レシピ実行中に組み込まれるデバイスの全てをグローバルに管理することができなかった。

一般に、プロセスコントロールシステムに多数のデバイスへのレシピによるアクセスを同時に管理することを要求することによって、バッチコントロールシステムの処理能力がオーバーロードされることを防止するため、製造プラントは、多くの場合、エリアとして知られる装置の区別されたグループへ論理的に分離される。各エリアは、いくつかのデバイスを含み、多くの場合、いくつかの動作が指定される。従来、バッチコントロールシステムは、同一エリア内の他の装置によって同時に使用されることから、装置を保護するためだけに使用される。

一つの実施の形態において、プロセスコントロールシステムにおける装置調停のための方法およびシステムが提供される。該方法およびシステムは、第２のエリアに対応付けられた第１のリソースユーザから、第１のエリアに対応付けられた第１のリソースへの要求を受取る。第２のエリアは第１のエリアと区別され、該第１のリソースを第１のリソースユーザが使用するために入手可能であるかを自動的に判断する。

本発明の開示によって種々の技術的な利点が提供される。種々の実施の形態によれば、これらの技術的な利点の、すべてまたはその一部が提供されたり、全く提供されなかったりする。一つのこのような技術的な利点は、複数のエリアを介してレシピ実行するためのデバイスへのアクセスを管理する能力である。複数のエリアを介したデバイスのアクセスの自動管理を可能とすることによって、プラントの生産効率が高まる。

本発明の一つの態様は、第１のエリアとは区別される第２のエリアに対応付けられた第１のリソースユーザから、第１のエリアに対応付けられた第１のリソースへの要求を受取るステップと、第１のリソースユーザが使用するために第１のリソースを入手可能であるかを自動的に判断するステップと、を含むプロセスコントロールシステムにおける装置調停方法である。

本発明の一つの態様は、コンピュータ読取可能媒体上で符号化されるソフトウェアであって、第１のエリアとは区別されている第２のエリアに対応付けられた第１のリソースユーザから、第１のエリアに対応付けられた第１のリソースへの要求を受取り、第１のリソースユーザが使用するために第１のリソースを入手可能であるかを自動的に判断するように動作可能であるソフトウェアを含むプロセスコントロールシステムにおける装置調停システムである。

本発明の一つの態様は、第１のエリアとは区別されている第２のエリアに対応付けられた第１のリソースユーザから、第１のエリアに対応付けられた第１のリソースへの要求を受取る手段と、第１のリソースユーザが使用するために第１のリソースを入手可能であるかを自動的に判断する手段と、を含む、プロセスコントロールシステムにおける装置調停システムである。

多くの場合、プロセスコントロールシステムは、工業用プラントにおける種々のデバイスの動作をコントロールしモニタするためにさまざまな業種において使用される。プロセスコントロールシステムを使用する工業用プラントのタイプとして製薬施設がある。製薬施設は、ステップ・バイ・ステップ処理を介して薬剤などの特定の物質を大量に生成するためにバッチ処理技術を使用する。製油所を通して天然ガスの流量をコントロールするために使用される技術などの連続的な処理技術とは対照的に、バッチ処理技術は、薬剤を製造するための１５の分離した工程を特定するレシピなどの一続きの独立した順序付けられた工程を含む。各工程は、ヒータ、ベルトコンベア、タンク、ミキサー等の一台以上の装置の使用を必要とする。

特定のプラントは、略並列に実行される複数のバッチレシピを有し得る。例えば、あるレシピは、混合バットの使用を必要とするが、他のレシピには、保存容器内での加熱が含まれる。複数のレシピが同一装置を同時に使用しようとすることを阻止するために並列レシピを、調整する必要がある。例えば、他の物質が混合されている間、一つの混合バットに物質を添加することを防止したりすることによって、プロセスコントロールシステムは、従来におけるように同一装置を同時に使用しようしたために互いを台無しにさせてしまうことを阻止するために、レシピへの装置の割当てを管理してきた。

一般に、製造プラントは、バッチコントロールシステムの処理能力をオーバーロードするのを避けるために、「エリア」として知られている装置の個別グループへ論理的に分離される。各エリアには、いくつかの装置が含まれ、何らかの動作が指定される。バッチコントロールシステムは、同一エリア内で他の装置によって同時使用されないように装置を保護するにすぎない。従って、一つのレシピが複数のエリアから装置を要求した場合、該バッチコントロールシステムのオペレータは、進行中の異なるレシピによる単一の装置の同時使用が発生しないように進行中の処理をモニタする必要があった。

少なくとも一つの実施の形態において、本開示は、プラントの複数のエリアを介しての装置の管理をもたらす。該装置は、特定のエリア内でローカルに使用されるものとして、あるいは、複数のエリアを介してグローバルに使用されるものとして、マークされる。多くの場合、幾台かの装置だけが複数のエリアを介して必要とされ、一台の装置がローカルにまたはグローバルに使用されるかをマークすることによって、プロセスコントロールシステムは、装置のエリア内のみで使用される多数の装置をモニタすることによって、過度な負荷を掛けずに、これらのエリアを介して、装置を管理することができる。

図１は、本発明の開示の一つの実施の形態による統合プロセスコントロールシステムを示す。特に、図１に示されるように、処理プラント５０は、プロセスコントロールシステム５２、一つ以上のエリア５４、一つ以上のリソース５６、通信ネットワーク５８、および一つ以上のリソースユーザ６０を含む。処理プラント５０は、製薬または製造施設、精製または他の化学処理オペレーション、または他の好適なバッチまたは連続的な処理環境を備える。開示されている実施の形態において、処理プラント５０は、少なくとも一つのバッチ処理技術を使用する。

プロセスコントロールシステム５２は、通信ネットワーク５８を介して、リソース５６をコントロール、命令、モニタ、試験し、該リソース５６と通信し、および／または、そうでなければ、該リソース５６を使用するように動作可能なハードウェアおよび／またはソフトウェアを備えていてよい。例えば、プロセスコントロールシステム５２は、テキサス州、オースチンのエマーソンプロセスマネージメント（Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ，ＬＬＰ）によって販売されているＤｅｌｔａＶ^TM（デルタ ヴィ）であってもよい。一般的に、プロセスコントロールシステム５２は、リソース５６へのアクセスをコントロールし、リソースユーザ６０によるリソース５６の使用をスケジューリングする。通信ネットワーク５８は、プロセスコントロールシステム５２、エリア５４、リソース５６、およびリソースユーザ６０間でのデータ通信を支援するとともに、任意の所望されるバスベースおよび／またはノンバスベースのハードウェアを、単独でまたは種々に組み合わせて使用して、任意の所望されるハードワイヤード通信ストラクチャおよび／またはワイヤレス通信ストラクチャ、または、Ｅｔｈｅｒｎｅｔ（登録商標）（イーサネット（登録商標））、Ｆｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓ（ファンデーションフィールドバス）または、Ｐｒｏｆｉｂｕｓ（プロフィバス）プロトコルなどの他の好適な通信プロトコルを使用することによって実施され得る。

エリア５４は、処理プラント５０、リソース５６、およびリソースユーザ６０の論理的および／または物理的な編成を示す。一般に、バッチ処理環境において、最終製品または所望の製品はレシピとして知られる一連の工程を経て、作成される。一般に、エリア５４は、プラント５０において使用されるレシピの工程を実行する際に使用されるリソース５６を編成するために使用される。該エリア５４の編成は、プラント５０内のリソース５６の物理的位置、該プラント５０のリソース５６の論理的編成、または、リソース５６の物理的編成と論理的編成の組合せに基づいて行なわれることが好ましい。例えば、バッチ処理動作は、受取り、準備、処理、および出荷からなる分離エリア５４へ分割されてよい。前述の例に続いて、受取りエリアでは、製薬プロセスのための原材料が受け取られ、準備エリアにおいて変更され、処理エリアで、組み合わされ、処理され、目標とする薬剤を製造し、次に、得られた薬剤が包装され、出荷エリアから出荷される。該エリア５４内のリソース５６は、別の薬剤を製造するために使用される種々の装置などの異なるタイプの最終製品の製造工程の一部として使用され得る。一つの実施の形態において、該エリア５４は、リソース５６とリソースユーザ６０が多すぎると、プロセスコントロールシステム５２がこれらを単一グループとして処理できないという問題に実践的な解決策を提供することもできる。多数のリソース５６を管理するとともに他のプロセスをモニタするように該プロセスコントロールシステム５２に要求することによってプロセスコントロールシステム５２の動作が遅延することを防止するために、該エリア５４を使用して大規模レシピの処理を分割してもよい。例えば、コントロールシステム５２の処理能力は、プラント５０全体を介して管理されるべき大量のインタラクションによって超過されることもあるが、プラント５０全体を分離エリア５４へ分割することによって、インタラクションの数を減少させることができる。

リソース５６は、バルブ、タンク、ポンプ、ベルトコンベア、ミキサー、ヒータ、またはプラント５０内で実行される処理の一部として使用可能な他の好適なデバイスをそれぞれ含んでいてよい。リソース５６は、バッチ処理の異なる部分で任意の時間に異なるリソースユーザ６０によって使用され得る。例えば、特定のヒータリソース５６は、一つの最終製品のために第１の物質と共に使用され、洗浄され、その後、他の最終製品のために第２の物質と共に使用され得る。

リソースユーザ６０は、リソース５６を使用する物理的または論理的エンティティを示す。例えば、ユーザ６０は、特定の製品を作成するために特定の順序で該リソース５６を使用するプロセスコントロールシステム５２によって実行される特定のレシピを示すこともある。該リソースユーザ６０はそれら自体がリソース５６であってもよい。例えば、タンクリソースへのアクセスを要求する時、ポンプリソースはリソースユーザとして作動し、これによって、該ポンプリソースはタンクリソースを特定の材料で充填することができる。また、リソースユーザ６０は、製造工程自体の一部として使用される原材料などの材料を示すこともある。例えば、タンク内に現在保存されている第１の物質は、該第１の物質をレシピの一部としてヒータヘ移動させるためにポンプへのアクセスを要求してもよい。また、リソースユーザ６０は、プロセスコントロールシステム５２によって直接コントロールされない人間または他のエンティティでもよいが、該リソースユーザ６０が、該プロセスコントロールシステム５２からリソース５６へのアクセスを要求してよい。一般に、リソースユーザ６０は、プロセスコントロールシステム５２のコントロール下で製品を製造するためにプラント５０によって使用される、人間、材料、ハードウェア、ソフトウェアおよび／または他のリソース５６であってもよい。

動作上、一人以上の人間のユーザ（図示しない）が、プロセスコントロールシステム５２を用いて、一つ以上のレシピ、バッチ処理または他の処理の実行を構築し、コントロールし、モニタしてもよい。レシピは、一つ以上の所望の最終製品を作成するために処理プラント５０において入手可能なリソース５６を用いて実行される。プロセスコントロールシステム５２は、二人のユーザ６０が同一リソース５６を同時に使用することがないように、リソース５６へのリソースユーザ６０によるアクセスをコントロールする役割をはたす。異なるレシピに対して同一リソース５６を同時に使用した場合、処理される材料の汚染が生じ、これによって、製品を廃棄する必要が生じたり、他の否定的な結果が生じたりする。図２より詳細に示されているように、プロセスコントロールシステム５２は、リソース５６を使用するためにユーザ６０からの要求間を調停することによって、リソース５６へのアクセスをコントロールする。

図２は、プラント５０とプロセスコントロールシステム５２の更なる詳細を示すブロック図である。プロセスコントロールシステム５２は、一つ以上のワークステーション１００を更に含み、そして、リソース５６はタイプ１２０を更に含む。

それぞれのタイプ１２０は、各リソース５６に対応付けられ、該リソース５６が単一のエリア５４のみにおいて、または、複数のエリア５４を介して、使用されるかを示す。一つの実施の形態において、タイプ１２０は、「ローカル」または「グローバル」のいずれかである。ローカルタイプ１２０は、該リソース５６が一つのみのエリア５４内で使用されることを示し、一方、グローバルタイプ１２０は、該リソース５６が複数のエリア５４を介して使用されることを示す。一つのリソース５６が、一つのみのエリア５４で必要とされるか、または、複数のエリア５４を介して必要とされるかを指定することによって、全てのリソース５６を管理することを必要とせずに、複数のエリア装置アービトレータ（調停器）が、複数のエリア４５を介して、ユーザ６０からの同一のリソース５６に対する同時または競合する要求を管理することができる。一つの実施の形態において、特定のリソース５６がローカルまたはグローバルであるかの判断は、該プラント５０に対応付けられる人間のオペレータまたはエンジニアによって行なわれる。

ワークステーション１００は、プロセスコントロールサービスを提供するために動作可能な、モニタ、キーボード、中央処理装置（ＣＰＵ）、コンピュータ読取可能メモリ、および記憶装置などのハードウェアおよび／またはソフトウェアを含む。例えば、ワークステーション１００は、Ｉｎｔｅｌ(Ｃｏｒｐ．（インテル社）のコンピュータプロセッサ上で、Ｍｉｃｒｏｓｏｆｔ(Ｗｉｎｄｏｗｓ（登録商標）（マイクロソフトウィンドウズ（登録商標））ＮＴ、２０００、またはＸＰオペレーティングシステムを実行するコンピュータワークステーションまたはパーソナルコンピュータ（ＰＣ）であってよい。また、例えば、ワークステーション１００は、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、およびリードオンリーメモリ（ＲＯＭ）等の電子メモリ、ハードドライブ、フロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−ＲＷドライブ、およびディジタルバーサタイルディスク（ＤＶＤ）ドライブ等の磁気光学記憶媒体、および他の好適なコンピュータコンポーネントを含み得る。

ワークステーション１００は、ＤｅｌｔａＶ^TMシステムの一部としてエマーソンプロセスマネージメント（Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ）によって販売されているＤｅｌｔａＶ^TMバッチソフトウェアなどのバッチ処理コントロール能力を更に含む。一つの実施の形態において、ワークステーション１００は、バッチ管理（Ｂａｔｃｈ Ｅｘｅｃｕｔｉｖｅ）１１０、ローカル装置アービトレータ（Ｌｏｃａｌ Ｅｑｕｉｐｍｅｎｔ Ａｒｂｉｔｒａｔｏｒ）（ＬＡＲ）１１２、およびグローバル装置アービトレータ（Ｇｌｏｂａｌ Ｅｑｕｉｐｍｅｎｔ Ａｒｂｉｔｒａｔｏｒ）（ＧＡＲ）１１４を更に含む。

バッチ管理１１０は、コンピュータ読取可能媒体上に格納されるとともにプロセスコントロールシステム５２のバッチ処理部分を一つ以上のエリア５４に対して実行するために動作可能なソフトウェアを含む。一つの実施の形態において、それぞれのエリア５４は、分離したバッチ管理１１０によってコントロールされる。バッチ管理１１０は、プラント５０において使用されるレシピの工程を実行するリソース５６およびリソースユーザ６０をコントロールする。例えば、バッチ管理１１０は、ヒータリソースをコントロールして物質を１５分間３５０°Ｆ（１７６．６°Ｃ）に加熱し、次に、加熱された物質をミキサーリソースへ沈降させる。バッチ管理１１０は、略同時におよび／または互いに並行して、複数のレシピの実行をコントロールする。バッチ管理１１０は、ユーザ６０によるリソース５６への要求を処理するためにＬＡＲ１１２およびＧＡＲ１１４と情報のやりとりを行う。

ＬＡＲ１１２は、特定のエリア５４内でユーザ６０がリソース５６を使用する上で衝突する要求を調停するためにバッチ管理１１０と情報のやりとりを行うために動作可能なコンピュータ読取可能媒体および／またはハードウェアに格納されるソフトウェアを含む。より具体的には、バッチ管理１１０がリソース５６を用いてレシピを実行しているとき、二以上のユーザ６０が同じリソース５６を略同時に使用することを要求する場合がある。バッチ管理１１０が両ユーザ６０に対して同じリソース５６を略同時に使用させる場合、レシピはともに台無しになる恐れがある。同様に、バッチ管理１１０は、レシピにおいて時間に注意が必要な工程に備えて一つ以上のリソース５６を将来的に確保しておく必要があること、または、リソース５６が洗浄を必要とするなど、特定のレシピで使用する前に特定のリソース５６を準備する必要があることをレシピの一部として判断することもある。ユーザ６０に対して、一つ以上のリソース５６を割当てたり、確保したりする前に、バッチ管理１１０は、ＬＡＲ１１２へリソース５６の使用を要求する。ＬＡＲ１１２は、バッチ管理の特定のエリア５４内で該バッチ管理１１０が使用するために該要求されたリソース５６を入手可能であるかを判断する。一つの実施の形態において、ＬＡＲ１１２は「ローカル」タイプ１２０を有するリソース５６のみを処理する。

ＧＡＲ１１４は、二つ以上のエリア５４を介して、ユーザ６０がリソース５６を使用する上で衝突する要求を調停するためにバッチ管理１１０と情報をやりとりするために動作可能なコンピュータリーダ読取可能媒体および／またはハードウェアに格納されるソフトウェアを含む。より具体的には、バッチ管理１１０がリソース５６を用いてレシピを実行している時、二つ以上のレシピが同じリソース５６を略同時に使用することを要求する場合がある。レシピに対して一つ以上のリソース５６を割当てたり、確保したりする前に、バッチ管理１１０は、ＧＡＲ１１４とは異なるエリア５４にリソース５６の使用を要求する。ＧＡＲ１１４は、バッチ管理の特定エリア５４以外で該バッチ管理１１０が使用するために該要求されたリソース５６を入手可能であるかを判断する。一つの実施の形態において、ＧＡＲ１１４は、「グローバル」タイプ１２０を有するリソース５６のみを処理する。ＧＡＲ１１４は、リソース５６への要求を解決するためにＧＡＲ１１４間で互いに情報をやりとりすることができる。

一つの実施の形態において、各ＧＡＲ１１４は、各バッチ管理１１０に対応付けられ、バッチ管理の特定エリア５４内でグローバルタイプ１２０を有するリソース５６に対して責任を持つ。異なるエリア５４における第２のＧＡＲ１１４は、要求されたリソース５６を有するエリア５４に対応付けられたＧＡＲ１１４からのリソース５６を要求する。例えば、図２を参照すると、ユーザＵ２は、リソースＲ３へのアクセスを要求してよい。Ｕ２は、Ｒ３とは異なるエリア内にあるので、Ｕ２のエリア内のＧＡＲ１１４は、Ｒ３エリア内のＧＡＲ１１４からのＲ３へのアクセスを要求する。

また、一つの実施の形態において、ＧＡＲ１１４は、失敗したＧＡＲ１１４によって扱われたリソース５６を引き継ぐことによって他のＧＡＲ１１４の失敗を処理するように動作可能であってよい。例えば、第１のエリアのＧＡＲ１１４が失敗した場合、第２のエリア内のＧＡＲ１１４が、該失敗したＧＡＲのエリア内のリソース５６のリソース調停を引き継ぐこともある。

動作上、一つ以上のバッチ管理１１０は、一つ以上のエリア５４の各々の一つ以上のレシピの実行をコントロールする。該レシピの工程を実行するために、種々のリソースユーザ６０が一つ以上のリソース５６へのアクセスを要求してもよい。該リソースユーザ６０は、バッチ管理１１０を介してリソース５６へのアクセスを要求する。次に、該バッチ管理１１０は、要求されているリソース５６のタイプ１２０に基づいてバッチ管理に対応付けられたＬＡＲ１１２またはＧＡＲ１１４へ該リソース５６への要求を送る。

該要求されたリソース５６のタイプ１２０がローカルであるとき、ＬＡＲ１１２は、好適な基準に基づいてユーザ６０が使用するために該リソース５６を入手可能であるかを判断する。例えば、ＬＡＲ１１２は、該リソース５６が他のユーザ６０によって現在使用されているかのみを判断する。該ＬＡＲ１１２は、該要求しているユーザ６０によって使用される前に、リソース５６をクリーン・イン・プレース（定置洗浄）システムなどによって洗浄する必要があるか、または、該要求しているユーザ６０によって使用される前に該リソース５６をある温度に設定する必要があるかなどの複雑な使用上の判断を実行する場合もある。次に、ＬＡＲ１１２は、バッチ管理１１０が要求されたリソース５６を入手可能であるか否か、あるいは、いつ該リソース５６を入手可能であるかについて情報のやりとりを行なう。例えば、ユーザＵ１およびＵ２がＲ１へアクセスを試みる場合、ＬＡＲ１１２は、どのユーザが該要求されたリソースへのアクセスを得るかを決定する。

該要求されたリソース５６のタイプ１２０がグローバルであれば、ＧＡＲ１１４は、要求しているユーザ６０が使用するために該リソース５６を入手可能であるかを判断する。該要求されたリソース５６がバッチ管理１１０に対応付けられたＧＡＲ１１４と同じエリア内にある場合、該ＧＡＲ１１４は、該リソースを入手可能であるかを判断するとともに、バッチ管理１１０が該要求されたリソース５６を入手可能であるかについて情報のやりとりを行なう。該要求されたリソース５６が、バッチ管理１１０に対応付けられたＧＡＲ１１４とは異なるエリア内にある場合、ＧＡＲ１１４は、そのエリア５４内に該要求されたリソース５６を有するＧＡＲ１１４へ該要求を伝える。要求しているＧＡＲ１１４は、任意の好適な方法を用いて該要求を処理するために適切なＧＡＲ１１４を決定してもよい。一つの実施の形態において、ＧＡＲ１１４は、要求がＧＡＲ１１４の全てまたは一部へブロードキャスト（不特定多数の相手にむかってデータ送信）され、該適切なＧＡＲ１１４によって処理されるピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）ネットワーク構成のピア（同位）として編成される。他の実施の形態においても、ＧＡＲ１１４は、ピアとして編成されるが、処理されるリソース５６のリストを交換することによって、該要求を全てのＧＡＲ１１４へブロードキャストする必要性を回避する。あるいは、適切なＧＡＲ１１４は、該要求しているＧＡＲ１１４によって直接交信される。一般に、ＧＡＲ１１４は、任意の好適な方法で編成されてよい。適切なＧＡＲ１１４は、要求されたリソース５６が入手可能であるかを判断し、その結果を要求しているＧＡＲ１１４へ返信する。次に、該要求しているＧＡＲ１１４は、該結果をバッチ管理１１０が処理するように該バッチ管理１１０へ返信する。あるいは、該要求しているＧＡＲ１１４は、バイパスされ、結果は要求しているバッチ管理１１０へ直接返信される。例えば、図２を参照すると、ユーザＵ３が現在リソースＲ３を使用中である時にユーザＵ２がリソースＲ３へアクセスしたいとする場合、Ｕ２のエリアのＧＡＲ１１４は、Ｕ２の要求をＲ３のエリアのＧＡＲ１１４が処理するように該Ｒ３のエリアのＧＡＲ１１４へ送る。

次に、バッチ管理１１０は、該要求されたリソース５６を入手可能であるかについて処理する。入手不可能なリソースに関して、該バッチ管理１１０は、要求しているユーザ６０に対応付けられたレシピの実行の休止などの適切な行動を取る。

一つの実施の形態において、プロセスコントロールシステム５２によって提供されるＧＡＲ１１４の全てまたは一部からマスターＧＡＲ１１４を選択してもよい。任意の好適なＧＡＲ１１４は、マスターＧＡＲとして作動し得る。例えば、該マスターＧＡＲは、ある一定量の処理能力またはある一定量未満の処理負荷を有するワークステーション１００上で実行するＧＡＲ１１４に限定され得る。該マスターＧＡＲは、特定のリソース５６を入手可能であるか、どのリソース５６がどのエリア４３内にあるかを追跡する集中データベースとして作動し、および／または、他の好適なデータを提供する。マスターＧＡＲは、リソース５６と該リソース５６を処理するように割り当てられたＧＡＲ１１４の間のマッピングを格納することによって、ＧＡＲ１１４間で必要とされる通信の量を減少させるために使用される。他の実施の形態において、該マスターＧＡＲは、リソース５６のために入手性などの状態情報を格納してもよい。この実施の形態において、要求しているＧＡＲ１１４は、リソース５６が使用可能であるかを判断するためにマスターＧＡＲに問合せることもできる。該マスターＧＡＲの選択は、任意の好適な技術を用いて実行され得る。例えば、どのマスターＧＡＲ１１４が最初に起動されたかを判断することによってマスターＧＡＲを選択してもよい。ネットワーク内で「マスター」エレメントを選定または選択するための他の技術は、当該技術分野において周知である。

ＧＡＲ１１４は、他のＧＡＲ１１４の失敗を処理することも可能である。より具体的には、特定のエリア５４におけるＧＡＲ１１４は、例えば、クラッシュなどによって失敗することもある。他のＧＡＲ１１４は、このような失敗を検出し、失敗したＧＡＲのリソース５６の処理を引き継いでもよい。例えば、マスターＧＡＲは、失敗を検出し、失敗したＧＡＲのリソース５６へ他のＧＡＲ１１４を割り当ててもよい。また、例えば、要求しているＧＡＲ１１４は、他のＧＡＲ１１４がある期間の応答に失敗したことを検出し、該失敗したＧＡＲ１１４によって処理されたリソース５６を引き継いでもよい。

他の実施の形態において、ＧＡＲ１１４は、ユーザ６０が特定のリソース５６を使用してよいかを集合的に判断し得る。例えば、各エリア５４のＧＡＲ１１４にそのエリア５４のリソース５６へのアクセスの処理を引き受けさせることとは対照的に、二つ以上のＧＡＲ１１４は、一つ以上のエリア５４内の一つ以上のリソース５６へのアクセスの処理に対し責任をもってもよい。一般に、好適に、ＧＡＲ１１４のいくつかまたは全てが、エリア５４内のリソース５６のいくつかまたは全てへのアクセスを処理することに対し責任をもってもよい。例えば、更なるタイプ１２０は、特定のリソース５６の入手可能性がＧＡＲ１１４によってどのように処理されるかを判断するために定義付けられる。リソース５６の入手可能性の集合的判断は、ＧＡＲ１１４または他の好適な技術による投票（ｖｏｔｉｎｇ）に基づいて行なわれる。また、集合的判断に応じて、特定のリソース５６の入手可能性を判断する際の優先順位を特定のＧＡＲ１１４にもたせてもよい。例えば、第１のＧＡＲは、一つ以上の第２のＧＡＲより多くの投票数を得ることもあるし、あるいは、該第２のＧＡＲに対する拒否権を持つこともある。また、要求されている特定のリソース５６に基づいて、一つ以上のＧＡＲ１１４の投票権または拒否能力が増大してもよい。ＧＡＲ１１４に付与する投票権または拒否能力が増大することによって、特定の状況におけるリソース５６の優先使用を可能とする能力を提供することもある。例えば、緊急事態または予期しない結果によっては、何人かのユーザ６０へ優先アクセスを付与することが要求されることもある。図５は、投票能力を有するＧＡＲをより詳細に示す。

一つの実施の形態において、さまざまなタイプをリソースに対応付けることの利点の一つは、プロセスコントロールシステムをオーバーロードせずに複数のエリアを介してリソースが管理され得ることである。複数のエリアを介してリソースを自動的に管理することを可能とすることによって、該処理における人間のオペレータの介入の必要性を減少させることによってプラント効率が高まり、これが、該プラントのコスト削減につながる。

図３は、本発明の一つの実施の形態においてプラント５０内の組織に関するリソース５６の更なる詳細を示すブロック図である。リソース５６は、タンクなどの単一アイテム、あるいは、他のリソース５６を含む、タンクおよびポンプなどの複数のアイテムの論理的グループを表す。単一リソース５６に他のリソース５６を表させたり、組織させたりすることによって、グループ内のリソース５６のコントロールが可能となる。例えば、プラントを組織するためにはリソースの階層が生成され得る。図３に示されるように、一つの実施の形態は、薬品工業において使用される共通の組織化されたシステムに基づいてリソース５６が組織される。該薬品工業において、プラント５０などの所与のサイトが、エリア５４などの一つ以上のエリアを含む。該エリアは、それぞれ、一つ以上のプロセスセルを含む。該セルは１つ以上のユニットを含む。該一つ以上のプロセスユニットがそれぞれ実際の装置を示す一つ以上のモジュールを含む。リソース５６は、識別子（ｉｄ）１５０を更に含む。ｉｄ１５０は、リソース５６を互いに区別する、数値的、英数字またはアルファベット値などの好適な固有識別子を含む。

図４は、本開示の一つの実施の形態によるバッチ管理１１０の更なる詳細を示すブロック図である。バッチ管理１１０は、リソースのｉｄ１５０に基づいて対応付けられたタイプ１２０にリソース５６をマッピングするリソーステーブル２００を維持してよい。該リソーステーブル２００は、リソース５６への要求をＬＡＲ１１２またはＧＡＲ１１４のどちらに送るべきかを判断するためにバッチ管理１１０によって使用され得る。例えば、図４を参照すると、バッチ管理１１０は、リソース「リソース２」を使用するための要求をＧＡＲ１１４へ送るべきであると判断するためにリソーステーブル２００を使用してもよい。

図５は、投票権および優先投票権を含むＧＡＲ１１４の一つの実施の形態の詳細を示すブロック図である。一つの実施の形態において、特定のＧＡＲ１１４にリソース５６の特定のセットのみを引き受けさせる代わりに、ＧＡＲ１１４は、投票の活用または他の好適な技術によってリソース５６へのアクセスを集合的にコントロールできる。投票は、特定のエリア５４の代わりに、プラント５０の必要性にグローバルに基づいたアロケーション（割当て）などのリソース５６の改良されたアロケーションをもたらす。例えば、ＧＡＲ１１４は、集合的に、プラント５０における処理の状態の実質的にグローバルな知識を有し、より効率的にリソース５６を割当てるために該知識を利用してよい。また、特定のＧＡＲ１１４の投票重みは、特定のリソース５６に関してカスタマイズされてもよい。該リソース５６に対して、それぞれのＧＡＲ１１４に固有に対応付けられたＧＡＲ識別子（ＧＡＲｉｄ）２６０と、そのリソース５６のＧＡＲ１１４に対する投票重み２６２を用いることによって、ｉｄ１５０を特定のＧＡＲ１１４へマッピングするために投票テーブル２５０が使用されてもよい。例えば、図５を参照すると、ＧＡＲ ＧＥＡ１は、リソース「リソース１」に対して０．７の投票重みを有するが、ＧＡＲ ＧＥＡ２は、「リソース１」に対して１．０の投票重みを有する。このような異なる投票重みは、リソース５６または他の好適な基準に対してＧＡＲ１１４の優先権を示すために使用され得る。

一つの実施の形態において、顧客ＧＡＲ２７０は、カスタマイズ、または、他のリソース割当て計画を実施するためにＧＡＲ１１４のセットに追加される。例えば、顧客ＧＡＲ２７０は、該顧客ＧＡＲ２７０に割り当てられた投票重みによって、プラントオペレータ（図示しない）を他のＧＡＲ１１４よりも優先させるか、または、該プラントオペレータに該他のＧＡＲ１１４を拒否させるように構成され得る。顧客ＧＡＲ２７０は、好適に、特定のエリア５４またはバッチ管理１１０に対応付けられたり、対応付けられなかったり、または、直接対応付けられるリソース５６を有していたり、いなかったりしてもよい。

図６は、本開示の一つの実施の形態によるプラント５０の動作を示すフローチャートである。本発明の方法は、ブロック３００で開始し、該ブロック３００において、バッチ管理１１０は、リソースユーザ６０から、リソース５６への要求を受取る。次に、判断ブロック３０２において、該バッチ管理１１０は、要求されたリソース５６のタイプ１２０がローカルかまたはグローバルかを判断する。該要求されたリソース５６のタイプ１２０がローカルであれば、判断ブロック３０２のローカルブランチはブロック３０４へ進む。該ブロック３０４において、バッチ管理１１０は、該要求されたリソース５６が入手可能であるかを判断するために、バッチ管理のエリア５４についてＬＡＲ１１２へ問合せる。該要求されたリソース５６のタイプ１２０がグローバルであれば、判断ブロック３０２のグローバルブランチは、ブロック３０６へ進む。該ブロック３０６において、該要求されたリソース５６に適したＧＡＲ１１４について問合わせられ、該ＧＡＲ１１４は、該要求されたリソース５６を入手可能であるかを判断する。該ＧＡＲ１１４は、該要求されたリソース５６を入手可能であるかを判断するために、任意の好適な技術を、単独で、または、他のＧＡＲ１１４と組み合わせて使用することができる。

判断ブロック３０８において、適切なＬＡＲ１１２またはＧＡＲ１１４が要求されたリソース５６が入手可能であるかを判断した。該要求されたリソース５６が入手可能である場合、判断ブロック３０８の「ＹＥＳ」ブランチがブロック３１０へ進み、該ブロック３１０において、バッチ管理１１０は、該要求されたリソース５６が入手可能であるという情報を受け、該バッチ管理１１０は、該要求されたリソース５６へのアクセスを要求しているユーザ６０に与えるか、該要求しているユーザ６０へ該要求されたリソース５６を割当てる。該要求されたリソース５６が入手不可能である場合、判断ブロック３０８の「ＮＯ」ブランチは、ブロック３１２へ進み、該ブロック３１２において、バッチ管理１１０は、該要求されたリソース５６が入手不可能であるという情報を受け、該バッチ管理１１０は、該要求しているユーザ６０に対して該要求されたリソース５６へのアクセスを拒否する。バッチ管理１１０は、該要求を拒否する際に、該要求しているユーザ６０の処理を休止するなどの他の好適なアクションをとることができる。

本開示に関して種々の方法および手順が記載されているが、本開示の作用および使用がこれらに制約または限定されるものではないことが理解されよう。本明細書中に記載されている方法および手順の種々の変形および順序変更は、本開示の種々の実施の形態において実行が可能であり、また、説明されているフローチャートは、該フローチャートにおけるブロックのうちの一つの可能性のある順序を説明しているにすぎず、特定の実施の形態および実現によってさまざまな順序を適宜採用することが可能である。

本明細書中では、本発明の教示に応じて構築された装置が記載されているが、本特許の適用範囲はこれに限定されるものではないことが理解されよう。寧ろ、本特許は、字義通りまたは同等な教義の下であきらかに添付の特許請求の範囲を逸脱することがない限り、本発明の教示による製造に関する全ての装置、方法、および製品を網羅するものである。

本発明の一つの実施の形態による製造プラントにおけるプロセスコントロールシステムを示すブロック図である。 本発明の一つの実施の形態によるプラントおよびプロセスコントロールシステムのより詳細に示すブロック図である。 本発明の一つの実施の形態によるプラント内の編成に関して、該プラントに対応付けられたリソースをより詳細に示すブロック図である。 本発明の一つの実施の形態によるレシピを実行するために使用されるバッチ管理をより詳細に示すブロック図である。 投票および投票優先権を含むグローバル装置アービトレータの一つの実施の形態を詳細に示すブロック図である。 本発明の一つの実施の形態によるプラントの動作を示すフローチャートである。

Claims (23)

1. 第１のエリアとは区別される第２のエリアに対応付けられた第１のリソースユーザから、前記第１のエリアに対応付けられた第１のリソースへの要求を受取るステップと、
   前記第１のリソースユーザが使用するために前記第１のリソースを入手可能であるかを自動的に判断するステップと、
   を含むプロセスコントロールシステムにおける装置調停方法。
2. 前記第１のリソースを入手可能であるかを自動的に判断するステップが、前記第１のリソースを入手可能であるかを複数のグローバル装置アービトレータによって判断するステップと、該第１のリソースを入手可能であるかを前記グローバル装置アービトレータによって投票するステップと、を含む請求項１に記載の方法。
3. 前記グローバル装置アービトレータが同等でない投票権を有する請求項２に記載の方法。
4. 前記要求を受取るステップが、前記第１のエリアに対応付けられた第１の装置アービトレータにおいて前記要求を受取るステップを更に含み、前記第１のリソースを入手可能であるかを判断するステップが、前記リソースを入手可能であるかを前記第１の装置アービトレータによって判断するステップを更に含む、請求項１に記載の方法。
5. 前記第１のエリアに対応付けられた第２のリソースユーザが使用するために前記第１のリソースを入手可能であるかをローカル装置アービトレータによって自動的に判断するステップを更に含み、前記ローカル装置アービトレータが、前記第１のリソースユーザが使用するために前記第１のリソースを入手可能であるかを判断するために動作不能であり、該ローカル装置アービトレータが、前記第１の装置アービトレータとは区別される、請求項４に記載の方法。
6. 前記第１のリソースを第１のリソースユーザが入手可能であるかについての情報のやりとりを行なうステップを更に含み、前記要求を受取るステップが、前記第１のエリアに対応付けられたバッチ管理において前記要求を受取るステップと、前記第１のリソースに対応付けられたタイプに基づいて該要求を処理するために、前記バッチ管理によって前記第１の装置アービトレータまたは前記ローカル装置アービトレータを選択するステップと、を更に含む請求項４に記載の方法。
7. 前記タイプは、グローバルタイプ及びローカルタイプのいずれか一つを含み、前記第１の装置アービトレータまたは前記ローカル装置アービトレータを選択するステップが、前記タイプが前記グローバルタイプであれば、前記第１の装置アービトレータを選択し、前記タイプが前記ローカルタイプであれば、前記ローカル装置アービトレータを選択する、請求項６に記載の方法。
8. 前記バッチ管理によって判断するステップが、前記第１のエリアに対応付けられたリソーステーブルに基づいて前記第１のリソースのタイプを判断するステップを更に含み、前記第１のリソースと前記第２のリソースが階層的に編成される、請求項６に記載の方法。
9. 前記第１のエリアに対応付けられた第２のリソースユーザが前記第２のエリアに対応付けられた第２のリソースを入手可能であるかを第２の装置アービトレータによって自動的に判断するステップを更に含み、前記第１の装置アービトレータと前記第２の装置アービトレータが互いに情報のやりとりを行なうために動作可能である、請求項４に記載の方法。
10. それぞれが前記第１の装置アービトレータ、前記第２の装置アービトレータ、および互いから区別されている複数の第３の装置アービトレータを提供するステップと、前記第１の装置アービトレータをマスター装置アービトレータとして選択するステップと、
    前記マスター装置アービトレータにおいて更なる要求を受取るステップと、
    前記マスター装置アービトレータによって、本来、該マスター装置アービトレータ、前記第２の装置アービトレータ、および該マスター装置アービトレータに対応付けられた情報に基づいた前記第３の装置アービトレータからなるセットから一つの装置アービトレータを選択するステップと、該選択された装置アービトレータによって前記更なる要求を処理するステップと、を更に含む請求項９に記載の方法。
11. 前記第１のリソースが対応する識別子を有し、該第１のリソースを入手可能であるかを自動的に判断するステップが該第１のリソースが使用中であるかを判断するステップを含む、請求項１に記載の方法。
12. コンピュータ読取可能媒体上で符号化されるソフトウェアであって、第１のエリアとは区別される第２のエリアに対応付けられた第１のリソースユーザから、第１のエリアに対応付けられた第１のリソースへの要求を受取り、前記第１のリソースユーザが使用するために前記第１のリソースを入手可能であるかを自動的に判断するように動作可能である前記ソフトウェアを含む、
    プロセスコントロールシステムにおける装置調停システム。
13. 前記第１のリソースを入手可能であるかを自動的に判断することが、前記第１のリソースを入手可能であるかを複数のグローバル装置アービトレータによって判断し、該第１のリソースを入手可能であるかを前記グローバル装置アービトレータによって投票すること、を含む請求項１２に記載のシステム。
14. 前記グローバル装置アービトレータが同等でない投票権を有する、請求項１３に記載のシステム。
15. 前記要求を受取ることが、前記第１のエリアに対応付けられた第１の装置アービトレータにおいて該要求を受取ることを更に含み、前記第１のリソースを入手可能であるかを判断することが、前記リソースを入手可能であるかを前記第１の装置アービトレータによって判断することを更に含む、請求項１２に記載のシステム。
16. 前記ソフトウェアが、更に、前記第１のエリアと対応付けられた第２のリソースユーザが使用するために前記第１のリソースを入手可能であるかをローカル装置アービトレータによって自動的に判断するように動作可能であって、前記ローカル装置アービトレータは、前記第１のリソースユーザが使用するために前記第１のリソースを入手可能であるか判断するには動作不能であるとともに、前記第１の装置アービトレータとは区別される、請求項１５に記載のシステム。
17. 前記ソフトウェアが、更に、前記第１のリソースユーザが前記第１のリソースを入手可能であるかについて情報のやりとりを行なうために動作可能であり、前記要求を受取ることが、前記第１のエリアに対応付けられたバッチ管理において該要求を受取り、前記第１のリソースに対応付けられたタイプに基づいて前記要求を処理するために前記バッチ管理によって前記第１の装置アービトレータまたは前記ローカル装置アービトレータを選択することを更に含む、請求項１５に記載のシステム。
18. 前記タイプがグローバルタイプおよびローカルタイプのいずれかを含み、前記第１の装置アービトレータまたは前記ローカル装置アービトレータを選択することが、前記タイプが前記グローバルタイプであれば、前記第１の装置アービトレータを選択し、前記タイプが前記ローカルタイプであれば、前記ローカル装置アービトレータを選択することを更に含む、請求項１７に記載のシステム。
19. 前記バッチ管理によって判断することが、前記第１のエリアに対応付けられたリソーステーブルに基づいて前記第１のリソースのタイプを決定することを更に含み、該第１のリソースと前記第２のリソースが階層的に編成される、請求項１７に記載のシステム。
20. 前記ソフトウェアが、更に、前記第１のエリアに対応付けられた第２のリソースユーザが前記第２のエリアに対応付けられた第２のリソースを入手可能であるかを、第２の装置アービトレータによって、自動的に判断するように更に動作可能であり、前記第１の装置アービトレータと該第２の装置アービトレータが互いに情報のやりとりを行なうべく動作可能である、請求項１５に記載のシステム。
21. 前記ソフトウェアが、更に、それぞれが前記第１の装置アービトレータ、第２の装置アービトレータ、および互いから区別されている複数の第３の装置アービトレータを提供し、前記第１の装置アービトレータをマスター装置アービトレータとして選択し、前記マスター装置アービトレータにおいて更なる要求を受取り、前記マスター装置アービトレータによって、本来、該マスター装置アービトレータ、前記第２の装置アービトレータ、および該マスター装置アービトレータに対応付けられた情報に基づいた前記第３の装置アービトレータからなるセットから一つの装置アービトレータを選択し、該選択された装置アービトレータによって前記更なる要求を処理するように動作可能である請求項２０に記載のシステム。
22. 前記第１のリソースが対応する識別子を有し、該第１のリソースが入手可能であるかを自動的に判断することが前記第１のリソースが使用中であるかを判断することを含む、請求項１２に記載のシステム。
23. 第１のエリアとは区別される第２のエリアに対応付けられた第１のリソースユーザから、第１のエリアに対応付けられた第１のリソースへの要求を受取る手段と、
    前記第１のリソースユーザが使用するために前記第１のリソースを入手可能であるかを自動的に判断する手段と、
    を含むプロセスコントロールシステムにおける装置調停システム。

Images