Method and System for Controlling Mutually Exclusive Resources Using a Modified Petri Net Process Control Graph

1. Field of the Invention

This invention relates to a method and a system for controlling mutually exclusive resources that are available sequentially in an event driven process. The sequentially available resources are controlled by a computer, a programmable logic controller or the like.

2. Description of the Prior Art

Important concepts in the recent computer technology art are multitasking, multiprocessing and distributed processing. To implement these techniques, it is necessary to share a resource between several tasks or processes during parallel execution of a plurality of tasks or processes. Such a resource is called a shared resource, for example, various peripheral devices, disks, memories, communication lines, programs, and data. A shared resource that can be appropriated by one task or process at a time is called a critical resource.

The problem of controlling mutually exclusive resources in an event driven process arises when event driven processes are executed in parallel and compete for the shared resource. The mutually exclusive resource control mechanism assures that the shared resource will be held by at most one process. An area which holds a shared resource in the processes executed in parallel is called a critical section. The problem of sharing a resource when a plurality of tasks are executed in parallel is presented as a problem of interprocess communication and synchronization. To solve it conventionally, various techniques have been proposed, and analyzed by system models. The synchronization problem includes the mutual exclusion problem, the producer consumer problem, the dining philosopher problem, and the reader/writer problem.

At present, there is no way to solve the problem of automatically controlling access to a mutually exclusive resource among a plurality of competing processes. It is a burden for the programmer or the operator. Thus, whether a programmer writes a program executing in parallel, or an operator executes a program under such an environment, attention must always be paid to resource assignment. In implementing a parallel execution system, a programmer uses semaphores to control access.

An example of programming using semaphores will be explained as follows. It is assumed that there are three flows of event driven processes G.sub.1, G.sub.2 and G.sub.3 as shown schematically in FIG. 2. In the first flow of process G.sub.1, tasks p.sub.1 and p.sub.2 are processed sequentially. After the task p.sub.1 has been executed while using shared resources A and C, the task p.sub.2 is executed while using shared resources B and C.

In the second flow of process G.sub.2, a task P.sub.3 is executed. The task P.sub.3 is executed while using the shared resources A, B and C. In the third flow of process G.sub.3, tasks P.sub.4 and P.sub.5 are executed in parallel. The task P.sub.4 is executed while using the shared resources A and C, and the task P.sub.5 is simultaneously executed while using the shared resources B and C. The start or end points of the tasks are indicated by time marks t.sub.1 --t.sub.7. It is assumed that, among the resources appearing in FIG. 2, the critical resources are A and B, and that the critical resource A is a robot 2, while the critical resource B is a robot 1.

At present, in most cases, software programming is performed for each critical resource, i.e., a controller for production apparatus in a manufacturing process, or a computer in a network system. This requires a program for each critical resource and a program for controlling them. An example of this is shown in FIGS. 3A-3C. FIG. 3A is a program for controlling the entire system; FIG. 3B is a program for controlling the robot 1; FIG. 3C is a program for controlling the robot 2.

The syntax for describing the parallel execution is as follows: ##STR1## wherein P1 and P2 are tasks executed in parallel.

In addition, syntax for describing a critical section is as follows: ##STR2## wherein R is a unique name for a critical resource to be mutually excluded, and S is a critical section to be mutually excluded. In this case, R is a semaphore.

In FIG. 3A, R(p) is a program for a robot as indicated in FIGS. 3B and 3C, respectively. When a parameter p is passed to R, the program for R executes only the task for p.

The syntax for describing the critical section and its mechanism, as well as the syntax for describing the parallel execution and its mechanism are not supplied to the programmer generally, so that it becomes the responsibility of the programmer to write the description of the critical section, to produce its mechanism, and to debug the process for mutually exclusive control.

One technique that is widely used for modeling of a system is called a Petri-Net. Features of the Petri-Net are parallelism or simultaneousness and nonsynchronization. Its execution may be considered to be a series of discrete events with the timing when an event occurs being indefinite. Attempts have been made to utilize these features and the execution form for event driven control. The Petri-Net is useful in the simulation of a parallel execution system such as a computer model or a manufacturing process because of its mathematical analysis characteristics and modeling capabilities.

The Petri-Net consists of four components: a place, a transition, an arc, and a token. The place indicates an event, the transition indicates a condition, the arc indicates a path, and the token indicates a state. The token moves in the arc between the places according to the condition of the transition, and causes an event corresponding to the place.

