JPH0769842B2 - 資源の相互排他制御方法及びシステム - Google Patents
資源の相互排他制御方法及びシステムInfo
- Publication number
- JPH0769842B2 JPH0769842B2 JP1031146A JP3114689A JPH0769842B2 JP H0769842 B2 JPH0769842 B2 JP H0769842B2 JP 1031146 A JP1031146 A JP 1031146A JP 3114689 A JP3114689 A JP 3114689A JP H0769842 B2 JPH0769842 B2 JP H0769842B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- node
- graph
- resource
- token
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Programmable Controllers (AREA)
Description
【発明の詳細な説明】 A.産業上の利用分野 この発明は、事象駆動型プロセスにおける逐次的利用可
能資源の相互排他制御方法及びシステムに関するもので
ある。ここで制御する逐次的利用可能資源の対象は、計
算機およびプログラマブル・ロジック・コントローラな
どが制御する資源である。
能資源の相互排他制御方法及びシステムに関するもので
ある。ここで制御する逐次的利用可能資源の対象は、計
算機およびプログラマブル・ロジック・コントローラな
どが制御する資源である。
B.従来の技術及びその問題点 最近のコンピュータ技術では、マルチタスク，マルチプ
ロセス，分散処理が重要な課題になっている。これらの
技術は実現する為には、、複数のタスクまたはプロセス
が並列実行される際に、資源を幾つかのタスクまたはプ
ロセスで共有しなくてはならない。この資源を共有資源
とよび、例えば種々の周辺装置、ディスク、メモリ、過
信回線、プログラム、データ等が挙げられる。一時に一
つタスクまたはプロセスでしか専有できない共有資源を
重要資源という。
ロセス，分散処理が重要な課題になっている。これらの
技術は実現する為には、、複数のタスクまたはプロセス
が並列実行される際に、資源を幾つかのタスクまたはプ
ロセスで共有しなくてはならない。この資源を共有資源
とよび、例えば種々の周辺装置、ディスク、メモリ、過
信回線、プログラム、データ等が挙げられる。一時に一
つタスクまたはプロセスでしか専有できない共有資源を
重要資源という。
事象駆動型プロセスにおける資源の相互排他制御の問題
は、事象駆動型プロセスが並列に実行され、それらのプ
ロセスが共有資源を使用するときに起きる。資源の相互
排他制御とは、高だか１つのプロセスしか共有資源を専
有しないための機構である。また並列実行のプロセスの
中で、共有資源を専有する部分を危険区間という。これ
は、複数のプロセスが並列実行される際の資源の共有問
題であり、プロセス間の通信及び同期化問題として提起
されている。これを解決するために、従来より多くの手
法が提案されモデルを用いて解析されてシステムの中で
用いられている。この同期化問題としては、相互排他問
題、生産者消費者問題、食事をする哲学者問題、読みだ
し書きこみ問題がある。
は、事象駆動型プロセスが並列に実行され、それらのプ
ロセスが共有資源を使用するときに起きる。資源の相互
排他制御とは、高だか１つのプロセスしか共有資源を専
有しないための機構である。また並列実行のプロセスの
中で、共有資源を専有する部分を危険区間という。これ
は、複数のプロセスが並列実行される際の資源の共有問
題であり、プロセス間の通信及び同期化問題として提起
されている。これを解決するために、従来より多くの手
法が提案されモデルを用いて解析されてシステムの中で
用いられている。この同期化問題としては、相互排他問
題、生産者消費者問題、食事をする哲学者問題、読みだ
し書きこみ問題がある。
現在は、並列実行システム実現の際、重要な問題となる
複数のプロセス間の資源の相互排他制御はセマフォ等を
使いプログラムが注意して書く以外に方法がない。この
ように、プログラマが並列実行するプログラムを書くと
き、又はオペレータはその環境下でプログラムを実行す
るときに、常に資源割当を意識しなくてはならない。こ
れは、プログラマやオペレータにとって負担である。
複数のプロセス間の資源の相互排他制御はセマフォ等を
使いプログラムが注意して書く以外に方法がない。この
ように、プログラマが並列実行するプログラムを書くと
き、又はオペレータはその環境下でプログラムを実行す
るときに、常に資源割当を意識しなくてはならない。こ
れは、プログラマやオペレータにとって負担である。
以下に、セマフォを用いたプログラミングの１例を示
す。今、第２図に模式的に示す事象駆動型の３つのプロ
セスの流れG1,G2,G3があるとしよう。第１のプロセスの
流れG1では、タスクp1とp2が連続して実行される。タス
クp1が共有資源ＡとＣを使いながら実行された後、続い
てタスクp2が共有資源ＢとＣを使いながら実行される。
す。今、第２図に模式的に示す事象駆動型の３つのプロ
セスの流れG1,G2,G3があるとしよう。第１のプロセスの
流れG1では、タスクp1とp2が連続して実行される。タス
クp1が共有資源ＡとＣを使いながら実行された後、続い
てタスクp2が共有資源ＢとＣを使いながら実行される。
第２のプロセスの流れG2では、タスクP3が実行される。
タスクP3は共有資源Ａ、Ｂ、Ｃを使いながら実行され
る。第３のプロセスの流れG3では、タスクP4とP5が並列
に実行される。タスクP4は共有資源ＡとＣを使いながら
実行され、タスクP5は共有資源ＢとＣを使いながら同時
に実行される。t1〜t7はタスクの始点または終点を示し
ている。第２図に登場する資源のうち、重要資源はＡと
Ｂであり、かつ重要資源Ａはロボット２、重要資源Ｂは
ロボット１であるとする。
タスクP3は共有資源Ａ、Ｂ、Ｃを使いながら実行され
る。第３のプロセスの流れG3では、タスクP4とP5が並列
に実行される。タスクP4は共有資源ＡとＣを使いながら
実行され、タスクP5は共有資源ＢとＣを使いながら同時
に実行される。t1〜t7はタスクの始点または終点を示し
ている。第２図に登場する資源のうち、重要資源はＡと
Ｂであり、かつ重要資源Ａはロボット２、重要資源Ｂは
ロボット１であるとする。
現在は、ほとんどの場合において、プログラミングが各
重要資源（マニファクチャリング・プロセスに於ける生
産機器のコントローラ、ネットワーク・システムに於け
るコンピュータ）上で行なわれており、各重要資源上の
プログラムと、それらを制御するプログラムが必要にな
る。この例を第３図に示す。第3A図は全体を制御するプ
ログラム、第3B図はロボット１のプログラム、第3C図は
ロボット２のプログラムである。
重要資源（マニファクチャリング・プロセスに於ける生
産機器のコントローラ、ネットワーク・システムに於け
るコンピュータ）上で行なわれており、各重要資源上の
プログラムと、それらを制御するプログラムが必要にな
る。この例を第３図に示す。第3A図は全体を制御するプ
ログラム、第3B図はロボット１のプログラム、第3C図は
ロボット２のプログラムである。
ここでは、並列実行を記述する構文は次のとおりであ
る。
る。
cobegin P1; P2 coend ここでP1、P2は並列実行されるタスクである。また、危
険区間を記述する構文は次のとおりである。
険区間を記述する構文は次のとおりである。
with R do begin Ｓ end ここで、Ｒは相互排除すべき重要資源に対する一意名で
あり、Ｓは相互排除すべき危険区間である。この場合Ｒ
がセマフォとなる。
あり、Ｓは相互排除すべき危険区間である。この場合Ｒ
がセマフォとなる。
第3A図において、Ｒ（ｐ）は第3B図、第3C図で示す、そ
れぞれのロボットのプログラムである。Ｒにパラメタｐ
を渡すとＲのプログラムはｐのタスクのみが実行され
る。
れぞれのロボットのプログラムである。Ｒにパラメタｐ
を渡すとＲのプログラムはｐのタスクのみが実行され
る。
危険区間を記述する構文およびそのメカニズム、並列実
行を記述する構文およびそのメカニズムは、一般的にプ
ログラマに供給されておらず、その記述およびそのメカ
ニズムの作成、そして相互排他制御のデバックはプログ
ラマの責任となる。
行を記述する構文およびそのメカニズムは、一般的にプ
ログラマに供給されておらず、その記述およびそのメカ
ニズムの作成、そして相互排他制御のデバックはプログ
ラマの責任となる。
さて、システムのモデリングに多く用いられてきた手法
の一つにペトリネットがある。ペトリネットの特徴は、
並列性あるいは同時進行性と非同期性であり、その実行
は離散的な事象の系列と考えることができ、いつ事象が
発生するかは非決定的である。この特徴及び実行形態を
利用して事象駆動型の制御に利用しようとする試みがな
されている。また、ペトリネットの数学的解析性の良さ
とモデル化能力の高さに注目して、並列実行システム
（計算機モデル、マニファクチャリング・プロセス）の
シュミレーションに使われている ペトリネットの概略を説明する。
の一つにペトリネットがある。ペトリネットの特徴は、
並列性あるいは同時進行性と非同期性であり、その実行
は離散的な事象の系列と考えることができ、いつ事象が
発生するかは非決定的である。この特徴及び実行形態を
利用して事象駆動型の制御に利用しようとする試みがな
されている。また、ペトリネットの数学的解析性の良さ
とモデル化能力の高さに注目して、並列実行システム
（計算機モデル、マニファクチャリング・プロセス）の
シュミレーションに使われている ペトリネットの概略を説明する。
ペトリネットはプレース、トランジション、アーク、ト
ークンの４つから構成されており、プレースは事象を、
トランジションは条件、アークは経路、トークンは状態
を表わす。トークンはトランジションの条件に従ってプ
レース間の経路を移動し、プレースに対応した事象を引
き起こす。
ークンの４つから構成されており、プレースは事象を、
トランジションは条件、アークは経路、トークンは状態
を表わす。トークンはトランジションの条件に従ってプ
レース間の経路を移動し、プレースに対応した事象を引
き起こす。
第４図は、ペトリネットの実行例である。この例では、
トランジションＴ＝｛ta、tb、tC｝、プレースＰ＝
｛Px、Py、Pz｝、トークンを用いて説明する。まず、ta
は、Pxにトークンがなければ、トークンを発生させ、Px
に置く（第4A図）。tbはPxにトークンがありかつPy、Pz
にトークンがなければ、トークンをPy、Pzに移す（第4B
図）。tcはトークンがPy、Pzあれば、Py,Pzよりトーク
ンを取りだして、このトークン消滅させる。なお、ペト
リネットの詳細については、例えば （１）Peterson、J.L.著 "Petri Net Theory and the Modeling of Systems"、Pr
entice−Hall Inc.、1981を参照されたい。
トランジションＴ＝｛ta、tb、tC｝、プレースＰ＝
｛Px、Py、Pz｝、トークンを用いて説明する。まず、ta
は、Pxにトークンがなければ、トークンを発生させ、Px
に置く（第4A図）。tbはPxにトークンがありかつPy、Pz
にトークンがなければ、トークンをPy、Pzに移す（第4B
図）。tcはトークンがPy、Pzあれば、Py,Pzよりトーク
ンを取りだして、このトークン消滅させる。なお、ペト
リネットの詳細については、例えば （１）Peterson、J.L.著 "Petri Net Theory and the Modeling of Systems"、Pr
entice−Hall Inc.、1981を参照されたい。
最近は、プログラマがグラフィック・エディタを用いて
第２図または第４図のようなプロセスの流れを記述し、
これをコードに変換して全体を制御するプログラムを作
成し、実行時には該プログラムに基づいて、タスクの開
始を命じたり終了信号を受け取ったりしつつ、これらの
信号に応じて、トークンを自動的に移動させていくシス
テムも提案されている。例えば、 （２）Hasegawa、K.and Takahashi、K.、"MFG（Mark Fl
ow Graph）−Based Programmable Controller and its
Application to FMS、"Proceedings of the Internatio
nal Conference on System Engineering、pp306−311、
1984.、 を参照されたい。
第２図または第４図のようなプロセスの流れを記述し、
これをコードに変換して全体を制御するプログラムを作
成し、実行時には該プログラムに基づいて、タスクの開
始を命じたり終了信号を受け取ったりしつつ、これらの
信号に応じて、トークンを自動的に移動させていくシス
テムも提案されている。例えば、 （２）Hasegawa、K.and Takahashi、K.、"MFG（Mark Fl
ow Graph）−Based Programmable Controller and its
Application to FMS、"Proceedings of the Internatio
nal Conference on System Engineering、pp306−311、
1984.、 を参照されたい。
しかしながら、従来のこの種の制御システムにおいて、
相互排他制御を考慮したものはない。
相互排他制御を考慮したものはない。
また、プログラミングではなくモデル化の方面において
ではあるけれども、資源の空状態にあたるプレース（空
プレース）を作成し、その資源を使うタスクのプレース
と繋ぎ、危険区間を設定することによって、相互排他制
御のモデル化が行われている。ここでは、ペトリネット
の重要な性質である保存性を利用している。その空プレ
ースには、初期マーキングとしてトークンが入ってお
り、資源を使用されないときは、常にトークンが入って
いる。あるプロセスが危険区間に入っていて、資源を使
用しているとき、空プレースにはトークンがない。他の
プロセスが同じ資源を使おうとして、危険区間に入ろう
とすると、空プレースにはトークンがなく、発火条件が
満たされないので、プロセスは実行できない。資源を使
用しているプロセスが終了し、資源を解放して空プレー
スにトークンが戻るまで、他のプロセスの実行は待たさ
れる。
ではあるけれども、資源の空状態にあたるプレース（空
プレース）を作成し、その資源を使うタスクのプレース
と繋ぎ、危険区間を設定することによって、相互排他制
御のモデル化が行われている。ここでは、ペトリネット
の重要な性質である保存性を利用している。その空プレ
ースには、初期マーキングとしてトークンが入ってお
り、資源を使用されないときは、常にトークンが入って
いる。あるプロセスが危険区間に入っていて、資源を使
用しているとき、空プレースにはトークンがない。他の
プロセスが同じ資源を使おうとして、危険区間に入ろう
とすると、空プレースにはトークンがなく、発火条件が
満たされないので、プロセスは実行できない。資源を使
用しているプロセスが終了し、資源を解放して空プレー
スにトークンが戻るまで、他のプロセスの実行は待たさ
れる。
第５図にこのようなモデル化の１例を示す。
プレースｍは危険区間に入るための許可をあらわす。あ
るプロセスが危険区間に入るには、p1またはp2にトーク
ンを入れて危険区間に入りたいという合図を出し、危険
区間に入ってよいという合図すなわちｍのトークンを待
って危険区間にアクセスすることとなる。両方のプロセ
スが危険区間に入りたいときには、トランジションt1と
t2は競合となり、どちらか一方しか発火できない。t1の
発火はt2を発火不能とし、プロセス１が危険区間を終わ
ってトークンをｍに戻すまでプロセス２は待機するここ
となる。
るプロセスが危険区間に入るには、p1またはp2にトーク
ンを入れて危険区間に入りたいという合図を出し、危険
区間に入ってよいという合図すなわちｍのトークンを待
って危険区間にアクセスすることとなる。両方のプロセ
スが危険区間に入りたいときには、トランジションt1と
t2は競合となり、どちらか一方しか発火できない。t1の
発火はt2を発火不能とし、プロセス１が危険区間を終わ
ってトークンをｍに戻すまでプロセス２は待機するここ
となる。
では、第５図のような重要資源の空プレースを含んだグ
ラフを作成してこれをコードに変換することによって、
相互排他制御を考慮した全体の制御プログラムを作成
し、上記文献（２）に示されるシステムの如く、トーク
ンを自動的に移動させていけば、相互排他制御が容易に
実現されるだろうか。残念ながら、答は「否」である。
この理由を以下に述べる。
ラフを作成してこれをコードに変換することによって、
相互排他制御を考慮した全体の制御プログラムを作成
し、上記文献（２）に示されるシステムの如く、トーク
ンを自動的に移動させていけば、相互排他制御が容易に
実現されるだろうか。残念ながら、答は「否」である。
この理由を以下に述べる。
（１）まず、空プレースをペトリネットの中に組み込ま
なければならない。プログラマが重要資源を意識してそ
の空プレースをペトリネット中の適切な場所に組み込ん
でいくとすれば、その労力はセマフォを用いたプログラ
ミングと同等のものになるであろう。第５図のような簡
単な事例ならともかく、第６図のように事例が少し複雑
になるだけで、ペトリネットの作成は大幅に困難にな
る。
なければならない。プログラマが重要資源を意識してそ
の空プレースをペトリネット中の適切な場所に組み込ん
でいくとすれば、その労力はセマフォを用いたプログラ
ミングと同等のものになるであろう。第５図のような簡
単な事例ならともかく、第６図のように事例が少し複雑
になるだけで、ペトリネットの作成は大幅に困難にな
る。
（２）実行時において、ユーザが、まず空プレース（資
源プレース）をタスク・プレースと区別した後、空プレ
ースのすべてに初期トークンを置かなければならない。
これはユーザーに大きな負担をかけることになる。
源プレース）をタスク・プレースと区別した後、空プレ
ースのすべてに初期トークンを置かなければならない。
これはユーザーに大きな負担をかけることになる。
（３）ペトリネットの表現自体に起因してデッドロック
が生じる場合がある。
が生じる場合がある。
第６図を例にとって説明しよう。今、第6A図のような状
態にあるとする。すなわち、タスクP1、P4が実行中であ
り、資源Px、Pyは空いている。なお、資源Pxは、タスク
P2、P3、P6で使用される。資源Pyは、タスクP3,P5,P6で
使用される。
態にあるとする。すなわち、タスクP1、P4が実行中であ
り、資源Px、Pyは空いている。なお、資源Pxは、タスク
P2、P3、P6で使用される。資源Pyは、タスクP3,P5,P6で
使用される。
第6A図の状態にあるならば、制御システムがタスクP2、
P5の実行を開始できることは明らかである。よって、
t1、t4は、トークンをそれぞれP2、P5に移す。ここで注
意すべきは、第５図、第６図のような表現では危険区間
の両端と資源の空プレースとを繋いでいるため、タスク
P2に続いてタスクP3の実行が終了するまでPxの空きプレ
ースにトークンが移ることはとなく、同様に、タスクP5
に続いてタスクP6の実行が終了するまでPyの空きプレー
スにトークンが移ることはないことである。タスクP2、
P5の実行開始後のトークンの位置を第6B図に示す。さ
て、タスクP2の実行が終了しても、制御システムはタス
クP3の実行を開始できない。Pyの空きプレースにトーク
ンがないからである。タスクP3の実行が始まらない限り
はPxの空きプレースにトークンが戻ることもない。よっ
てタスクP6の実行が開始されることもない。このよう
に、トランジッションt2とt5が発火できずデッドロック
が起こる。ペトリネットでは、発火できないトランジッ
ションおよびその集合をデッドロックという。
P5の実行を開始できることは明らかである。よって、
t1、t4は、トークンをそれぞれP2、P5に移す。ここで注
意すべきは、第５図、第６図のような表現では危険区間
の両端と資源の空プレースとを繋いでいるため、タスク
P2に続いてタスクP3の実行が終了するまでPxの空きプレ
ースにトークンが移ることはとなく、同様に、タスクP5
に続いてタスクP6の実行が終了するまでPyの空きプレー
スにトークンが移ることはないことである。タスクP2、
P5の実行開始後のトークンの位置を第6B図に示す。さ
て、タスクP2の実行が終了しても、制御システムはタス
クP3の実行を開始できない。Pyの空きプレースにトーク
ンがないからである。タスクP3の実行が始まらない限り
はPxの空きプレースにトークンが戻ることもない。よっ
てタスクP6の実行が開始されることもない。このよう
に、トランジッションt2とt5が発火できずデッドロック
が起こる。ペトリネットでは、発火できないトランジッ
ションおよびその集合をデッドロックという。
数学的に表現するなら、ペトリネット構造をＧとする
と、Ｇ＝（Ｐ、Ｔ、Ｏ）である。ここで、Ｐ＝｛P1、
P2、…、PM｝は、プレースの集合であってＭ＞０であ
る。Ｔ＝｛T1、T2、…、TL｝は、トランジッションの集
合であってＬ＞１である。プレースの集合とトランジッ
ションの集合とは互いに素であり、Ｐ∩Ｔ＝φである。
I:P−＞Ｔは、プレースからトランジッションへの入力
関数である。O:T−＞Ｐは、トランジッションからプレ
ースへの出力関数である。このペトリネット構造に、プ
レースへのトークンを割り当てたマーキングμを加えた
ものをマークペトリネットという。トークンはプレース
のみに存在し、トランジッションの発火が実行を制御し
ている。トランジッションの発火は、トークンが入力プ
レースから出力プレースへ移動することである。ペトリ
ネット構造は、グラフ理論においては双対である。マー
クペトリネットにおいては双対の定義が困難なため、双
対の概念が利用されていない。
と、Ｇ＝（Ｐ、Ｔ、Ｏ）である。ここで、Ｐ＝｛P1、
P2、…、PM｝は、プレースの集合であってＭ＞０であ
る。Ｔ＝｛T1、T2、…、TL｝は、トランジッションの集
合であってＬ＞１である。プレースの集合とトランジッ
ションの集合とは互いに素であり、Ｐ∩Ｔ＝φである。
I:P−＞Ｔは、プレースからトランジッションへの入力
関数である。O:T−＞Ｐは、トランジッションからプレ
ースへの出力関数である。このペトリネット構造に、プ
レースへのトークンを割り当てたマーキングμを加えた
ものをマークペトリネットという。トークンはプレース
のみに存在し、トランジッションの発火が実行を制御し
ている。トランジッションの発火は、トークンが入力プ
レースから出力プレースへ移動することである。ペトリ
ネット構造は、グラフ理論においては双対である。マー
クペトリネットにおいては双対の定義が困難なため、双
対の概念が利用されていない。
C.問題点を解決するための手段 本発明による資源の相互排他制御方法は、 （ａ）プロセスの流れに含まれるタスク及び何れかのタ
スクによつて専有され得る重要資源がノードに対応さ
れ、逐次実行されるタスクのノードは直列に配置される
とともに、並列して実行されるタスクのノード同士は並
列に配置され、重要資源のノードは該重要資源を専有し
得るすべてのタスクのノードと並列に配置されてなるグ
ラフを記憶装置上に作成し、 （ｂ）タスクの実行開始信号を送る度に、上記グラフ中
の該タスクのノード及び該ノードに並列に配置された重
要資源のノードにトークンを発生させ、 プロセスの流れの中で先行するタスクの実行の終了を検
知したとき、上記グラフを参照して、直接の後続タスク
のノード又は該ノードに並列に配置された重要資源のノ
ードの何れか１つにトークンが存在している間は、直接
の後続タスクの実行開始信号の送出を待機する ことを特徴とする。
スクによつて専有され得る重要資源がノードに対応さ
れ、逐次実行されるタスクのノードは直列に配置される
とともに、並列して実行されるタスクのノード同士は並
列に配置され、重要資源のノードは該重要資源を専有し
得るすべてのタスクのノードと並列に配置されてなるグ
ラフを記憶装置上に作成し、 （ｂ）タスクの実行開始信号を送る度に、上記グラフ中
の該タスクのノード及び該ノードに並列に配置された重
要資源のノードにトークンを発生させ、 プロセスの流れの中で先行するタスクの実行の終了を検
知したとき、上記グラフを参照して、直接の後続タスク
のノード又は該ノードに並列に配置された重要資源のノ
ードの何れか１つにトークンが存在している間は、直接
の後続タスクの実行開始信号の送出を待機する ことを特徴とする。
上記ステツプ（ａ）では、上記グラフにおいて、連続し
た実行されるタスクのノード同士を連結する位置にゲー
トのノードが設けられ、 上記ステツプ（ｂ）では、タスクの実行の終了を検知す
る更に、該タスクのノード及び該ノードに並列に配置さ
れた重要資源のノードに存在するトークンを消滅させ、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、その後、
上記グラフを参照して、該ゲート・ノードの直後に配置
された後続タスクのノード又はこれと並列に配置された
重要資源ノードの何れか１つにトークンが存在している
間は、該後続タスクの実行開始信号の送出を待機し、 該後続タスクの実行開始信号を送つた後に、該ゲート・
ノードのトークンを消滅させることが好ましい。
た実行されるタスクのノード同士を連結する位置にゲー
トのノードが設けられ、 上記ステツプ（ｂ）では、タスクの実行の終了を検知す
る更に、該タスクのノード及び該ノードに並列に配置さ
れた重要資源のノードに存在するトークンを消滅させ、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、その後、
上記グラフを参照して、該ゲート・ノードの直後に配置
された後続タスクのノード又はこれと並列に配置された
重要資源ノードの何れか１つにトークンが存在している
間は、該後続タスクの実行開始信号の送出を待機し、 該後続タスクの実行開始信号を送つた後に、該ゲート・
ノードのトークンを消滅させることが好ましい。
本発明による好ましい資源の相互排他制御システムは、
プロセスの流れに含まれるタスク及び何れかのタスクに
よって専有され得る重要資源に対応するノーを持ち、逐
次実行されるタスクのノードは直列に配置されるととも
に、並列して実行されるタスクのノード同士は並列に配
置され、タスクノード同士を連結する位置にゲートのノ
ードが配置され、重要資源のノードは該重要資源を専有
し得るすべてのタスクのノードと並列に配置されてなる
グラフを保持する記憶装置と、 タスクの実行開始信号を送る度に、上記グラフ中の該タ
スクのノード及び該ノードに並列に配置された重要資源
のノードにトークンを発生させる手段と、 タスクの実行の終了を検知する度に、該タスクのノード
及び該ノードに並列に配置された重要資源のノードに存
在するトークンを消滅させる手段と、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、その後、
上記グラフを参照して、該ゲート・ノードの直後に配置
された後続タスクのノード又はこれと並列に配置された
重要資源ノードの何れか１つにトークンが存在している
間は、該後続タスクの実行開始信号の送出を待機し、 該後続タスクの実行開始信号を送つた後に、該ゲート・
ノードのトークンを消滅させる手段、 を具備する。
プロセスの流れに含まれるタスク及び何れかのタスクに
よって専有され得る重要資源に対応するノーを持ち、逐
次実行されるタスクのノードは直列に配置されるととも
に、並列して実行されるタスクのノード同士は並列に配
置され、タスクノード同士を連結する位置にゲートのノ
ードが配置され、重要資源のノードは該重要資源を専有
し得るすべてのタスクのノードと並列に配置されてなる
グラフを保持する記憶装置と、 タスクの実行開始信号を送る度に、上記グラフ中の該タ
スクのノード及び該ノードに並列に配置された重要資源
のノードにトークンを発生させる手段と、 タスクの実行の終了を検知する度に、該タスクのノード
及び該ノードに並列に配置された重要資源のノードに存
在するトークンを消滅させる手段と、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、その後、
上記グラフを参照して、該ゲート・ノードの直後に配置
された後続タスクのノード又はこれと並列に配置された
重要資源ノードの何れか１つにトークンが存在している
間は、該後続タスクの実行開始信号の送出を待機し、 該後続タスクの実行開始信号を送つた後に、該ゲート・
ノードのトークンを消滅させる手段、 を具備する。
D.実施例 第１図は、この発明の実施例のシステム構成図である。
以下、この図のステップS1〜S8を順に説明する。
以下、この図のステップS1〜S8を順に説明する。
（ａ）プロセス・フロー・グラフの作成（ステップS1） ユーザは、単位プロセスをタスクとして、事象駆動型プ
ロセスを表現するプロセス・フロー・グラフを作成す
る。ここで作成されるプロセス・フロー・グラフは、安
全で且つ活性の性質を持つ制限された（多重枝も自己ル
ープもない）ペリトネット・グラフと等価である。プロ
セス・フロー・グラフの定義は、［数学的な表現］の項
を参照されたい。
ロセスを表現するプロセス・フロー・グラフを作成す
る。ここで作成されるプロセス・フロー・グラフは、安
全で且つ活性の性質を持つ制限された（多重枝も自己ル
ープもない）ペリトネット・グラフと等価である。プロ
セス・フロー・グラフの定義は、［数学的な表現］の項
を参照されたい。
このプロセス・フロー・グラフの作成法としては、グラ
フィックス・エディタを用いてグラフィカル・シンボル
で記述した後、それをテキスト表現に変換する方法と、
テキスト・エディタを用いて文字コードで直接記述する
方法がある。ここで作成されたプロセス・フロー・グラ
フをプロセス・フロー・プログラムとも呼ぶ。
フィックス・エディタを用いてグラフィカル・シンボル
で記述した後、それをテキスト表現に変換する方法と、
テキスト・エディタを用いて文字コードで直接記述する
方法がある。ここで作成されたプロセス・フロー・グラ
フをプロセス・フロー・プログラムとも呼ぶ。
本実施例では、ユーザが対話的にグラフィクス・エディ
タによって記述する。第７図は、プロセス・フロー・プ
ログラムのグラフィカルな表現である。プロセス・フロ
ー・グラフ上の制御単位をタスクと呼び、プログラム・
ファイルに対応している（第８図参照）。
タによって記述する。第７図は、プロセス・フロー・プ
ログラムのグラフィカルな表現である。プロセス・フロ
ー・グラフ上の制御単位をタスクと呼び、プログラム・
ファイルに対応している（第８図参照）。
第７図を用いて、プロセス・フロー・グラフの定義に従
った実行例を説明する。トークンがコンディション・ゲ
イトC1またはC4に発生する。トークンがコンディション
・ゲイトC1に発生した場合は、タスク・プレースT1、T2
にトークンが移動し、タスクT1、T2がそれぞれ資源RA、
RBを使いながら実行される。タスクT1、T2がどちらも終
了すると、コンディション・ゲイトC2の条件により、ト
ークンは、タスク・プレースT3に移動する。タスクT3は
資源RBを使いながら実行される。そして、タスクT3が終
了すると、トークンは、プレースT3からコンディショ
ン、ゲイトC3に移動し、消滅する。次に、トークンがコ
ンディション・ゲイトC4に発生した場合は、タスク・プ
レースT4にトークンが移動し、タスクT4が資源RAを使い
ながら実行される。タスクT4が終了すると、コンデイシ
ョン・ゲイトC5の条件により、トークンは、タスク・プ
レースT5に移動する。タスクT5は資源RA、RBを使いなが
ら実行される。そして、タスクT5が終了すると、トーク
ンは、プレースT5からコンディション・ゲイトC3に移動
し、消滅する。この実行例では、資源の相互排他制御
は、含まれていない。ここで、コンディション・ゲイト
とは、ペトリネット・モデルにおけるトランジションに
相当するものだが、それ自体にトークンを置き得るとい
う点でトランジションと決定的に異なっている。この点
については後で詳しく述べる。
った実行例を説明する。トークンがコンディション・ゲ
イトC1またはC4に発生する。トークンがコンディション
・ゲイトC1に発生した場合は、タスク・プレースT1、T2
にトークンが移動し、タスクT1、T2がそれぞれ資源RA、
RBを使いながら実行される。タスクT1、T2がどちらも終
了すると、コンディション・ゲイトC2の条件により、ト
ークンは、タスク・プレースT3に移動する。タスクT3は
資源RBを使いながら実行される。そして、タスクT3が終
了すると、トークンは、プレースT3からコンディショ
ン、ゲイトC3に移動し、消滅する。次に、トークンがコ
ンディション・ゲイトC4に発生した場合は、タスク・プ
レースT4にトークンが移動し、タスクT4が資源RAを使い
ながら実行される。タスクT4が終了すると、コンデイシ
ョン・ゲイトC5の条件により、トークンは、タスク・プ
レースT5に移動する。タスクT5は資源RA、RBを使いなが
ら実行される。そして、タスクT5が終了すると、トーク
ンは、プレースT5からコンディション・ゲイトC3に移動
し、消滅する。この実行例では、資源の相互排他制御
は、含まれていない。ここで、コンディション・ゲイト
とは、ペトリネット・モデルにおけるトランジションに
相当するものだが、それ自体にトークンを置き得るとい
う点でトランジションと決定的に異なっている。この点
については後で詳しく述べる。
プロセス・フロー・プログラムのテキスト表現を、プロ
セス・フロー・グラフの中間コードの形で作成する。こ
れは、グラフィカルな表現と等価であり、相互変換がで
きる。以後グラフのテキスト表現を単に中間コードとも
呼ぶ。
セス・フロー・グラフの中間コードの形で作成する。こ
れは、グラフィカルな表現と等価であり、相互変換がで
きる。以後グラフのテキスト表現を単に中間コードとも
呼ぶ。
プロセス・フロー・グラフの中間コードの書式は、次の
ようにする。
ようにする。
コンディション・ゲイト： 入力プレース（，入力プレース…）／ 出力プレース（，出力プレース…） 第７図の実施例の中間コードは、下記のようになる。
C1:/T1、T2 C2:T1、T2/T3 C3:T3/ C4:/T4 C5:T4/T5 C6:T5/ （ｂ）資源管理グラフの生成（ステップS2、S3） このプロセス・フロー・グラフとタスク・プログラムよ
り、資源管理グラフを生成する。タスク・プログラムの
中よりタスクに必要な重要資源の資源名を抽出し、その
リストを生成する。第８図に示すようにタスク・プログ
ラムがテキストで記述された場合、その中で記述される
重量資源は、資源の論理記号、資源の論理番号、資源の
論理名などで記述される。プロセス・フロー・グラフと
資源名を抽出したリストから資源管理グラフを生成す
る。第９図が、第７図のプロセス・フロー・グラフとそ
のタスクで必要な重要資源の資源名リストより生成され
た資源管理グラフを示す。
り、資源管理グラフを生成する。タスク・プログラムの
中よりタスクに必要な重要資源の資源名を抽出し、その
リストを生成する。第８図に示すようにタスク・プログ
ラムがテキストで記述された場合、その中で記述される
重量資源は、資源の論理記号、資源の論理番号、資源の
論理名などで記述される。プロセス・フロー・グラフと
資源名を抽出したリストから資源管理グラフを生成す
る。第９図が、第７図のプロセス・フロー・グラフとそ
のタスクで必要な重要資源の資源名リストより生成され
た資源管理グラフを示す。
なお、第８図に示す如く、ユーザは、タスクのつながり
を記述するプロセス・フロー・グラフにおいても、ま
た、個々のタスクを記述するタスク・プログラムにおい
ても、プログラム作成時にはセマフォ等を使って資源管
理を意識する必要は一切ないことに注意されたい。
を記述するプロセス・フロー・グラフにおいても、ま
た、個々のタスクを記述するタスク・プログラムにおい
ても、プログラム作成時にはセマフォ等を使って資源管
理を意識する必要は一切ないことに注意されたい。
本実施例では、タスク・プログラムの作成は、テキスト
・エディタを用いて対象指向型言語で記述され、その書
式は下記の通りである。
・エディタを用いて対象指向型言語で記述され、その書
式は下記の通りである。
資源の論理名：コマンド タスク・プログラム中の資源の論理名から、タスクの中
で用いる重要資源名を抽出したリストを作り、このリス
トとプロセス・フロー・グラフより資源管理グラフを生
成する。
で用いる重要資源名を抽出したリストを作り、このリス
トとプロセス・フロー・グラフより資源管理グラフを生
成する。
資源管理グラフの中間コードの書式を、プロセス・フロ
ー・グラフの中間コードの書式と同じにすると、第９図
の実施例の中間コードは、下記のようになる。
ー・グラフの中間コードの書式と同じにすると、第９図
の実施例の中間コードは、下記のようになる。
C1:/RA、RB C2:RA、RB/RB C3:RB/ C4:/RA C5:RA/RA、RB C6:RA、RB/ 第10図は、資源名リストでプロセス・フロー・グラフか
らこのような中間コードを生成するためのアルゴリズム
を示すフロー・チャートである。なお、すべての資源が
重要である場合には、タスク・プログラムに含まれるす
べての資源名を自動的に抽出することによって資源名リ
ストを作成してもよい。資源名リストはユーザが重要資
源名を指定して作成してもよい。
らこのような中間コードを生成するためのアルゴリズム
を示すフロー・チャートである。なお、すべての資源が
重要である場合には、タスク・プログラムに含まれるす
べての資源名を自動的に抽出することによって資源名リ
ストを作成してもよい。資源名リストはユーザが重要資
源名を指定して作成してもよい。
（Ｃ）プロセス・リソース・グラフの生成（ステップS
4、S5、S6） ソフトウェアによつて実行されるプロセス・リソース・
グラフの生成の過程を、 フロー・チャートとして第11図に示す。このフロー・チ
ャートに従って説明を行う。プロセス・フロー・グラフ
と資源管理グラフをロードし（ステップ111、112）、そ
れらから共通結合のグラフを生成する（ステップ11
3）。
4、S5、S6） ソフトウェアによつて実行されるプロセス・リソース・
グラフの生成の過程を、 フロー・チャートとして第11図に示す。このフロー・チ
ャートに従って説明を行う。プロセス・フロー・グラフ
と資源管理グラフをロードし（ステップ111、112）、そ
れらから共通結合のグラフを生成する（ステップ11
3）。
第７図のプロセス・リソース・グラフと第９図の資源管
理グラフから生成される共通結合のグラフを、第12図に
示す。
理グラフから生成される共通結合のグラフを、第12図に
示す。
共通結合グラフの中間コードの書式を、プロセス・フロ
ー・グラフの中間コードの書式と同じにすると、第12図
の共通結合グラフの中間コード表現は、下記のようにな
る。
ー・グラフの中間コードの書式と同じにすると、第12図
の共通結合グラフの中間コード表現は、下記のようにな
る。
C1:/T1、T2、RA、RB C2:T1、T2、RA、RB/T3、RB C3:T3、RB/ C4:/T4、RA C5:T4、RA/T5、RA、RB C6:T5、RA、RB/ 第13図は、プロセス・フロー・グラフと資源管理グラフ
とからこのような中間コードを生成するためのアルゴリ
ズムを示すフロー・チャートである。つまり、第11図の
ステップ113を詳述したものである。
とからこのような中間コードを生成するためのアルゴリ
ズムを示すフロー・チャートである。つまり、第11図の
ステップ113を詳述したものである。
ところで、このようにして生成された共通結合のグラフ
を無条件でそのままプロセス・リソース・グラフと見做
すと、デッドロックが生じる場合がある。
を無条件でそのままプロセス・リソース・グラフと見做
すと、デッドロックが生じる場合がある。
第14図を使ってデッドロックが生じる場合を示す。初期
状態としてトークンがコンディション・ゲイトC1にあ
る。タスクT1が資源PAを使い、タスクT2が資源RA、RBを
使いながら実行しなければならないので、デッドロック
が起きる。
状態としてトークンがコンディション・ゲイトC1にあ
る。タスクT1が資源PAを使い、タスクT2が資源RA、RBを
使いながら実行しなければならないので、デッドロック
が起きる。
本実施例では、共通結合のグラフのデッドロックが生じ
ないグラフを、プロセス・リソース・グラフとする。こ
れに従って実行すると、事象駆動型プロセスの制御と資
源の相互排他制御が同時に行える。共通結合のグラフが
デッドロックを生じる場合は、それをユーザに表示す
る。
ないグラフを、プロセス・リソース・グラフとする。こ
れに従って実行すると、事象駆動型プロセスの制御と資
源の相互排他制御が同時に行える。共通結合のグラフが
デッドロックを生じる場合は、それをユーザに表示す
る。
本実施例では、この共通結合のグラフで起こりうるデッ
ド・ロックは、プロセス・フロー・グラフと資源管理グ
ラフから共通結合のグラフが生成された時点で、デッド
ロックのチェックを行って（ステップ114）、表示して
いる（ステップ115）。
ド・ロックは、プロセス・フロー・グラフと資源管理グ
ラフから共通結合のグラフが生成された時点で、デッド
ロックのチェックを行って（ステップ114）、表示して
いる（ステップ115）。
第14図を共通結合グラフの形で表現したものが第15図で
ある。第15図に示すごとく、デッドロックの起こる場合
とは、コンディション・ゲートと資源プレースとが重複
してつながる場合のことである。生成された共通結合の
グラフの中に１つのコンディション・ゲートと重複して
つながれた資源があるか否かチェックし、あればそれを
ユーザに指摘してやればよい。デットロックが生じない
ならば、共通結合グラフはそのままプロセス・リソース
・グラフとされる（ステップ116）。
ある。第15図に示すごとく、デッドロックの起こる場合
とは、コンディション・ゲートと資源プレースとが重複
してつながる場合のことである。生成された共通結合の
グラフの中に１つのコンディション・ゲートと重複して
つながれた資源があるか否かチェックし、あればそれを
ユーザに指摘してやればよい。デットロックが生じない
ならば、共通結合グラフはそのままプロセス・リソース
・グラフとされる（ステップ116）。
なお、ここで言うデットロックとは、第６図に関して説
明したグラフ表現及びそれに従って制御するシステムの
責任で起こるものではない。後述するように、本発明に
よれば、第６図の如きデッド・ロックの発生は回避され
る。第11図のステップ115で表示されるデッドロック
は、プログラムの構造自体に起因して生じるものであ
り、ユーザの責任でこれを回避しなければならない（ス
テップ117）。
明したグラフ表現及びそれに従って制御するシステムの
責任で起こるものではない。後述するように、本発明に
よれば、第６図の如きデッド・ロックの発生は回避され
る。第11図のステップ115で表示されるデッドロック
は、プログラムの構造自体に起因して生じるものであ
り、ユーザの責任でこれを回避しなければならない（ス
テップ117）。
プロセス・リソース・グラフは、イベント・プレースと
コンディション・ゲイトをノードとし入力関数と出力関
数をアークとする二部有効グラフである。マーキングは
プロセス・リソース・グラフのタスク・プレース、資源
プレース、コンディション、ゲイトにトークンを割り当
てることをいう。また、トークンはタスク・プレース、
資源プレース、コンディション・ゲイトに高々一つ存在
できる。従来のペトリネットでは、コンディション・ゲ
イトにはトークンは割り当てられないが、プロセス・リ
ソース・グラフでは割り当てがおこなわれる。プロセス
・リソース・グラフの定義は、［数学的な表現］の項を
参照されたい。
コンディション・ゲイトをノードとし入力関数と出力関
数をアークとする二部有効グラフである。マーキングは
プロセス・リソース・グラフのタスク・プレース、資源
プレース、コンディション、ゲイトにトークンを割り当
てることをいう。また、トークンはタスク・プレース、
資源プレース、コンディション・ゲイトに高々一つ存在
できる。従来のペトリネットでは、コンディション・ゲ
イトにはトークンは割り当てられないが、プロセス・リ
ソース・グラフでは割り当てがおこなわれる。プロセス
・リソース・グラフの定義は、［数学的な表現］の項を
参照されたい。
なお、第12図に示した共通結合グラフつまりプロセス・
リソース・グラフにおいては、すべてのタスク・ノード
について、これと並列に資源ノードが配置されている。
しかしながら、タスクの中には重要資源にアクセスする
ことのないものもある。そういうタスクのノードには当
然資源ノードが並列に配置されない（第18図参照）。
リソース・グラフにおいては、すべてのタスク・ノード
について、これと並列に資源ノードが配置されている。
しかしながら、タスクの中には重要資源にアクセスする
ことのないものもある。そういうタスクのノードには当
然資源ノードが並列に配置されない（第18図参照）。
（ｄ）プロセス・リソース・グラフの実行（ステップS
7、S8） プロセス・リソース・グラフは、逐次的利用可能資源の
相互排他制御と同時に事象駆動型の制御を行なうコント
ローラのコードに変換され、実行されるコントローラ
（計算機およびプログラマブル・ロジック・コントロー
ラなど）のメモリー、ROM等にロードされる。このグラ
フを実行すると、資源の相互排他制御と事象駆動型のプ
ロセスの制御が同時に行われる。例えばプロセス・リソ
ース・グラフのノード（イベント・プレース、コンディ
ション・ゲート）はメモリー中にデータ構造体として実
現され、要素間のつながりはポインタによって表現され
る。トークンの存在に関する情報は、データ構造体の中
に記憶される。トークンを発生または消滅させる方法自
体は上記文献（２）のシステムと同様に行われるので、
ここでは詳細に述べない。
7、S8） プロセス・リソース・グラフは、逐次的利用可能資源の
相互排他制御と同時に事象駆動型の制御を行なうコント
ローラのコードに変換され、実行されるコントローラ
（計算機およびプログラマブル・ロジック・コントロー
ラなど）のメモリー、ROM等にロードされる。このグラ
フを実行すると、資源の相互排他制御と事象駆動型のプ
ロセスの制御が同時に行われる。例えばプロセス・リソ
ース・グラフのノード（イベント・プレース、コンディ
ション・ゲート）はメモリー中にデータ構造体として実
現され、要素間のつながりはポインタによって表現され
る。トークンの存在に関する情報は、データ構造体の中
に記憶される。トークンを発生または消滅させる方法自
体は上記文献（２）のシステムと同様に行われるので、
ここでは詳細に述べない。
本発明で提唱するトークンの移動条件は後で厳密に式
（１）、（２）の形で表現するが、その意味する所を言
葉で述べると、次の通りになる。
（１）、（２）の形で表現するが、その意味する所を言
葉で述べると、次の通りになる。
（Ｉ）タスクの実行開始を命じると同時に該タスクのプ
レース（ノード）及び該プレースに並列な資源のプレー
スにトークンを置く、つまり、本発明においては、従来
のペトリネット・モデルと異なって、資源プレースに置
かれたトークンは、その資源が実行中のタスクによって
専有されていることを示す。
レース（ノード）及び該プレースに並列な資源のプレー
スにトークンを置く、つまり、本発明においては、従来
のペトリネット・モデルと異なって、資源プレースに置
かれたトークンは、その資源が実行中のタスクによって
専有されていることを示す。
（II）並列制御されるタスクがあるときは、そのタスク
すべての実行が終了した時点で、トークンを後続のコン
ディション・ゲイトに移動させる。
すべての実行が終了した時点で、トークンを後続のコン
ディション・ゲイトに移動させる。
（III）コンディション・ゲイトに直接続くタスク・プ
レースまたは該タスク・プレースに並列な資源プレース
のうちの少なくとも１つにトークンが置かれている間
は、トークンをコンディション・ゲイトに置き続けるこ
とによって、後続タスクの実行開始を待機させる。
レースまたは該タスク・プレースに並列な資源プレース
のうちの少なくとも１つにトークンが置かれている間
は、トークンをコンディション・ゲイトに置き続けるこ
とによって、後続タスクの実行開始を待機させる。
第12図のプロセス・リソース・グラフの定義に従った実
行を、実行制御の一例として第16図に示す。第12図で
は、初めにトークンがコンディション・ゲイトC1に発生
する場合とコンディション・ゲイトC4に発生する場合が
ある。本実行例では、初めにトークンがコンディション
・ゲイトC1に発生する場合を取り扱う。トークンがコン
ディション・ゲイトC1に発生する（第16A図）このよう
に、タスクT1、T2を実行させることが必要になっても、
いきなりプレースT1、T2にトークンを置くことはない。
まずコンディション・ゲイトC1にトークンが置かれる。
トークンは移動条件式（１）によってコンディション・
ゲイトC1からタスク・プレースT1、T2と資源プレース
RA、RBに移動する（第16B図）。このとき、他のコンデ
ィション・ゲイトにトークンが存在しても、資源プレー
スRA、RBにトークンが存在しているため、移動条件式
（１）が満足できない。このためにトークンの移動がお
こらず、T1、T2以外の新しいタスクの実行はおこなわれ
ない。タスクT1、T2がどちらも終了すると、トークンは
移動条件式（２）によってタスク・プレートT1、T2と資
源プレースRA、RBからコンディション・ゲイトC2に移動
する（第16C図）。さらにトークンは、移動条件式
（１）によってコンディション・ゲイトC2からタスク・
プレースT3と資源プレースRBに移動する（第16D図）。
このとき、コンディション・ゲイトC4にトークンが発生
したとしよう。タスクT4の実行は開始できる。つまり、
資源プレースRAにはトークンがないために、移動条件式
（１）が満たされるので、タスク・プレースT4と資源プ
レースRAへのトークンの移動はおこなわれる（第16E
図）。したがって資源RBを使うタスクT3の実行と、資源
RAを使うタスクT4の実行が独立におこなわれる。T4が終
了すると、トークンは、移動条件式（２）によってタス
ク・プレースT4と資源プレースRAからコンディション・
ゲイトC5に移動する（第16F図）。
行を、実行制御の一例として第16図に示す。第12図で
は、初めにトークンがコンディション・ゲイトC1に発生
する場合とコンディション・ゲイトC4に発生する場合が
ある。本実行例では、初めにトークンがコンディション
・ゲイトC1に発生する場合を取り扱う。トークンがコン
ディション・ゲイトC1に発生する（第16A図）このよう
に、タスクT1、T2を実行させることが必要になっても、
いきなりプレースT1、T2にトークンを置くことはない。
まずコンディション・ゲイトC1にトークンが置かれる。
トークンは移動条件式（１）によってコンディション・
ゲイトC1からタスク・プレースT1、T2と資源プレース
RA、RBに移動する（第16B図）。このとき、他のコンデ
ィション・ゲイトにトークンが存在しても、資源プレー
スRA、RBにトークンが存在しているため、移動条件式
（１）が満足できない。このためにトークンの移動がお
こらず、T1、T2以外の新しいタスクの実行はおこなわれ
ない。タスクT1、T2がどちらも終了すると、トークンは
移動条件式（２）によってタスク・プレートT1、T2と資
源プレースRA、RBからコンディション・ゲイトC2に移動
する（第16C図）。さらにトークンは、移動条件式
（１）によってコンディション・ゲイトC2からタスク・
プレースT3と資源プレースRBに移動する（第16D図）。
このとき、コンディション・ゲイトC4にトークンが発生
したとしよう。タスクT4の実行は開始できる。つまり、
資源プレースRAにはトークンがないために、移動条件式
（１）が満たされるので、タスク・プレースT4と資源プ
レースRAへのトークンの移動はおこなわれる（第16E
図）。したがって資源RBを使うタスクT3の実行と、資源
RAを使うタスクT4の実行が独立におこなわれる。T4が終
了すると、トークンは、移動条件式（２）によってタス
ク・プレースT4と資源プレースRAからコンディション・
ゲイトC5に移動する（第16F図）。
トークンがコンディション・ゲイトC5に存在しても、資
源プレースRBにすでにトークンがあるにトークンがある
ために、コンディション・ゲイトC5からタスク・プレー
スT5と資源プレースRA、RBへのトークンの移動は、移動
条（１）が満たされないために、おこなわれない。つま
りタスクT5は実行されない。タスクT3が終了すると、ト
ークンは、移動条件式（２）によってタスク・プレース
T3と資源プレースRBからコンディション・ゲイトC3に移
動し、消滅する。したがって、タスクT5が実行可能にな
る。
源プレースRBにすでにトークンがあるにトークンがある
ために、コンディション・ゲイトC5からタスク・プレー
スT5と資源プレースRA、RBへのトークンの移動は、移動
条（１）が満たされないために、おこなわれない。つま
りタスクT5は実行されない。タスクT3が終了すると、ト
ークンは、移動条件式（２）によってタスク・プレース
T3と資源プレースRBからコンディション・ゲイトC3に移
動し、消滅する。したがって、タスクT5が実行可能にな
る。
第12図の例でも見られるようにプロセス・リソース・グ
ラフは資源プレースRA、RBに対して自己ループのあるグ
ラフとなる。これを安全で且つ活性の性質を持つ制限さ
れたペトリネットを見做すと、タスクが連続して、すぐ
同じ資源を使おうとすると、デッドロックが起こる。例
えば第12図では、タスクT4が資源RAを使う実行を終了し
たのち、タスクT5と資源RA、RBを使う実行をしようとし
た場合、資源RAに対して自己ループのグラフとなり、後
述する移動条件式（０）が常に満たされずデッドロック
が起こる。
ラフは資源プレースRA、RBに対して自己ループのあるグ
ラフとなる。これを安全で且つ活性の性質を持つ制限さ
れたペトリネットを見做すと、タスクが連続して、すぐ
同じ資源を使おうとすると、デッドロックが起こる。例
えば第12図では、タスクT4が資源RAを使う実行を終了し
たのち、タスクT5と資源RA、RBを使う実行をしようとし
た場合、資源RAに対して自己ループのグラフとなり、後
述する移動条件式（０）が常に満たされずデッドロック
が起こる。
この点について説明を補足する。まず第12図のようなグ
ラフ表現自体が新規であることに注意されたい。（従来
のペトリネットとの相違点は、後で第６図と第18図を対
比させてさらに詳しく述べる）。次に、本発明のトーク
ン移動法を採用して、資源が専有されているときに対応
する資源プレースにトークンを置くけれども、コンディ
ション・ゲートにはトークンを置かない実施例を想定し
てみる。この例においては、タスクT4の実行中に、プレ
ースT4とRAにトークンが置かれる。次に、制御システム
がタスクT5の実行を開始しようとしても、つまり、プレ
ースT4からプレースT5とプレースRA、RBにトークンを、
進めようとしても、プレースRAにトークンが既に置かれ
ているので、トークンをプレースT5に進めることができ
ない。そして、トークンがプレースT5に進まない限り
は、プレースRAのトークンも消滅しないのである。
ラフ表現自体が新規であることに注意されたい。（従来
のペトリネットとの相違点は、後で第６図と第18図を対
比させてさらに詳しく述べる）。次に、本発明のトーク
ン移動法を採用して、資源が専有されているときに対応
する資源プレースにトークンを置くけれども、コンディ
ション・ゲートにはトークンを置かない実施例を想定し
てみる。この例においては、タスクT4の実行中に、プレ
ースT4とRAにトークンが置かれる。次に、制御システム
がタスクT5の実行を開始しようとしても、つまり、プレ
ースT4からプレースT5とプレースRA、RBにトークンを、
進めようとしても、プレースRAにトークンが既に置かれ
ているので、トークンをプレースT5に進めることができ
ない。そして、トークンがプレースT5に進まない限り
は、プレースRAのトークンも消滅しないのである。
もし、プロセス・リソース・グラフで定義したごとくコ
ンディション・ゲイトにトークンを存在させれば、上述
の実行例で示したように，安全で且つ活性の性質を持つ
制限されたペトリネットで起こるデッドロックは生じな
い。つまり、上の例でいえば、タスクT4の実行が終了し
た時点で、プレースT4とRAのトークンを消滅させ、コン
ディション・ゲイトC5にトークンを発生させることによ
って、プレースRAにトークンが存在しない状態が出現す
るので、トークンをコンディション・ゲイトC5からプレ
ースT5、RA、RBに移すことができる。つまり、タスクT5
の実行を開始することが可能になる。コンディション・
ゲイトにトークンを置くことの意義はこの点にある。
ンディション・ゲイトにトークンを存在させれば、上述
の実行例で示したように，安全で且つ活性の性質を持つ
制限されたペトリネットで起こるデッドロックは生じな
い。つまり、上の例でいえば、タスクT4の実行が終了し
た時点で、プレースT4とRAのトークンを消滅させ、コン
ディション・ゲイトC5にトークンを発生させることによ
って、プレースRAにトークンが存在しない状態が出現す
るので、トークンをコンディション・ゲイトC5からプレ
ースT5、RA、RBに移すことができる。つまり、タスクT5
の実行を開始することが可能になる。コンディション・
ゲイトにトークンを置くことの意義はこの点にある。
プロセス・リソース・グラフの実行コードは実行される
コントローラのメモリー、ROM等にロードされる。ここ
で制御する逐次的利用可能資源の対象は、計算機および
プログラマブル・ロジック・コントローラ（PLC）など
が制御する資源である。これらの資源は、実際にコント
ローラの中に含まれる資源のみならず、通信等を介して
制御可能な資源も含む。本発明では、これらの制御対象
となる逐次的利用可能資源に対して、プロセス・リソー
ス・グラフの実行コードに基づいて、事象駆動型のプロ
セスの制御と同時に資源の相互排他制御が行なわれる。
第17図はプロセス・リソース・グラフの実行コードをPL
Cのメモリーにロードしてかかる制御を行うシステムの
ハードウェア構成の１例を示す。この例では生産機器
１、２、３…が重要資源であり、これらの機器を用いる
タスクが第８図に示すようなタスク・プログラムの形で
記述される。タスク・プログラムの実行開始指示信号及
び該プログラムの実行が終了したことを知らせる終了信
号は、デジタル入出力インターフェイス又は通信インタ
ーフェイスを介して、PLCと生産機器間を転送される。
タスクの実行終了は、生産機器がPLCに対して信号を送
ることによって検知される。あるいは、PLCが生産機器
の状態をモニタすることによってその状態が終了状態に
転じたことを検知してもよい。
コントローラのメモリー、ROM等にロードされる。ここ
で制御する逐次的利用可能資源の対象は、計算機および
プログラマブル・ロジック・コントローラ（PLC）など
が制御する資源である。これらの資源は、実際にコント
ローラの中に含まれる資源のみならず、通信等を介して
制御可能な資源も含む。本発明では、これらの制御対象
となる逐次的利用可能資源に対して、プロセス・リソー
ス・グラフの実行コードに基づいて、事象駆動型のプロ
セスの制御と同時に資源の相互排他制御が行なわれる。
第17図はプロセス・リソース・グラフの実行コードをPL
Cのメモリーにロードしてかかる制御を行うシステムの
ハードウェア構成の１例を示す。この例では生産機器
１、２、３…が重要資源であり、これらの機器を用いる
タスクが第８図に示すようなタスク・プログラムの形で
記述される。タスク・プログラムの実行開始指示信号及
び該プログラムの実行が終了したことを知らせる終了信
号は、デジタル入出力インターフェイス又は通信インタ
ーフェイスを介して、PLCと生産機器間を転送される。
タスクの実行終了は、生産機器がPLCに対して信号を送
ることによって検知される。あるいは、PLCが生産機器
の状態をモニタすることによってその状態が終了状態に
転じたことを検知してもよい。
なお、タスク・プログラムは、生産機器側にて蓄積され
ていてよいし、PLCのメモリに蓄積しておいて、命令を
逐次PLCから生産機器へ転送してもよい。
ていてよいし、PLCのメモリに蓄積しておいて、命令を
逐次PLCから生産機器へ転送してもよい。
最後に、まとめとして、第６図に示すようなプロセスの
流れを本発明に従って表現した結果であるプロセス・リ
ソース・グラフを第18図に示し、その実行例を第19A図
ないし第19D図に示す。
流れを本発明に従って表現した結果であるプロセス・リ
ソース・グラフを第18図に示し、その実行例を第19A図
ないし第19D図に示す。
第18図に示す如く、連続する２つのタスク（例えばP2、
P3）によってある資源（この場合はPx）が使用される場
合でも、その各々と並列に資源プレースがつながれる点
及び、第６図の場合には例えばプレースPxがトランジシ
ョンt1の入力側につながれていたのが第18図ではプレー
スPxがコンディション・ゲイトC1の出力側につながれて
いるといった具合に、入出力の関係が逆になる点におい
て、両グラフは大きく異なっている。
P3）によってある資源（この場合はPx）が使用される場
合でも、その各々と並列に資源プレースがつながれる点
及び、第６図の場合には例えばプレースPxがトランジシ
ョンt1の入力側につながれていたのが第18図ではプレー
スPxがコンディション・ゲイトC1の出力側につながれて
いるといった具合に、入出力の関係が逆になる点におい
て、両グラフは大きく異なっている。
次に、本発明に従ってトークンを移動させていく実行例
を見てみる。まず、コンディション・ゲイトC1とC4にト
ークンが発生したとしよう（第19A図）。資源Px、Pyの
プレースの何れにもトークンがないならば、制御システ
ムは、コンデイション・ゲイトC1からプレースP2、Pxに
トークンを移す一方、コンディション、ゲイトC4からプ
レースP5、Pyにトークンを移すことができる（第19B
図）。つまり、タスクP2、P5の実行が開始される。次
に、タスクP2の実行が終了したとしよう。このとき、制
御システムは、プレースP2、Pxのトークンを消滅させ
て、コンディション・ゲイトC2にトークンを発生させる
（第19C図）。この時点では、まだプレースPyにトーク
ンがあるので、プレースP3にトークンを進めることはで
きない。よって、プロセスＡにおいて、トークンはコン
ディション・ゲイトC2に存在し続けて、資源Pyが解放さ
れるのを待つことになる。次に、制御システムは、タス
クP5の終了信号を受け取ると、プレースP5、Pyのトーク
ンを消滅させて、トークンをコンディション・ゲイトC5
にトークンが発生させる（第19D図）。制御システム
は、プレースP3とPx、Pyにトークンを進めることもでき
るし、又はプレースP6とPxにトークンを進めることもで
きる。すなわち、タスクP3、又はP6の実行開始を命じる
ことができる。このように、第６図の場合に生じたデッ
ドロックは起こらない。
を見てみる。まず、コンディション・ゲイトC1とC4にト
ークンが発生したとしよう（第19A図）。資源Px、Pyの
プレースの何れにもトークンがないならば、制御システ
ムは、コンデイション・ゲイトC1からプレースP2、Pxに
トークンを移す一方、コンディション、ゲイトC4からプ
レースP5、Pyにトークンを移すことができる（第19B
図）。つまり、タスクP2、P5の実行が開始される。次
に、タスクP2の実行が終了したとしよう。このとき、制
御システムは、プレースP2、Pxのトークンを消滅させ
て、コンディション・ゲイトC2にトークンを発生させる
（第19C図）。この時点では、まだプレースPyにトーク
ンがあるので、プレースP3にトークンを進めることはで
きない。よって、プロセスＡにおいて、トークンはコン
ディション・ゲイトC2に存在し続けて、資源Pyが解放さ
れるのを待つことになる。次に、制御システムは、タス
クP5の終了信号を受け取ると、プレースP5、Pyのトーク
ンを消滅させて、トークンをコンディション・ゲイトC5
にトークンが発生させる（第19D図）。制御システム
は、プレースP3とPx、Pyにトークンを進めることもでき
るし、又はプレースP6とPxにトークンを進めることもで
きる。すなわち、タスクP3、又はP6の実行開始を命じる
ことができる。このように、第６図の場合に生じたデッ
ドロックは起こらない。
以上、本発明を実施例に即して説明したが、他の変形例
も考えられる。例えば、前記実施例では、プロセス・フ
ロー・グラフと資源管理グラフを中間コードの形で生成
し、プロセス・リソース・グラフは一旦中間コードの形
で生成した後実行コードに変換したけれども、要するに
これらのグラフは図面に示したものと等価な表現をメモ
リ中に生成できればよいわけであるから、その表現形式
は特に制約されない。
も考えられる。例えば、前記実施例では、プロセス・フ
ロー・グラフと資源管理グラフを中間コードの形で生成
し、プロセス・リソース・グラフは一旦中間コードの形
で生成した後実行コードに変換したけれども、要するに
これらのグラフは図面に示したものと等価な表現をメモ
リ中に生成できればよいわけであるから、その表現形式
は特に制約されない。
［数学的な表現］ プロセス・フロー・グラフ理論の定義に従って以下に記
述する。プロセス・フロー・グラフGPFは、 GPF＝（Ｔ、Ｃ、IT、OT、μ） ここで、 Ｔ＝｛T1、T2、…、TM｝、Ｍ＞０タスク・プレースの集
合 Ｃ＝｛C1、C2、…CL｝、Ｌ＞１コンディション・ゲイト
の集合 Ｔ∩Ｃ＝φタスク・プレースの集合とコンディション・
ゲイトの集合とは互いに素である IT:T−＞Ｃタスク・プレースからコンディション・ゲイ
トへの入力関数 OT:C−＞Ｔコンディション・ゲイトからタスク・プレー
スへの出力関数 μ:T−＞｛０、１｝タスク・プレースのマーキング関数 任意の時刻ｔにおける、任意のコンディション・ゲイト
CKに関するタスク・プレースTiからToへのトークンの移
動条件式は、 但し、m1＞０、m2＞０ となる。時刻ｔ＋１における新しいマーキングは、タス
ク・プレースT1では、 μ（Ti（ｔ＋１）） ＝μ（Ti（ｔ））−＃（Ti、To）（ｔ）ｉ＝１…m1 タスク・プレースToでは、 μ（To（ｔ＋１）） ＝μ（To（ｔ））＋＃（Ti、To）（ｔ）ｏ＝１…m2 となる。
述する。プロセス・フロー・グラフGPFは、 GPF＝（Ｔ、Ｃ、IT、OT、μ） ここで、 Ｔ＝｛T1、T2、…、TM｝、Ｍ＞０タスク・プレースの集
合 Ｃ＝｛C1、C2、…CL｝、Ｌ＞１コンディション・ゲイト
の集合 Ｔ∩Ｃ＝φタスク・プレースの集合とコンディション・
ゲイトの集合とは互いに素である IT:T−＞Ｃタスク・プレースからコンディション・ゲイ
トへの入力関数 OT:C−＞Ｔコンディション・ゲイトからタスク・プレー
スへの出力関数 μ:T−＞｛０、１｝タスク・プレースのマーキング関数 任意の時刻ｔにおける、任意のコンディション・ゲイト
CKに関するタスク・プレースTiからToへのトークンの移
動条件式は、 但し、m1＞０、m2＞０ となる。時刻ｔ＋１における新しいマーキングは、タス
ク・プレースT1では、 μ（Ti（ｔ＋１）） ＝μ（Ti（ｔ））−＃（Ti、To）（ｔ）ｉ＝１…m1 タスク・プレースToでは、 μ（To（ｔ＋１）） ＝μ（To（ｔ））＋＃（Ti、To）（ｔ）ｏ＝１…m2 となる。
トークンの発生は、コンディション・ゲイトCkにおい
て、入力関数ITがない場合であり、移動条件式の右辺の
項を、 としたときである。
て、入力関数ITがない場合であり、移動条件式の右辺の
項を、 としたときである。
トークンの消滅は、コンディション・ゲイトCKにおい
て、出力関数OTがない場合であり、移動条件式の右辺の
項を、 としたときである。
て、出力関数OTがない場合であり、移動条件式の右辺の
項を、 としたときである。
プロセス・リソース・グラフをグラフ理論の定義に従っ
て以下に記述する。プロセス・リソース・グラフG
PRは、 GPR＝（Ｔ∪R,C,IT∪IR,OT∪OR,uT∪uR∪uC） ここで、 Ｔ＝｛T1,T2,…,TM｝,M＞０タスク・プレースの集合 Ｒ＝｛R1,R2,…,RN｝,N≧０資源プレースの集合 Ｃ＝｛C1,C2,…,CL｝,L＞１コンディション・ゲイトの
集合 Ｔ∩Ｒ∩Ｃ＝φ タスク・プレースの集合と資源プレー
スの集合とコンディション・ゲイトの集合とは互いに素
である IT:T−＞Ｃ タスク・プレースからコンディション・ゲ
イトの入力関数 IR:R−＞Ｃ 資源プレースからコンディション・ゲイト
への入力関数 IT∩IR＝φ 入力関数ITと入力関数IRとは互いに素であ
る OT:C−＞Ｔ コンディション・ゲイトからタスク・プレ
ースへの出力関数 OR:C−＞Ｒ コンディション・ゲイトから資源プレース
への出力関数 OT∩OR＝φ 出力関数OTと出力ORとは互いに素である μT:T−＞｛０、１｝タスク・プレースのマーキング関
数 μR:R−＞｛０、１｝資源プレースのマーキング関数 μC:C−＞｛０、１｝コンディション・ゲイトのマーキ
ング関数 μＴ∩μＲ∩μＣ＝φ マーキング関数μＴとマーキン
グ関数μＲとマーキング関数μＣとは互いに素である 任意の時刻ｔにおける、任意のコンディション・ゲイト
CKからイベント・プレースＴおよびＲへのトークンの移
動条件式は、 但し、ｍ＞０、ｎ＞０ となる。時刻ｔ＋１における新しいマーキングは、コン
ディション・ゲイトCKでは、 μ（Ck（ｔ＋１）） ＝μ（CK（ｔ））−＃（ｃ、ｐ）（ｔ） タスク・プレースＴでは、 μ（Ti（ｔ＋１）） ＝μ（ti（ｔ））＋＃（ｃ、ｐ）（ｔ）ｉ＝１…ｍ 資源プレースＲでは、 μ（Rj（ｔ＋１）） ＝μ（Rj（ｔ））＋＃（ｃ、ｐ）（ｔ）ｊ＝１…ｎ となる。
て以下に記述する。プロセス・リソース・グラフG
PRは、 GPR＝（Ｔ∪R,C,IT∪IR,OT∪OR,uT∪uR∪uC） ここで、 Ｔ＝｛T1,T2,…,TM｝,M＞０タスク・プレースの集合 Ｒ＝｛R1,R2,…,RN｝,N≧０資源プレースの集合 Ｃ＝｛C1,C2,…,CL｝,L＞１コンディション・ゲイトの
集合 Ｔ∩Ｒ∩Ｃ＝φ タスク・プレースの集合と資源プレー
スの集合とコンディション・ゲイトの集合とは互いに素
である IT:T−＞Ｃ タスク・プレースからコンディション・ゲ
イトの入力関数 IR:R−＞Ｃ 資源プレースからコンディション・ゲイト
への入力関数 IT∩IR＝φ 入力関数ITと入力関数IRとは互いに素であ
る OT:C−＞Ｔ コンディション・ゲイトからタスク・プレ
ースへの出力関数 OR:C−＞Ｒ コンディション・ゲイトから資源プレース
への出力関数 OT∩OR＝φ 出力関数OTと出力ORとは互いに素である μT:T−＞｛０、１｝タスク・プレースのマーキング関
数 μR:R−＞｛０、１｝資源プレースのマーキング関数 μC:C−＞｛０、１｝コンディション・ゲイトのマーキ
ング関数 μＴ∩μＲ∩μＣ＝φ マーキング関数μＴとマーキン
グ関数μＲとマーキング関数μＣとは互いに素である 任意の時刻ｔにおける、任意のコンディション・ゲイト
CKからイベント・プレースＴおよびＲへのトークンの移
動条件式は、 但し、ｍ＞０、ｎ＞０ となる。時刻ｔ＋１における新しいマーキングは、コン
ディション・ゲイトCKでは、 μ（Ck（ｔ＋１）） ＝μ（CK（ｔ））−＃（ｃ、ｐ）（ｔ） タスク・プレースＴでは、 μ（Ti（ｔ＋１）） ＝μ（ti（ｔ））＋＃（ｃ、ｐ）（ｔ）ｉ＝１…ｍ 資源プレースＲでは、 μ（Rj（ｔ＋１）） ＝μ（Rj（ｔ））＋＃（ｃ、ｐ）（ｔ）ｊ＝１…ｎ となる。
任意の時刻ｔにおける、任意のコンディション・ゲイト
CKへイベント・プレースＴおよびＲからのトークンの移
動条件式は、 但し、ｍ＞０、ｎ＞０ となる。時刻ｔ＋１における新しいマーキングは、コン
ディション・ゲイトCKでは、 μ（Ck（ｔ＋１）） ＝μ（CK（ｔ））−＃（ｐ、ｃ）（ｔ） タスク・プレースＴでは、 μ（Ti（ｔ＋１）） ＝μ（Ti（ｔ））−＃（ｐ、ｃ）（ｔ）ｉ＝１…ｍ 資源プレースＲでは、 μ（Rj（ｔ＋１）） ＝μ（Rj（ｔ））−＃（ｐ、ｃ）（ｔ）ｊ＝１…ｎ となる。
CKへイベント・プレースＴおよびＲからのトークンの移
動条件式は、 但し、ｍ＞０、ｎ＞０ となる。時刻ｔ＋１における新しいマーキングは、コン
ディション・ゲイトCKでは、 μ（Ck（ｔ＋１）） ＝μ（CK（ｔ））−＃（ｐ、ｃ）（ｔ） タスク・プレースＴでは、 μ（Ti（ｔ＋１）） ＝μ（Ti（ｔ））−＃（ｐ、ｃ）（ｔ）ｉ＝１…ｍ 資源プレースＲでは、 μ（Rj（ｔ＋１）） ＝μ（Rj（ｔ））−＃（ｐ、ｃ）（ｔ）ｊ＝１…ｎ となる。
トークンの発生は、コンディション・ゲイトCKにおい
て、入力関数IT、IRがない場合であり、移動条件式
（２）の右辺を項を、 としたときである。
て、入力関数IT、IRがない場合であり、移動条件式
（２）の右辺を項を、 としたときである。
トークンの消滅は、コンディション・ゲイトCKにおい
て、出力関数OT、ORがない場合であり、移動条件式
（１）の右辺の項を、 としたときである。
て、出力関数OT、ORがない場合であり、移動条件式
（１）の右辺の項を、 としたときである。
E.効果 この発明により、ユーザが事象駆動型の制御（プロセス
・フロー・グラフとタスク・プログラム）を記述するだ
けで、逐次的利用可能資源相互排他制御と同時に事象駆
動型の制御を行なうことが可能になる。この発明では、
今までプログラマの責任であったプロセス中の資源管理
のプログラミングと実行を自動的に行ない、プログラマ
により資源管理プログラムにエラー及びオペレータのプ
ログラム実行の負担がなくなる。
・フロー・グラフとタスク・プログラム）を記述するだ
けで、逐次的利用可能資源相互排他制御と同時に事象駆
動型の制御を行なうことが可能になる。この発明では、
今までプログラマの責任であったプロセス中の資源管理
のプログラミングと実行を自動的に行ない、プログラマ
により資源管理プログラムにエラー及びオペレータのプ
ログラム実行の負担がなくなる。
また、本発明によれば、従来の如くペトリネット・モデ
ルで起こり得たデッドロックが、トークンをコンディシ
ョン・ゲートのノードに置くことによって生じない、と
いう利点も得られる。
ルで起こり得たデッドロックが、トークンをコンディシ
ョン・ゲートのノードに置くことによって生じない、と
いう利点も得られる。
第１図は、この発明の実施例のシステム構成図である。
第２図は、プロセスの流れの概念図である。第３図は、
従来技術による相互排他制御プログラムの記述例を示す
説明図である。第４図は、ペトリネットの実行例の説明
図である。第５図は、ペトリネットを用いた相互排他制
御のモデルの説明図である。第６図は、従来のペトリネ
ットを実行させて仮に相互排他制御を行った場合に生じ
るデッドロックの説明図である。第７図はプロセス・フ
ロー・グラフの説明図である。第８図はプロセス・フロ
ー・グラフとタスク・プログラムの説明図である。第９
図は資源管理グラフの説明図である。第10図は資源管理
グラフを生成するための処理手順のフロー・チャートで
ある。第11図はプロセス・リソース・グラフを生成する
ための処理手順のフローチャートである。第12図はプロ
セス・リソース・グラフの説明図である。第13図はプロ
セス・フロー・グラフと資源管理グラフの共通結合グラ
フを生成するための処理手順のフロー・チャートであ
る。第14図はデッドロックを生じるプロセスの流れの説
明図である。第15図は第14図の内容の共通結合グラフ表
現を示す図である。第16図は第12図のプロセス・リソー
ス・グラフの実行例を示す図である。第17図は相互排他
制御システムのハードウェア構成の１例を示す図であ
る。第18図は第６図に対応するプロセス・リソース・グ
ラフを示す図である。第19図は第18図のプロセス・リソ
ース・グラフの実行例を示す図である。
第２図は、プロセスの流れの概念図である。第３図は、
従来技術による相互排他制御プログラムの記述例を示す
説明図である。第４図は、ペトリネットの実行例の説明
図である。第５図は、ペトリネットを用いた相互排他制
御のモデルの説明図である。第６図は、従来のペトリネ
ットを実行させて仮に相互排他制御を行った場合に生じ
るデッドロックの説明図である。第７図はプロセス・フ
ロー・グラフの説明図である。第８図はプロセス・フロ
ー・グラフとタスク・プログラムの説明図である。第９
図は資源管理グラフの説明図である。第10図は資源管理
グラフを生成するための処理手順のフロー・チャートで
ある。第11図はプロセス・リソース・グラフを生成する
ための処理手順のフローチャートである。第12図はプロ
セス・リソース・グラフの説明図である。第13図はプロ
セス・フロー・グラフと資源管理グラフの共通結合グラ
フを生成するための処理手順のフロー・チャートであ
る。第14図はデッドロックを生じるプロセスの流れの説
明図である。第15図は第14図の内容の共通結合グラフ表
現を示す図である。第16図は第12図のプロセス・リソー
ス・グラフの実行例を示す図である。第17図は相互排他
制御システムのハードウェア構成の１例を示す図であ
る。第18図は第６図に対応するプロセス・リソース・グ
ラフを示す図である。第19図は第18図のプロセス・リソ
ース・グラフの実行例を示す図である。
Claims (7)
- 【請求項１】（ａ）プロセスの流れに含まれるタスク及
び何れかのタスクによつて専有され得る重要資源がノー
ドに対応づけられ、逐次実行されるタスクのノードは直
列に配置されるとともに、並列して実行されるタスクの
ノード同士は並列に配置され、重要資源のノードは該重
要資源を専有し得るすべてのタスクのノードの並列に配
置されてなるグラフを作成して記憶装置に保持し、 （ｂ）タスクの実行開始信号を送る度に、上記グラフ中
の該タスクのノード及び該ノードに並列に配置された重
要資源のノードにトークンを発生させ、 プロセスの流れの中で先行するタスクの実行の終了を検
知したとき、上記グラフを参照して、直接の後続タスク
のノード又は該ノードに並列に配置された重要資源のノ
ードの何れか１つにトークンが置かれている間は、直接
の後続タスクの実行開始信号の送出を待機する ことを特徴とする、資源の相互排他制御方法。 - 【請求項２】上記ステツプ（ａ）では、上記グラフにお
いて、連続して実行されるタスクのノード同士を連結す
る位置にゲートのノードが設けられ、 上記ステツプ（ｂ）では、タスクの実行の終了を検知す
る度に、該タスクノード及び該ノードに並列に配置され
た重要資源のノードに存在するトークンを消滅させ、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、 その後、上記グラフを参照して、該ゲート・ノードの直
後に配置された後続タスクのノード又はこれと並列に配
置された重要資源ノードの何れか１つにトークンが存在
している間は、該後続タスクの実行開始信号の送出を待
機し、 該後続タスクの実行開始信号を送つた後に、該ゲート・
ノードのトークンを消滅させることを特徴とする、特許
請求の範囲第１項記載の方法。 - 【請求項３】上記ステツプ（ａ）は、 （a1）プロセスの流れに含まれるタスクのノードとゲー
トのノードからなるプロセス・フロー・グラフを作成す
るステツプ、 （a2）上記タスクの何れかによつて専有され得る重要資
源のノードと上記ゲートのノードからなる資源管理グラ
フを作成するステツプ、 （a3）上記プロセス・フロー・グラフと上記資源管理グ
ラフを上記ゲートのノードを共通にして重ね合わせた共
通結合のグラフを作成して記憶装置に保持するステツプ からなる特許請求の範囲第２項記載の方法。 - 【請求項４】上記ステツプ（a3）は、 プロセス・フロー・グラフと資源管理グラフの共通結合
グラフを作成した後、該共通結合グラフ中のデツドロツ
クを生じさせる箇所の有無をチエツクするステツプと、
デツドロツクを生じさせる箇所があればこのことをユー
ザに表示するステツプとを含む ことを特徴とする、特許請求の範囲第１項ないし第３項
に記載の方法。 - 【請求項５】上記ステツプ（a1）では、プロセス・フロ
ー・グラフを中間コードの形で出力し、 上記ステツプ（a2）では、資源管理グラフを中間コード
の形で出力し、 上記ステツプ（a3）では、共通結合のグラフを一旦中間
コードの形で出力した後、これを実行コードに変換して
記憶装置に保持し、 上記ステツプ（ｂ）では、上記実行コードに基づいて相
互排他制御を行う ことを特徴とする、特許請求の範囲第３項又は第４項記
載の方法。 - 【請求項６】プロセスの流れに含まれるタスク及び何れ
かのタスクによつて専有され得る重要資源がノードに対
応づけられ、逐次実行されるタスクのノードは直列に配
置されるとともに、並列して実行されるタスクのノード
同士は並列に配置され、重要資源のノードは該重要資源
を専有し得るすべてのタスクのノードと並列に配置され
てなるグラフを保持する記憶装置と、 タスクの実行開始信号を送る度に、上記グラフ中の該タ
スクのノード及び該ノードに並列に配置された重要資源
のノードにトークンを発生させる手段と、 プロセスの流れの中で先行するタスクの実行の終了を検
知したとき、上記グラフを参照して、直接の後続タスク
のノード又は該ノードに並列に配置された重要資源のノ
ードの何れか１つにトークンが存在している間は、直接
の後続タスクの実行開始信号の送出を待機する手段 を具備する、資源の相互排他制御システム。 - 【請求項７】プロセスの流れに含まれるタスク及び何れ
かのタスクによつて専用され得る重要資源に対応するノ
ードを持ち、逐次実行されるタスクのノードは直列に配
置されるとともに、並列して実行されるタスクのノード
同士は並列に配置され、タスクのノード同士を連結する
位置にはゲートのノードが配置され、重要資源のノード
は該重要資源を専有し得るすべてのタスクのノードと並
列に配置されてなるグラフを保持する記憶装置と タスクの実行開始信号を送る度に、上記グラフ中の該タ
スクのノード及び該ノードに並列に配置された重要資源
のノードにトークンを発生させる手段と、 タスクの実行の終了を検知する度に、該タスクのノード
及び該ノードに並列に配置された重要資源のノードのト
ークンを消滅させる手段と、 ゲート・ノードの直前に配置された何れのタスク・ノー
ドに対応するタスクについても実行の終了を検知したと
き、該ゲート・ノードにトークンを発生させ、 その後、上記グラフを参照して、該ゲート・ノードの直
後に配置された後続タスクのノード又はこれと並列に配
置された重要資源ノードの何れか１つにトークンが存在
している間は、該後続タスクの実行開始信号の送出を待
機し、 該後続タスクの実行開始信号に送つた後に、該ゲート・
ノードのトークンを消滅させる手段 を具備する、相互排他制御システム。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1031146A JPH0769842B2 (ja) | 1989-02-13 | 1989-02-13 | 資源の相互排他制御方法及びシステム |
| US07/478,818 US5283896A (en) | 1989-02-13 | 1990-02-12 | Method and system for controlling mutually exclusive resources using a modified Petri net process control graph |
| EP90301431A EP0383506B1 (en) | 1989-02-13 | 1990-02-12 | Method and system for mutual exclusive resource control |
| DE69024072T DE69024072T2 (de) | 1989-02-13 | 1990-02-12 | Verfahren und System zur gegenseitig ausschliessenden Betriebsmittelsteuerung |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1031146A JPH0769842B2 (ja) | 1989-02-13 | 1989-02-13 | 資源の相互排他制御方法及びシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH02211546A JPH02211546A (ja) | 1990-08-22 |
| JPH0769842B2 true JPH0769842B2 (ja) | 1995-07-31 |
Family
ID=12323299
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP1031146A Expired - Lifetime JPH0769842B2 (ja) | 1989-02-13 | 1989-02-13 | 資源の相互排他制御方法及びシステム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5283896A (ja) |
| EP (1) | EP0383506B1 (ja) |
| JP (1) | JPH0769842B2 (ja) |
| DE (1) | DE69024072T2 (ja) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5339388A (en) * | 1991-12-31 | 1994-08-16 | International Business Machines Corporation | Cursor lock region |
| FR2692055B1 (fr) * | 1992-06-09 | 1996-10-25 | Bull Sa | Dispositif de conception de reseaux de commande d'informations pour la modelisation de tous processus. |
| JP2768412B2 (ja) * | 1992-07-15 | 1998-06-25 | 財団法人ニューメディア開発協会 | ユ−ザ適応型システムおよびその適応方法 |
| JPH0756754A (ja) * | 1993-08-03 | 1995-03-03 | Internatl Business Mach Corp <Ibm> | マルチメディア・グループ資源割当て装置及び方法 |
| FR2718868B1 (fr) * | 1994-04-18 | 1996-05-31 | Bull Sa | Procédé de détection d'interblocages dans les systèmes multiprocesseurs à mémoire partagée. |
| US5564049A (en) * | 1994-07-29 | 1996-10-08 | Allen-Bradley Company, Inc. | Industrial controller programming method using external connection database |
| US5680530A (en) * | 1994-09-19 | 1997-10-21 | Lucent Technologies Inc. | Graphical environment for interactively specifying a target system |
| US5640557A (en) * | 1994-11-18 | 1997-06-17 | International Business Machines Corporation | Method and system for processing logic blocks in a data processing system |
| US5812824A (en) * | 1996-03-22 | 1998-09-22 | Sun Microsystems, Inc. | Method and system for preventing device access collision in a distributed simulation executing in one or more computers including concurrent simulated one or more devices controlled by concurrent one or more tests |
| FR2752125B1 (fr) * | 1996-08-01 | 1998-09-11 | Bull Sa | Distribution de tickets dans un systeme informatique multinodal |
| JP3052908B2 (ja) | 1997-09-04 | 2000-06-19 | 日本電気株式会社 | トランザクションプログラム並列実行方法およびトランザクションプログラム並列実行方式 |
| JP3415009B2 (ja) * | 1997-11-14 | 2003-06-09 | 沖電気工業株式会社 | プログラム開発装置および記録媒体 |
| US6366946B1 (en) * | 1998-12-16 | 2002-04-02 | Microsoft Corporation | Critical code processing management |
| US6859927B2 (en) * | 1999-12-21 | 2005-02-22 | Lockheed Martin Corporation | Apparatus and method for controlling allocation of resources and task execution |
| US6842899B2 (en) * | 1999-12-21 | 2005-01-11 | Lockheed Martin Corporation | Apparatus and method for resource negotiations among autonomous agents |
| JP2004505333A (ja) | 2000-03-17 | 2004-02-19 | エンペレイティヴ インコーポレイテッド | 通信サービスのプロビジョニング方法及び装置、及びプロビジョニング・モデルを開発するためのオブジェクト・プログラミング言語 |
| DE10028140A1 (de) * | 2000-06-07 | 2001-12-20 | Siemens Ag | Verfahren zur Organisation des Ablaufs elektronisch gesteuerter Schaltvorgänge |
| DE10038439B4 (de) * | 2000-08-07 | 2008-04-24 | Siemens Ag | Vorrichtung, zumindest umfassend ein Computersystem und eine industrielle Steuerung, für das Debuggen von Programmen für industrielle Steuerungen |
| US7302676B2 (en) | 2000-08-07 | 2007-11-27 | Siemens Aktiengesselschaft | Method for debugging flowchart programs for industrial controllers |
| DE10038441B4 (de) * | 2000-08-07 | 2005-10-27 | Siemens Ag | "Flow Chart Programmierung für industrielle Steuerungen, insbesondere Bewegungssteuerungen" |
| US7133842B2 (en) * | 2000-12-29 | 2006-11-07 | International Business Machines Corporation | System, method and program for bidding for best solution process execution in a heterogeneous network |
| US20020087483A1 (en) * | 2000-12-29 | 2002-07-04 | Shlomi Harif | System, method and program for creating and distributing processes in a heterogeneous network |
| US7120699B2 (en) * | 2001-09-20 | 2006-10-10 | Ricoh Company, Ltd. | Document controlled workflow systems and methods |
| US7093253B2 (en) | 2001-11-06 | 2006-08-15 | International Business Machines Corporation | Method, computer program product, and system for a self-throttled computing task |
| US7146360B2 (en) * | 2002-12-18 | 2006-12-05 | International Business Machines Corporation | Method and system for improving response time for database query execution |
| US7065419B2 (en) * | 2004-04-14 | 2006-06-20 | Taiwan Semiconductor Manufacturing Company, Ltd. | Job flow Petri Net and controlling mechanism for parallel processing |
| US7698708B1 (en) * | 2004-07-30 | 2010-04-13 | Symantec Operating Corporation | Method and system for persistent, recoverable user-level locks |
| US8234647B1 (en) * | 2008-01-31 | 2012-07-31 | The Mathworks, Inc. | Checking for mutual exclusiveness of a shared resource |
| US9582768B1 (en) | 2008-01-31 | 2017-02-28 | The Mathworks, Inc. | Determining conditions associated with accessing data stores |
| US8601457B1 (en) * | 2008-01-31 | 2013-12-03 | The Mathworks, Inc. | Checking for access problems with data stores |
| US8280832B1 (en) | 2009-03-04 | 2012-10-02 | The Mathworks, Inc. | Proving latency associated with references to a data store |
| US8769496B2 (en) * | 2010-08-13 | 2014-07-01 | Accenture Global Services Limited | Systems and methods for handling database deadlocks induced by database-centric applications |
| US8762781B2 (en) | 2010-11-16 | 2014-06-24 | International Business Machines Corporation | Method and apparatus useful in manufacturing test case operations |
| US20150039279A1 (en) * | 2013-08-02 | 2015-02-05 | Vitali Volovoi | Systems and methods for modeling a complex system using abridged petri nets |
| CN106569472B (zh) * | 2016-11-14 | 2019-05-07 | 南京理工大学 | 基于bdd的企业车间死锁的快速预防方法 |
| CN111444082B (zh) * | 2019-01-17 | 2022-02-11 | 同济大学 | 基于Petri网的并发错误检测方法及系统 |
| CN113886053B (zh) * | 2021-12-01 | 2022-03-04 | 华控清交信息科技(北京)有限公司 | 一种任务调度方法、装置和用于任务调度的装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4866605A (en) * | 1984-11-05 | 1989-09-12 | Hitachi, Ltd. | System function simulation method and apparatus therefor using Petri net symbols |
| US4922413A (en) * | 1987-03-24 | 1990-05-01 | Center For Innovative Technology | Method for concurrent execution of primitive operations by dynamically assigning operations based upon computational marked graph and availability of data |
| JP2580592B2 (ja) * | 1987-04-17 | 1997-02-12 | 株式会社日立製作所 | データ構造駆動型処理装置とその制御方法 |
-
1989
- 1989-02-13 JP JP1031146A patent/JPH0769842B2/ja not_active Expired - Lifetime
-
1990
- 1990-02-12 EP EP90301431A patent/EP0383506B1/en not_active Expired - Lifetime
- 1990-02-12 US US07/478,818 patent/US5283896A/en not_active Expired - Fee Related
- 1990-02-12 DE DE69024072T patent/DE69024072T2/de not_active Expired - Fee Related
Non-Patent Citations (1)
| Title |
|---|
| 「情報処理」，Ｖｏｌ．２５，Ｎｏ．３，１９８４年３月，（社）情報処理学会，Ｐ．１８８−１９８ |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0383506A2 (en) | 1990-08-22 |
| DE69024072D1 (de) | 1996-01-25 |
| JPH02211546A (ja) | 1990-08-22 |
| EP0383506A3 (en) | 1992-07-01 |
| DE69024072T2 (de) | 1996-06-13 |
| EP0383506B1 (en) | 1995-12-13 |
| US5283896A (en) | 1994-02-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH0769842B2 (ja) | 資源の相互排他制御方法及びシステム | |
| KR101126255B1 (ko) | 신호처리장치 | |
| KR950006616B1 (ko) | 변환된 프로그램 코드에서 소스 명령 분자를 보전하기 위한 시스템 및 방법 | |
| US7916974B2 (en) | Processing device, processing method and computer readable medium | |
| JP2710896B2 (ja) | 通信オートマトンセットの開発を支援する方法 | |
| US20080005255A1 (en) | Extensible robotic framework and robot modeling | |
| CN110663006B (zh) | 对可编程逻辑控制器执行故障转移并控制物理系统的方法 | |
| CN110262791B (zh) | 一种可视化编程方法、装置及运行器、可读存储介质 | |
| US9323874B2 (en) | Simulation method using memory frame proxy architecture for synchronization and check handling | |
| JP2009282755A (ja) | シミュレーション装置 | |
| Windsor et al. | RoboCert: property specification in robotics | |
| JP2006343818A (ja) | 教示装置用プログラムのデバッグ方法 | |
| Ebert et al. | DiNeROS: A Model-Driven Framework for Verifiable ROS Applications with Petri Nets | |
| JP2016146148A (ja) | 設計支援装置、および設計支援方法 | |
| JPH1049206A (ja) | シーケンスプログラム作成装置 | |
| Noble et al. | Lazy functional components for graphical user interfaces | |
| US20240231330A1 (en) | Method and system for controlling a machine by executing program steps which verifiably execute predefined control tasks | |
| Zhang | Aspect-oriented modeling of mutual exclusion in UML state machines | |
| Graczyk et al. | A Framework for Verifying the Collision Freeness of Collaborative Robots (Work in Progress) | |
| Thomas | A model for process representation and synthesis | |
| Richard et al. | An attempt to confront asynchronous reality to synchronous modelization in the Esterel language | |
| US8990802B1 (en) | Pinball virtual machine (PVM) implementing computing process within a structural space using PVM atoms and PVM atomic threads | |
| D'Angelo | Tutorial on petri nets | |
| JPS6382212A (ja) | 物流システムの制御方法 | |
| JPH05282262A (ja) | 交信オートマトンセットのための構造 |