FIG. 4 shows examples illustrating the execution of the Petri Net. In this example, the Petri Net is described by using a transition T={t.sub.a, t.sub.b, t.sub.c }, a place P={P.sub.x, P.sub.y, P.sub.z }, and a token. First, if there is no token in P.sub.x, t.sub.a generates a token and places it in P.sub.x (FIG. 4A). If P.sub.x has a token, and P.sub.y and P.sub.z do not have a token, t.sub.b transfers the token to P.sub.y and P.sub.z (FIG. 4B). If P.sub.y and P.sub.z have a token, t.sub.c takes out and erases the token. More details on the Petri Net can be found in "Petri Net Theory and the Modeling of Systems" by J. L. Peterson, Prentice-Hall Inc., 1981.

In a conventional control system using Petri Nets, a programmer describes a flow of processes as shown in FIG. 2 or FIG. 4 by using a graphics editor and then converting the description into code to create a program for controlling the entire system so that, when starting a task or receiving a termination signal, the token is automatically transferred according to these signals based on the program in execution. Description of this system can be found in a paper authored by K. Hasegawa and K. Takahashi, "MFG (Mark Flow Graph)-Based Programmable Controller and its Application to FMS," published in the Proceedings of the International Conference on System Engineering, pp. 306-311, 1984.

However, the conventional control systems do not take the mutually exclusive control problem into consideration. Modeling of the mutually exclusive control problem is performed by creating a place corresponding to an empty state of a resource (empty place) and by connecting it to a place of a task using that resource to establish a critical section. In this case, it utilizes storability which is an important characteristic of the Petri-Net. The empty place contains a token as an initial marking, and always contains a token when a resource is not used. When a process is in a critical section and is using a resource, the empty place does not contain a token. If another process attempts to enter the critical section to use the same resource, it cannot be executed because the empty place does not contain a token and a firing condition is not satisfied. The execution of this other process is forced to wait until the process using the resource ends, releases the resource, and returns the token to the empty place.

FIG. 5 shows an example of this modeling. Place m indicates authorization to enter a critical section. When a process wants to enter the critical section, it supplies a token to p.sub.1 or p.sub.2 to indicate its readiness to enter the critical section, and waits for a signal allowing entrance into the critical section or the token of m to access the critical section. If both processes want to enter the critical section simultaneously, transitions t.sub.1 and t.sub.2 cause contention, and only one process can be fired. Firing of t.sub.1 disables that of t.sub.2, and the process 2 is delayed until the process 1 completes the critical section and returns the token to m.

A control system for providing mutually exclusive control cannot be implemented easily if a graph having empty places for critical resources is created, and converted into codes so as to create a control program for the entire system with the token being automatically transferred. The reasons for this are as follows:

1. The empty places must be incorporated in the Petri-Net. If a programmer incorporates the empty places in a suitable location in the Petri Net while paying attention to critical resources, his effort will be equivalent to programming using semaphores. The creation of the Petri Net becomes very difficult for even a slightly complicated case as illustrated in FIG. 6 as compared with a simple case as illustrated in FIG. 5.

2. In execution, a user must first distinguish the empty places (resource places) from task places, and then place initial tokens in all empty places. This imposes a significant burden on the user.

3. A deadlock may be caused from the representation of the Petri Net itself.

This can be further explained by taking the situation in FIG. 6 as an example. It is assumed that the current state is as shown in FIG. 6A. That is, the tasks P.sub.1 and P.sub.4 are being executed, and the resources P.sub.x and P.sub.y are empty. The resource P.sub.x is used by the tasks P.sub.2, P.sub.3 and P.sub.6. The resource P.sub.y is used by the tasks P.sub.3, P.sub.5 and P.sub.6.

If the state is as shown in FIG. 6A, then it is clear that the control system can start the execution of the tasks P.sub.2 and P.sub.5. Thus, t.sub.1 and t.sub.4 transfer the tokens to P.sub.2 and P.sub.5, respectively. Here, it should be noted that, because the representation as shown in FIG. 5 or FIG. 6 connects each end of the critical section to the empty place of the resource, the token is never transferred to the empty place of P.sub.x until the execution of the task P.sub.3 following the task P.sub.2 is completed, and that, similarly, the token is never transferred to the empty place of P.sub.y until the execution of the task P.sub.6 following the task P.sub.5 is completed. FIG. 6B shows the positions of the tokens after starting the execution of the tasks P.sub.2 and P.sub.5. Now, the control system cannot start the execution of the task P.sub.3 even if the execution of the task P.sub.2 is completed because there is no token in the empty place of P.sub.y. A token is never returned to the empty place of P.sub.x unless the execution of the task P.sub.3 is started. Thus, the execution of the task P.sub.6 is not started either. In this way, the transitions t.sub.2 and t.sub.5 cannot fire and thus cause a deadlock. In the Petri Net, whenever transitions cannot fire, a deadlock results.

In a mathematical representation, G=(P, T, O) where G is the Petri Net structure, P={P.sub.1, P.sub.2, . . . P.sub.M } is a set of places with M>0, and T={T.sub.1, T.sub.2, . . . T.sub.L } is a set of transitions with L>1. The set of places and the set of transitions are disjoint, and P.andgate.T=.PHI.. I: P->T is an input function from a place to a transition. O: T->P is an output function from a transition to a place. A Petri Net structure to which is added a marking .mu. for assignment of a token to a place is called a marked Petri-Net. The token exists only in the place, and firing of the transition controls execution. Firing of the transition transfers a token from an input place to an output place. The Petri Net structure is dual in the graph theory. The concept of the dual of a graph is not utilized in the marked Petri-Net because the dual of a graph is difficult to define.

It is therefore an object of this invention to provide a method and system for controlling mutually exclusive resources.

The invention enables a user to perform mutually exclusive control of sequentially available resources together with event driven control by describing the event driven control in terms of a process flow graph and a task program. The invention automatically performs programming and execution for the management of resources in the process removing the burden of preventing errors in a resource management program from the programmer, and removing the burden of executing the program from the operator.

In addition, the invention provides the advantage that a deadlock which may occur in a conventional Petri-Net representation is avoided by assigning a token to a condition gate described herein.

According to the invention, the method involves first generating a graph in a storage device, the graph containing nodes to which are mapped the tasks included in a flow of processes and the critical resources which may be appropriated by at least one of the tasks. The nodes of tasks executed sequentially are arranged sequentially; the nodes of tasks executed in parallel are being arranged in parallel with each other, and each node of a critical resource is arranged in parallel with every node which may appropriate it.

Each time a signal to begin execution of a task is transmitted, a token is generated in the task node and the critical resource node in parallel with the task node. Referring to said graph, when the completion of the current task in the process flow is detected, a signal to begin execution of the immediately succeeding task is delayed in its transmission until a token is assigned to any one of the immediately succeeding task nodes and the critical resource nodes arranged in parallel with it.

It is preferable in the process flow graph to provide gate nodes in the graph at each location where nodes of the tasks that are sequentially executed are connected;

Every time the completion of the execution of a task is detected, the tokens are removed from the node of the task and each critical resource that is arranged in parallel with the task node.

After detecting the completion of execution for tasks corresponding to every task node arranged immediately before a gate node, a token is generated in the gate node, and then, while a token is being assigned to any one of the nodes for a succeeding task arranged immediately after the gate node or nodes of any critical resource arranged in parallel with it, the transmission of a signal to begin the execution of the succeeding task is delayed.

Finally, the token is removed from the gate node after the transmission of the signal to begin the execution of the succeeding task.

The preferred system for controlling mutually exclusive resources according to the invention includes a storage device holding a graph having nodes representing the tasks contained in a flow of processes and nodes corresponding to each critical resource capable of being exclusively appropriated by any of the tasks. In the graph, nodes of tasks that are sequentially executed are arranged in series, the nodes of the tasks that are executed in parallel are arranged in parallel, a gate node is arranged at each location connecting the nodes of the tasks with each other, and a node for each critical resource is arranged in parallel with the nodes of all tasks capable of exclusively appropriating the critical resource.

The preferred system includes means for generating the tokens in the node of the current task in the graph and in the node of each critical resource that is arranged in parallel with the current task node every time a task beginning signal is transmitted. The system includes means for removing the tokens assigned to the node of the current task and to the node of each critical resource arranged in parallel with the current task node every time the end of the execution of the task is detected. The system includes means for generating a token in the gate node when the completion of execution for tasks corresponding to every task node arranged immediately before a gate node is detected, and means for delaying the transmission of a signal to begin the execution of the succeeding task until a token exists in a node for a succeeding task arranged immediately after the gate node or a node of a critical resource arranged in parallel with the task. Finally, the system includes means for removing the token from the gate node after the signal to begin the succeeding task is transmitted.

FIG. 1 is a system block diagram illustrating the preferred embodiment of the invention.

FIG. 2 is a schematic diagram illustrating the flows of three event driven processes.

FIGS. 3A, 3B, 3B.sub.1, 3C, 3C.sub.1 contain pseudocode representations of a prior art method for controlling mutually exclusive resources.

FIGS. 4A, 4B are diagrams illustrating examples of the execution of a Petri net.

FIG. 5 is a diagram illustrating a model for mutually exclusive control employing the Petri net.

FIGS. 6A, 6B are diagrams illustrating that a deadlock can occur if a conventional Petri net is executed to perform the mutually exclusive control of resources.

FIG. 7 is a diagram illustrating the process flow graph of this invention.

FIG. 8 is a diagram illustrating both a process flow graph and a task program.

FIG. 9 is a diagram illustrating the resource management graph of this invention.

FIG. 10 is a flowchart illustrating the processing procedures for generating a resource management graph.

FIG. 11 is a flowchart illustrating the processing procedures for generating a process resource graph.

FIG. 12 is a diagram illustrating the process resource graph of this invention.

FIG. 13 is a flowchart illustrating the processing procedures for generating a union graph from a program flow graph and a resource management graph.

FIG. 14 is a diagram illustrating a process flow that causes a deadlock.

FIG. 15 is a diagram showing a union graph representation of the contents of FIG. 14 to detect deadlock.

FIGS. 16A, 16B, 16C, 16D, 16E, 16F are diagrams showing the execution of the process resource graph of FIG. 12.

FIG. 17 is a diagram illustrating a hardware implementation of a mutually exclusive control system.

FIG. 18 is a diagram showing the process resource graph corresponding to the conventional Petri-net diagram of FIG. 6.

FIGS. 19A, 19B, 19C, 19D are diagrams showing the execution of the process resource graph of FIG. 18.

Referring now to the drawings, and more particularly to FIG. 1, there is shown a system configuration of the preferred embodiment of the invention. Steps S1-S8 in the figure are described in order.

(a) Creation of a process flow graph (step S1)

A user creates a process flow graph representing an event driven process with a task as a unit of process. The created process flow graph is equivalent to a restricted Petri Net graph with a safe and active nature (without multibranch or self loop). Refer to the Appendix for the mathematical representation of the process flow graph.

As methods for creating the process flow graph, there is a first method in which the process flow graph is described with graphical symbols by using a graphics editor, and then converted to a text representation, and a second method in which the process flow graph is directly described with character codes by using a text editor. The process flow graph created in this manner is also called a process flow program.

In the preferred embodiment, the user describes the process flow graph interactively with a graphics editor. FIG. 7 shows a graphical representation of the process flow program. A unit of control on the process flow graph is called a task, which corresponds to a program file (see FIG. 8).

An example of execution subsequent to the definition of the process flow graph is explained by referring to FIG. 7. A token is generated in a condition gate C.sub.1 or C.sub.4. In the case where the token is generated in the condition gate C.sub.1, the token moves to task places T.sub.1 and T.sub.2 where tasks T.sub.1 and T.sub.2 are executed by using resources R.sub.A and R.sub.B. When both tasks T.sub.1 and T.sub.2 have been completed, the token moves to task place T.sub.3 according to the condition of the condition gate C.sub.2. The task T.sub.3 is executed by using the resource R.sub.B. Then, when the task T.sub.3 is completed, the token moves from the place T.sub.3 to the condition gate C.sub.3, and is removed. In the case where the token is generated in the condition gate C.sub.4, the token moves to task place T.sub.4 where the task T.sub.4 is executed by using the resource R.sub.A. When the task T.sub.4 is completed, the token moves to a task place T.sub.5 according to the condition of the condition gate C.sub.5. The task T.sub.5 is executed by using the resources R.sub.A and R.sub.B. Then, when the task T.sub.5 is completed, the token moves from the place T.sub.5 to the condition gate C.sub.6, and is removed. This example of execution does not contain the mutually exclusive resource control function. Here, the condition gate corresponds to the transition in the Petri-Net, but definitely differs from the transition in that the condition gate allows a token to be assigned to itself.

A text representation of the process flow program is created in the form of intermediate codes of the process flow graph. It is equivalent to the graphical representation, and each representation can be converted to the other representation. In the following description, the text representation of the graph is also referred to as the intermediate code.

The format for the intermediate code of the process flow graph is as follows:

Condition gate:

Input place (, input place . . . )/

Output place (, output place . . . )

The intermediate code for the embodiment shown in FIG. 7 is as follows.

C.sub.1 : /T.sub.1, T.sub.2

C.sub.2 : T.sub.1, T.sub.2 /T.sub.3

C.sub.3 : T.sub.3 /

C.sub.4 : /T.sub.4

C.sub.5 : T.sub.4 /T.sub.5

C.sub.6 : T.sub.5 /

(b) Generation of resource management graph (steps S2 and S3)

A resource management graph is generated from the process flow graph and the task program. Resource names of critical resources necessary for the tasks are extracted from the task programs, thereby generating a list of them. As shown in FIG. 8, when the task program is described in a text, the critical resources described therein are described by logical symbols of the resources, logical numbers of the resources, or logical names of the resources. A resource management graph is generated from the process flow graph and the list which extracted the resource names. FIG. 9 shows a resource management graph generated from the process flow graph of FIG. 7 and the resource name list of the critical resources necessary for the tasks.

It should be noted that, as shown in FIG. 8, the user is never required to pay attention to resource management by using semaphores or the like, in creating a program of a process flow graph describing connections between tasks, or a task program describing an individual task.

In the embodiment shown in FIG. 8, the program is described with an object oriented language by using a text editor in the following format.

A list is created that extracts the names of the critical resources used by the task from the logical names of critical resources in the task programs. A resource management graph is generated from the list and the process flow graph.

If the format for the intermediate code of the resource management graph is made the same as that for the intermediate code of the process flow graph, the intermediate code for the resource management graph of FIG. 9 is as follows:

C.sub.1 : /R.sub.A, R.sub.B

C.sub.2 : R.sub.A, R.sub.B /R.sub.B

C.sub.3 : R.sub.B /

C.sub.4 : /R.sub.A

C.sub.5 : R.sub.A /R.sub.A, R.sub.B

C.sub.6 : R.sub.A, R.sub.B /

FIG. 10 is a flowchart illustrating an algorithm for generating the intermediate code from the process flow graph and the resource name list. If all resources are critical, the resource name list may be created by automatically extracting all resource names contained in the task program. The user may also create the resource name list by specifying the critical resource names.

(c) Generation of process resource graph (steps S4, S5, and S6)

A flowchart of the process for generating the process resource graph is shown in FIG. 11. The process flow graph and the resource management graph are loaded in steps 111 and 112, from which a graph of their union is generated in step 113.

FIG. 12 shows a union graph generated from the process resource graph of FIG. 7 and the resource management graph of FIG. 9.

If the format for the intermediate code of the union graph is made the same as that for the intermediate codes of the process flow graph, the representation of the union graph of FIG. 12 is as follows:

C.sub.1 : /T.sub.1, T.sub.2, R.sub.A, R.sub.B

C.sub.2 : T.sub.1, T.sub.2, R.sub.A, R.sub.B /T.sub.3, R.sub.B

C.sub.3 : T.sub.3, R.sub.B /

C.sub.4 : /T.sub.4, R.sub.A

C.sub.5 : T.sub.4, R.sub.A /T.sub.5, R.sub.A, R.sub.B

C.sub.6 : T.sub.5, R.sub.A, R.sub.B /

FIG. 13 is a flowchart illustrating an algorithm for generating the intermediate code from the process flow graph and the resource management graph, i.e., it shows step 113 of FIG. 11 in detail.

If the union graph thus generated is unconditionally regarded as a process resource graph as it is, a deadlock may be caused.

FIG. 14 shows a case where a deadlock is caused. In the initial state, a token is in the condition gate C.sub.1. The deadlock is caused because the task T.sub.1 should be executed while using the resource R.sub.A, and the task T.sub.2 should be executed while using the resources R.sub.A and R.sub.B. If the common connection graph causes a deadlock, it is reported to the user for resolution.

The preferred embodiment uses a graph that avoids the deadlock shown on the common connection graph based on the process resource graph. When execution is performed accordingly, it is possible to simultaneously perform the control of an event driven process and mutually exclusive resource control.

Referring to FIG. 11, the deadlock that may be caused in the common connection graph is displayed in step 115 after checking for a deadlock at the time when the common connection graph is generated from the process flow graph and the resource management graph indicated by step 114.

FIG. 15 is a representation of the deadlock case of FIG. 14 in the form of a union graph. As shown in FIG. 15, a deadlock occurs in the case where a condition gate and a resource place are connected in duplicate. It is sufficient to check whether or not the generated union graph has a resource connected to one condition gate in duplicate, and to point it out to the user if there is one. If no deadlock occurs, the union graph is used as the process resource graph as is indicated by step 116 in FIG. 11.

The deadlock referred to herein is not caused by the system that performs control according to the graphic representation described herein. As described later, occurrence of the deadlock as in FIG. 6 is avoided according to the invention. The deadlock displayed in step 115 of FIG. 11 is caused from the program structure itself, and is the responsibility of the user to avoid (step 117).

The process resource graph is a bipartite directed graph, nodes of which are event places and condition gates, and arcs of which are input functions and output functions. Marking means to assign tokens to the task places, the resource places, or the condition gates of the process resource graph. In addition, at most one token can exist in one task place, one resource place, or one condition place. In a conventional Petri-Net, a token is not assigned to a condition gate, while a token is assigned in the process resource graph. Refer to the Appendix for the mathematical representation of the process resource graph.

In the union graph or the process resource graph shown in FIG. 12, every task node is arranged in parallel with a resource node. However, in some cases tasks will never access a critical resource. In this situation, no resource node is arranged in parallel with such a task node (see FIG. 18).

(d) Execution of process resource graph (steps S7 and S8)

The process resource graph is converted into executable code for a controller that performs event driven control together with the mutually exclusive control of sequentially available resources, and is then loaded in the random access memory or ROM of the controller for execution (such as a computer or a programmable logic controller). When the process resource graph is executed, the mutually exclusive resource control and the event driven process control are simultaneously performed. For example, a node (an event place or a condition gate) of a process resource graph is implemented in memory as a data structure, and the connection between elements is represented by pointers. Information relating to the presence of a token is stored in the data structure. The method for generating or erasing a token is implemented similarly to the system described in the paper authored by Hasegawa and Takahashi and is incorporated by reference herein.

The conditions for transferring the token presented by the invention are strictly represented by equations (1) and (2) in the Appendix, which can be explained as follows:

(I) As soon as the beginning of execution of a task is directed, a token is assigned to the place (node) of the task and the resource place in parallel with the task place. That is, according to the invention, and different from the conventional Petri-Net representation, the token placed in the resource place indicates that the resource is appropriated by the task being executed.

(II) If there are tasks controlled in parallel, the tokens are transferred to a succeeding condition gate at the time when execution of all the tasks are completed.

(III) Until a token is assigned to at least one of the task places immediately after the condition gate and the resource places in parallel with the task places, the signal to begin execution of the succeeding task is delayed by keeping the token in the condition gate.

FIG. 16 shows an example of execution control following the definition of the process resource graph of FIG. 12. This figure illustrates the case where a token is generated first either in the condition gate C.sub.1 or in the condition gate C.sub.4. This discussion treats the case where the token is generated first in the condition gate C.sub.l. As shown in FIG. 16A, the token is generated in the condition gate C.sub.1. As illustrated, even if it is necessary to execute the tasks T.sub.1 and T.sub.2, tokens are not immediately placed in the places T.sub.1 and T.sub.2. First, the token is assigned to the condition gate C.sub.1. The token moves from the condition gate C.sub.1 to the task places T.sub.1 and T.sub.2, and the resource places R.sub.A and R.sub.B according to the transfer condition equation (1) in the Appendix (FIG. 16B). At this moment, even if a token is assigned to another condition gate, the transfer condition equation (1) is not satisfied because a token is assigned to the resource places R.sub.A and R.sub.B. Therefore, the token does not move, and a new task other than T.sub.1 and T.sub.2 is not executed. When both tasks T.sub.1 and T.sub.2 are completed, the token moves from the task places T.sub.1 and T.sub.2 and the resource places R.sub.A and R.sub.B to the condition gate C.sub.2 according to the transfer condition equation (2) in the Appendix (FIG. 16C). Next, the token moves from the condition gate C.sub.2 to the task place T.sub.3 and the resource place R.sub.B (FIG. 16D). At this moment, it is assumed that a token is generated in the condition gate C.sub.4. The execution of the task T.sub.4 can now be started. That is, because there is no token in the resource place R.sub.A, the transfer condition equation (1) is satisfied so that the token is transferred to the task place T.sub.4 and the resource place R.sub.A (FIG. 16E). Therefore, the execution of the task T.sub.3 using the resource R.sub.B and the execution of the task T.sub.4 using the resource R.sub.A are performed independently. When T.sub.4 is completed, the token moves from the task place T.sub.4 and the resource place R.sub.A to the condition gate C.sub.5 (FIG. 16F). Even if a token is assigned to the condition gate C.sub.5, the token is not transferred from the condition gate C.sub.5 to the task place T.sub.5 and the resource places R.sub.A and R.sub.B, because another token already is assigned to the resource place R.sub.B and the transfer condition equation (1) is not satisfied. That is, the task T.sub.5 is not executed. When the task T.sub.3 is completed, the token moves from the task place T.sub.3 and the resource place R.sub.B to the condition gate C.sub.3 according to the transfer condition equation (2), and is removed. Therefore, the task T.sub.5 becomes executable.

As seen from the example of FIG. 12, the process resource graph becomes a graph having self loops with respect to the resource places R.sub.A and R.sub.B. When it is regarded as a restricted Petri-Net with a safe and active nature, if tasks attempt to sequentially and immediately use the same resource, a deadlock occurs. For example, in FIG. 12, if, the task T.sub.5 attempts to perform execution using the resources R.sub.A and R.sub.B after the task T.sub.4 completes execution using the resource R.sub.A, a graph of a self loop with respect to the resource R.sub.A is constituted, and a deadlock is caused because the transfer condition equation (O), which is described later, is never satisfied.

This will be further described. First, it should be noted that the process resource graph representation in FIG. 12 itself is novel. (Differences from a conventional Petri-Net will be explained in more detail by comparing FIGS. 6 and 18 later). Next, it is assumed that a token is placed in a place of a held resource, but not placed in a condition gate. In this example, a token is placed in the places T.sub.4 and R.sub.A during execution of the task T.sub.4. Thus, even if the control system attempts to begin the execution of the task T.sub.5, that is, even if it attempts to transfer a token from the place T.sub.4 to the place T.sub.5 and the places R.sub.A and R.sub.B, it is impossible to transfer the token to the place T.sub.5 because a token is already assigned to the place R.sub.A. Then, as long as the token cannot move to the place T.sub.5, the token in the place R.sub.A cannot be removed.

If a token is caused to exist in a condition gate as defined for the process resource graph, deadlock as in the restricted Petri-Net never occurs. That is, in the above example, at the time when the execution of the task T.sub.4 is completed, a state where no token is assigned to the place R.sub.A results from removing the token from places T.sub.4 and R.sub.A, and by generating a token in the condition gate C.sub.5, so that the token can be transferred from the condition gate C.sub.5 to the places T.sub.5, R.sub.A, and R.sub.B. That is, the execution of the task T.sub.5 can be started. The significance of assigning a token to a condition gate lies in this point.

The executable codes of the process resource graph are loaded in the memory or ROM of the controller to be executed. Here, sequentially available resources to be controlled are ones that are controlled by a computer or a programmable logic controller (PLC). These resources include not only those actually contained in the controller, but also those that can be controlled through communications or the like. The invention performs mutually exclusive resource control together with event driven process control for the sequentially available resources based on the executable code of the process resource graph. FIG. 17 shows an example of the hardware configuration of a system that performs such control by loading the executable codes of the process resource graph. In this example, the production apparatus 1, 2, 3, . . . are the critical resources. A task using such apparatus is described in a task program as shown in FIG. 8. A signal directing the beginning of the execution of the program and an end signal notifying the completion of execution of the program are transferred between the PLC and the production apparatus through a digital input/output interface or a communications interface. The completion of execution of a task is detected by sending a signal from the production apparatus to the PLC. Otherwise, the PLC may monitor a state of the production apparatus to detect change of the state to the completion state.

In addition, a task program may be stored in the production apparatus, or may be stored in the memory of the PLC for sequential transfer of instructions from the PLC to the production apparatus.

Finally, as a summary, the process resource graph according to the invention that corresponds to the Petri Net representation of the flow of processes shown in FIG. 6 is shown in FIG. 18, and an example of its execution is shown in FIGS. 19A through 19D.

The graph of FIG. 18 differs from that of FIG. 6 significantly in the following points. Even when two consecutive tasks (for example, P.sub.2 and P.sub.3) use a resource (in this case, P.sub.x), the resource place is connected to each of them in parallel. Relations between the input and the output are reversed. For example, in FIG. 6, the place P.sub.x is connected to the input of the transition t.sub.1, while, in FIG. 18, it is connected to the output of the condition gate C.sub.1.

Now, an example of execution is discussed wherein a token is transferred according to the invention. First, it is assumed that tokens are generated in the condition gates C.sub.1 and C.sub.4 (FIG. 19A). If there is no token in either of the resource places P.sub.x and P.sub.y, the token can be transferred from the condition gate C.sub.1 to the places P.sub.2 and P.sub.x, and from the condition gate C.sub.4 to the places P.sub.5 and P.sub.y (FIG. 19B). That is, the execution of the tasks P.sub.2 and P.sub.5 is started. Then, it is assumed that the execution of the task P.sub.2 is completed. At this time, the control system erases the tokens in the places P.sub.2 and P.sub.x, and generates a token in the condition gate C.sub.2 (FIG. 19C). At this moment, because a token still is assigned to the place P.sub.y, it is impossible to transfer the token to the place P.sub.3. Thus, in the process A, the token remains in the condition gate C.sub.2, and waits for release of the resource P.sub.y. Then, when the control system receives a signal indicating the end of the task P.sub.5, it removes the token from places P.sub.5 and P.sub.y, and generates a token in the condition gate C.sub.5 (FIG. 19D). The control system may transfer the token to the places P.sub.3, and P.sub.x and P.sub.y, or may transfer the token to the places P.sub.6 and P.sub.x. That is, it can instruct the beginning of the execution of either task P.sub.3 or P.sub.6. The deadlock described in FIG. 6 never arises.

The invention has been explained by referring to the preferred embodiment. Other modifications are possible that are within the spirit and scope of this invention. For example, although, in the above embodiment, the process flow graph and the resource management graph are generated in a form of intermediate code, and the process resource graph is first generated in the form of intermediate code and then converted into executable code, the form of their representation is not restricted to this specific mode. It is sufficient for these graphs to generate in a memory representations that are equivalent to those represented in the drawings.

This appendix provides a mathematical representation of the process flow theory of this invention.

A. The process flow graph G.sub.PF is defined using graph theory as follows:

wherein:

T={T.sub.1, T.sub.2, . . . , T.sub.M }, M>0. Set of task places;

C={C.sub.1, C.sub.2, . . . , C.sub.L }, L>1. Set of condition gates;

T.andgate.C=.PHI.. The set of the task places and the set of the condition gates are disjoint.

I.sub.T : T->C. Input function from a task place to a condition gate;

O.sub.T : C->T. Output function from a condition gate to a task place;

.mu.: T->{0, 1}. Marking function of a task place.

A transfer condition equation of a token from a task place T.sub.i to T.sub.o in respect to an arbitrary condition gate C.sub.K at an arbitrary time t is: ##EQU1## wherein m1>0, m2>0. A new marking at time t+1 is: in the task place T.sub.1 ,

in the task place T.sub.o,

A token is generated in a case where there is no input function I.sub.T in the condition gate C.sub.k, and the right hand terms of the transfer condition equation become: ##EQU2##

A token disappears in a case where there is no output function O.sub.T in the condition gate C.sub.K, and the right hand terms of the transfer condition equation become: ##EQU3##

B. The process resource graph G.sub.PR is defined using

graph theory as follows:

wherein:

T={T.sub.1, T.sub.2, . . . , T.sub.M }, M>0. Set of task places;

R={R.sub.1, R.sub.2, . . . , R.sub.N }, N 0. Set of resource places;

C={C.sub.1, C.sub.2, . . . , C.sub.L }, L>1. Set of condition gates;

T.andgate.R.andgate.C=.PHI.. The set of task places, the set of resource places and the set of the condition gates are disjoint;

I.sub.T : T->C. Input function from a task place to a condition gate;

I.sub.R : R->C. Input function from a resource place to a condition gate;

I.sub.T .andgate.I.sub.R =.PHI.. The input function I.sub.T and the input function I.sub.R are disjoint;

O.sub.T : C->T. Output function from a condition gate to a task place;

O.sub.R : C->R. Output function from a condition gate to a resource place;

O.sub.T .andgate.O.sub.R =.PHI.. The output function O.sub.T and the output function O.sub.R are disjoint;

.mu..sub.T : T->{0, 1}. Marking function of the task place;

.mu..sub.R : R->{0, 1}. Marking function of the resource place;

.mu..sub.C : C->{0, 1}. Marking function of the condition gate;

.mu..sub.T .andgate..mu..sub.R .andgate..mu..sub.C =.PHI.. The marking function .mu..sub.T, the marking function .mu..sub.R, and the marking function .mu..sub.C are disjoint.

A transfer condition equation of a token from an arbitrary condition gate C.sub.K to event places T and R at an arbitrary time t is: ##EQU4## wherein m>0, n>0.

A new marking at time t+1 is: in the condition gate C.sub.K,

in the task place T,

in the resource place R,

A transfer condition equation of a token to an arbitrary condition gate C.sub.K from event places T and R at an arbitrary time t is: ##EQU5## wherein m>0, n>0.

A new marking at time t+1 is: in the condition gate C.sub.K,

in the task place T,

in the resource place R,

A token is generated in a case where there is no input function I.sub.T and I.sub.R in the condition gate C.sub.k, and the right hand terms of the transfer condition equation (2) become: ##EQU6##

A token is removed in a case where there is no output function O.sub.T and O.sub.R in the condition gate C.sub.K, and the right hand terms of the transfer condition equation (1) become: ##EQU7##