- Email: [email protected]
Concurrent modeling and simulation of multi-robot systems
Robotics & Computer-lnteorated Manufacturing, Vol. 8, No. 1, pp. 67-73, 1991 Printed in Great Britain
•
0736-5845/91 $3.00 + 0.00 © 1991 Pergamon Press plc
Paper C O N C U R R E N T M O D E L I N G A N D SIMULATION OF MULTI-ROBOT SYSTEMS D. BEN-ARIEH Department of Industrial Engineering and Management, Ben-Gurion University of the Negev, P.O. Box 653, Beer Sheva, Israel
Multi-robot systems can be viewed as a distributed, asynchronous and concurrem mechanism. The components of such a system communicate with each other and with the external world and perform discrete tasks. Such tasks exhibit nondeterminism, concurrency, mutual exdusivencss, and similar properties. Due to the system complexity, it is desired to model it for purposes of verification, analysis, and simulation. This paper has two objectives: to present the diflkulties in modeling and simulating such distributed, concurrent systems, and to describe a new implementation paradigm towards these objectives using concurrent logic programming. This approach is described and examples given using FCP (Flat Concurrent Prolog) for a robotic manufacturing cell.
1. INTRODUCTION One way to perceive robots is as devices that read sensory data, change their geometry frequently, and alter the surrounding world. The task performed by a robot is the result of input data and planned action. When more than one robot cooperates, the system is more complicated, because the tasks of each robot are also dependent upon the other robots' moves (depending on the mode of cooperation, as discussed, for example, in Ref. 10). Multi-robot systems, therefore, are difficult to program and control. Several approaches have been proposed in order to present, simulate, and control multi-robot systems: Petri net s models excel in describing concurrency, conflict problems, and non-determinism; however, this approach needs extensions in order to model activity durations or complex flow among the system elements. A different approach utilizes predicate logic as the modeling paradigm 16 and Prolog as the modeling tool. 12 Other approaches utilize extensions to the Petri net models9 and formal languages.17 Multi-robot systems can be viewed as distributed and asynchronous mechanisms which perform discrete tasks. The components of such a system communicate with one other and with the external world, and exhibit non-determinism, concurrency, mutual exclusiveness, and similar properties. In order to analyze, simulate and verify a system's operation, one must model material and information flow among the elements of the system, as well as the communication processes.
Example 1 The following example is used to demonstrate the desired properties of a modeling tool. The system described in Fig. 1 consists of two robots that assemble two different parts in an unsynchronized fashion. Robot 1 uses parts A, B, and C, and Robot 2 uses parts C and D for the end products. In addition to the common part C, the two robots share the workspace near the output conveyor. The robots have no special priority; therefore, if both are ready, one is activated nondeterministicaUy. Some desirable properties of modeling tools are: 1. Expressiveness. The descriptive power of the modeling tool should be sufficient to represent the properties of interest in the system.
ROBOT 1 ~ ROBOT 2 OUTPUT CONVEYOR 67
Fig. 1. Multi-robot assembly example.
68
Robotics & Computer-Integrated Manufacturing • Volume 8, Number I, 1991
2.
Uniqueness. Every system should be represented by a single model. More than one model for a given system reflects a non-unique modeling tool. 3. Nonambiguity. An ambiguous modeling tool allows one model to represent more than one system. 4. Conciseness. The modeling tool should represent the system in an efficient, nonredundant model. 5. Ease of analysis. An important objective of modeling is analysis of the models. Therefore the modeling tool should permit analysis of the system's properties. 6. Abstraction. The modeling tool should hide system properties that are extraneous to the representation and analysis. 7. Ease of use. The modeling technique should be convenient and useful to non-specialists. Systems that are distributed, asynchronous, and interrupt-driven, with a discrete state space, such as multi-robot systems, are termed "reactive systems". 4 Modelingsuch systems is inherently difficult, as discussed in Section 2. This paper presents a different modeling approach, aimed at reactive systems in general, and multi-robots specifically. This modeling approach is demonstrated on the robotic assembly cell described in Example 1. The next section describes some difficulties in computerized modeling of concurrent systems of the sort discussed. Section 3 presents the concurrent logic programming paradigm. Section 4 describes the F C P implementation of reactive models. Section 5 presents extensions to the basic modeling approach. Section 6 concludes the article and states further research issues.
2. I M P L E M E N T A T I O N ISSUES O F MULTIROBOT SYSTEMS This section highlights the difficulties in precise system modeling using sequential and concurrent simulation languages. The system properties mentioned here exist in Example 1.
Assumptions This paper treats multi-robot systems as a collection of finite-state machines. Each machine can be in a finite number of states; moving to a new state implies two things: the preconditions of the new state are true, and the post-conditions are fulfilled. This notion is similar to that of condition/event systems. ~3 Naturally the machines can operate concurrently, while machines can affect one another's state and activate one another. Each state machine can be in only one state at any instant. Preconditions are not assumed to be true after a machine has changed states. This assumption is justified ifa task's precondition can include availability of resources that are consumed during the task operation (e.g. parts availability).
Definitions Device: A robot or a mechanical entity that performs discrete tasks and is controlled individually, conforming to "the state machine definition. Task: An individual activity performed by a specific device. Each task has associated preconditions and postconditions. Task T~irepresents task i performed on device j. • To is the set of preconditions that have to be true for task T~j to occur. T~ • is the set of post-conditions that task T~ fulfills. Conflicting tasks: Tasks T/k and Tjl are called conflicting tasks if they both occur and
Nonconflicting tasks: A set of tasks T = (tl, t 2 , . . . , t , } is a nonconflicting set if every ti, t j e T can occur and is not conflicting. Comment All the examples to follow can be represented in terms of Petri nets 11 in which tokens in the input places represent valid preconditions, the transitions that fire represent task execution, and output tokens cause postconditions to be true. Therefore some of the examples are described both in physical terms and in Petri net form. 2.1. Sequential implementation languages A few difficulties can be demonstrated using the following naive algorithm:
Algorithm 1: The naive approach 1. For every device Dj, j = 1. . . . . n, if •T~j is nonempty or true, activate the device. 2. Go to step 1. This algorithm generates a subset of the states in which the system can be. This property appears in Example 1 when all input parts are available. In this case, only Robot 1 is always activated. The sequential nature of the algorithm introduces an execution order of events that is not intended in the system. The example also shows that although the preconditions for robot 2 are true, this robot is never activated, thus introducing an unfair schedule into the model. In order to alleviate the problem, an improved algorithm is presented:
Algorithm 2 1. Scan all the devices and find a set {T} ___D. The set D denotes all the devices, and { T} is the set of all the devices with true preconditions for their tasks. 2. Randomly select t~ e T and perform this task. 3. Go back to step 1. The second algorithm gives an answer to the tasks ordering problem, but is subject to other limitations: 1. The solution is less efficient. While the first algor-
69
Modeling and simulation of multi-robot systems • D. BEN-ARIEH
ithm performs task selection in constant time At = o(1), the second algorithm scans all the devices first, i.e. At = o(n). This means that since task selection in real systems takes constant time, there will be some n for which our model is slower than the real system. 2. This model still selects the tasks consecutively, so concurrent events take on some execution order that is not intended. This creates a complete ordering of task execution which introduces a different meaning to the model. 3. The sequential execution generates states that exist in the model but not in the real system (which leads to nonunique representation). Also, different systems share the same model, due to the limitations of the modeling approach (ambiguous model). The following example is given in terms of a Petri net and describes two cases: Fig. 2(a) shows two independent robots that operate concurrently, and Fig. 2(b) shows two robots that share a common resource in a mutually exclusive manner. In the first case, • T~k c~ • T~ = O, which is not true in the second case. Both cases are modeled by Algorithm 2, demonstrating the ambiguity of this modeling approach. In reactive system models, independent events should be able to occur concurrently. Implementing this property leads to the third algorithm:
Algorithm 3 1. For all the tasks with valid preconditions, choose randomly a non-conflicting group T and execute all t~ ~ T. 2. Go back to step 1. This algorithm executes fhe task selection process as if performed in parallel. This algorithm too has flaws: 1. 2.
Selection time At is still a function of n, probably of a higher order. The model assumes that task selection and execution take the same amount of time in all tasks. This leads to the need to introduce time explicitly into the model.
2.2. Concurrent implementation models In this section some problems in concurrent implementation are presented. Conflict. One of the important tasks in concurrent modeling is the conflict. This problem is demonstrated
robot1 robot2 avaiable avaiable perfor
"ski T
perform
robot1 avaiable
Ttask j 7:/°;
0 0
robot2 avaiable ~ tP:;:o;m
0 "v'lab"O
Fig. 2. Two different systems with a similar model.
part A partB partC partD available available available available pe~f r ~ om ( ~ ~ ~ task A T
T
£orm taskB
Fig. 3. The conflict problem in concurrent implementation.
by the following example, illustrated in Fig. 3. Two robots are attempting an assembly process that uses a common part. If they both start concurrently, only one can finish the operation, while the other is suspended and cannot finish. Global state detection. Sometimes it is desired to detect the presence of a "distributed" precondition that is a combination of several conditions. For example, an assembly operation can be performed only when components are available in all input buffers. If the check is performed sequentially, the response is bounded by the scan time of the algorithm. If we perform the check concurrently, there is an implementation difficulty, since each test can take a different amount of time and the results can arrive at various times. This again implies a scanning mechanism, which violates the concurrency assumption. Moreover, if preconditions are not steady and can change state (e.g. an input part exists, but is immediately taken by another robot), the problem is harder. By the time the model algorithm scans the preconditions list and reaches the state in which they are all true, the early ones might have changed their state. This can cause execution of a task for which the preconditions are no longer valid. Solutions to these modeling difficulties are presented in Section 4. 3. C O N C U R R E N T L O G I C P R O G R A M M I N G : AN OVERVIEW Logic programming languages, based on predicate logic, perform logical inference as a basic computational step. These languages typically are written declaratively. A logic program is composed of a finite set of universally quantified Horn clauses. 6 Concurrent languages, which have recently received much attention, apply four different strategies to exercise parallelism in interpreting the programs, is The most attractive strategy is stream parallelism, which involves cooperation of goals executed in parallel through shared variables. Several parallel logic programming languages based on stream parallelism have been proposed, including Relational Language, 2 Concurrent Prolop. 14 Parlog, 3 Guarded Horn Clauses 19 and OC. 5 The flexibility of the computation imposes a need for synchronization among the active processes. This is performed using data flow constraints, which res-
70
Robotics & Computer-IntegratedManufacturing • Volume8, Number 1, 1991
trict the feasible unification modes, as discussed below. 3.1. Flat Concurrent Prolog (FCP) This section briefly introduces the properties of FCP (Flat Concurrent Prolog) for later discussion of its adequacy for modeling/simulation. A more complete description can be found in Shapiro 14 and Mierowsky, 7 for example. In this section the Edinburgh syntax of Prolog is used, 1 so lists, terms, and goals follow their regular notation. Unification is used according to its standard definition. A parallel logic program is a collection of flat guarded clauses of the form:
H: -- G1, G2... GmIB1, B2,.. Bn.
m, n >_O.
In this case, H as well as each G~and B~ are goals. H is the clause's head, the Gs are its guard, and the Bs its body. The "l" operator is the commit operator that exists if the guard is not empty. Each clause can be read declaratively as: " H is true if the Gs and Bs are true". A flat guarded clause is a clause whose guard predicates are in the set of predefined guard test predicates. Clauses with the same name and number of arguments are grouped into procedures. The guard is a part of the synchronization mechanism, as discussed below. In concurrent logic programs, each goal is viewed as a process, and the program as a whole is viewed as a network of concurrent processes communicating by shared logical variables. The basic computational mechanism in logic programming is process reduction. In this process, a call to goal A' causes the goal A to be reduced to B1 ... Bn. The conditions for reduction are that A' unifies with A, and that G 1 ... Gm are true. Computation proceeds by repeatedly selecting a process and attempting to reduce it using the clauses in the associated procedures. The semantics of such languages allow nondeterministic process and clause selection, which means that these operations can be performed in any order or in parallel• The computational process of F C P can perform termination, iterations, and branching. A unit clause (a clause with empty body) of the form A: - true, specifies that a process whose head unifies with A can terminate. An iterative clause (a clause with a single goal in its body) A: - B, specifies that a process in a state unifiable with A can change its state to B. A general clause A: - BI ... B,, specifies that a process in a state unifiable with A can create n - 1 new concurrent processes B 2...B~, and simultaneously change state to B~. 3.2. Synchronization Synchronization is one of the crucial issues in concurrent logic programming. It is the mechanism that restricts the freedom of clause scheduling and communication among active processes, and synchronizes the computation with external events.
Synchronization can be performed using the unification mechanism. Three approaches exist: Ask unification (also called input unification), Read-Only unification, and Test-and-Set unification, x5 General (standard) unification is termed Tell unification. Ask unification is the simplest, most useful mechanism, and is efficient for process modeling. In this paper only Ask unification and Test-and-Set unification are utilized. Ask unification is used in a reduction step, and allows a term in the calling clause to be instantiated to a less detailed term. If the other term is more detailed (i.e. has a value) the calling one is suspended until it gets a value also, and can be matched. As an example, the reduction of p(X) to the goal p(a) succeeds (matches) when X gets the value "a". The goal p(X) is suspended until X gets this value. On the other hand, p(a) matches p(X) immediately. Using this mechanism, process synchronization can be achieved as shown in the following example: The call is: move(X, Done), take(X, Done). (Two concurrent goals.) The goals are: move(X, Done): - (X, Done) = (part_a, done). take (X, done): - take (X). The reduction of take(X, Done) to take(X, done) take(X) is suspended until the variable " D o n e " is instantiated to "done", by the process move(X, Done). This causes the process "take" to start only after the process "move" is finished. By sharing the variables in the call, processes "move" and "take" have the same variables; this causes the values to transfer as needed to activate the process "take". The F C P language employs atomic unification, which is a vital property for a concurrent programming language (and modeling of reactive systems). Atomic unification states that unifying (equating) terms is performed instantaneously, so that an attempt by two different processes to bind the same variable to two different values always fails. In this case, only one of the unifications succeeds, and causes the other one to fail (this point is further discussed in Section 4). A more sophisticated synchronization mechanism is "Test and Set" unification. Clause structure in this mode is slightly different: •
-
A: -- Ask, Tell fBody. The Ask and Tell are conjunctions of goals (possibly empty), where the Ask goals are predicates (system tests as in the flat guarded clause), and the Tell part contains only equality goals. The Ask part is essentially the same as the guard part seen so far. However, the Tell part that is not empty works as follows: initially, the goal is unified with the clause's head using Ask unification, and the Ask tests are performed. If they fail or suspend, so does the clause. If they succeed, the Tell unification is performed, equating terms and variables. This process can succeed or fail but not
Modeling and simulationof multi-robot systems • D. BEN-ARIEH suspend. If it succeeds, the result is the substitutions performed in the Tell part and the processes performed in the body. If it fails, the clause fails. This synchronization mechanism can be demonstrated in the following example: Two tasks are assigned to two robots by two process managers; each sends one task to both robots. Each one of the robots receives the two tasks. The task is of the form "task(X)", where X is a variable which gets the name of the robot that performs that task. The tasks should be received by each robot in such a way that each one gets only one task, and the two tasks received are different. The goals are: (1)
(2) (3)
manager(X, To_robot l, To_robot 2): T o _ r o b o t 1 = task(X), To_robot_2 = task(X). receive(Id, task(X1), _ ) : - true: Id = X1 Itrue. receive(Id, _, t a s k ( X 2 ) ) : - true: Id = X21true.
selected. The other clauses are then abandoned. In concurrent logic programming there is no backtracking, so the commitment to the selected clause is final. 4. C O N C U R R E N T I M P L E M E N T A T I O N OF M O D E L I N G SYSTEMS This section presents solutions to the problems raised in Section 2, and a concurrent implementation of reactive system modeling. 4.1. Conflict resolution One very important property of a concurrent modeling language in general, which F C P has, is an atomic unification mechanism. The implication of this mechanism is that two terms can be either unified or not unified, but never partially unified. As an example, when two processes concurrently try to unify terms that have a common variable, such as: process l: - (X1, X2) = (a, a). process 2: - (X2, X1) = (b, b).
The starting call to initiate the system is: manager(Taskl, M11, M12), manager(Task2, M22), receive(robotl, M l l , M21), receive(robot2, M22).
71
M21, M12,
In the above example two "manager" processes are initiated together with the "receive" processes. The "manager" processes send the message task(X) to each robot, and each robot writes its name on X. Since the variable X is sent to both robots, only one robot can write on X (X cannot have multiple values); the other robot gets the task from the other manager. This synchronization mechanism causes each robot to receive its task only from one manager, in a mutually exclusive manner. In other words, any received task from one manager constrains the other receiver to get the task from the other manager. The example demonstrates the nondeterministic choices possible in this approach, and the atomic "Test and Set" unification that guarantees mutual exclusion of the choices made. A second control and synchronization mechanism in FCP, besides unification, is the commit operator. Its procedural meaning is that the reduction of process A t to clause A: -- G[B is suspended until A1 is unifiable with A and the guard is determined to be true. Thus, the guard part is another mechanism for preventing or halting erroneous process actions. In concurrent logic programming, concurrency is achieved by reducing several processes in parallel. There are two kinds of parallelism: AND parallelism and OR parallelism. AND parallelism is exercised when a goal is reduced to n - 1 new processes, all active concurrently. OR parallelism can be performed when, given a process to reduce, all clauses applicable for its reduction may be tried in parallel. However, in F C P all applicable clauses are tried in parallel, but only the first one that has a true value for its guard is
The result can either be (X1 = a and X2 = a) or (X1 = b and X2 = b). A partial success in any unification process is infeasible, i.e. X1 = a, X2 = b cannot be a result of such a process. This property enables the modeler to use unification of terms as a distributed locking mechanism. 4.2. Global state detection: the short-circuit technique
4.2.1. Simple short circuit. The S.C. (Short Circuit) technique is a popular concurrent programming technique for detecting termination of several concurrent processes. The main concept is to "wire" all relevant processes to a circuit such that each process controls an open switch on that circuit. Each process closes its switch when a pre-defined local state is reached (e.g. termination state). A message sent from one end of the circuit reaches the other end only when all wired switches are closed, i.e. the desired global state is reached. In FCP, S.C. is implemented by using common variables as "wires" and the unification of variables as switch closing. As an example, detecting a global termination state of four processes is performed in the following way: system( .... Left-Right): - / * circuit creation*/ p( . . . . Left-Ml), p( .... MI-M2), p( .... M2-M3), p( . . . . M3-Right). p( . . . . L-R): --/* end condition*/ L = R./*close switch for each process*/ In the example, each process closes the switch using the unification L = R. When all processes are coneluded the variable Left is equal to Right, and any simple query for the value of Right can detect it.
72
Robotics & Computer-Integrated Manufacturing • Volume 8, Number 1, 1991
4.2.2. The open-close S.C. technique. The S.C. algorithm discussed so far has an irreversible switch closing, a property useful only if state change is permanent. When a global, reversible state must be detected, a different type of S.C. must be used: the open-close S.C. This algorithm is implemented by using an extra interrupt circuit on which special messages can be sent to perform switch state changing. When a closed switch has to be opened again, it is replaced with a new open switch and an interrupt is sent to the process's right neighbor to connect the new switch. The interrupt is propagated through all the neighbors with closed switches to change their connection. This mechanism is demonstrated in Fig. 4. After one switch is opened, there will be another attempt to check the closed circuit. 4.3. The synchronization mechanism The synchronization mechanism of multi-robot systems is composed of the following two procedures:
Tasks procedure 1. Verify that all the preconditions required for the task execution are available. 2. Instantaneously lock all of them (so no other task can change them). This atomic locking activity can either succeed or fail, but cannot lock half of the preconditions and then fail, creating conflicting events concurrently. 3. Cancel all the locked preconditions, and generate the corresponding post conditions.
Devices procedure 1. For all devices that are affected by the new post conditions, check preconditions validity. 2. Activate only the devices with true preconditions for their tasks. If additional requirements, such as fairness and liveness of the procedures, are added to the model, it becomes hard to implement. It is obvious that only a concurrent language with a strong locking mechanism is desired. This is implemented in FCP, using Tell unification and the fact that unification is performed atomically. 4.4. Representation of the system The system is represented as a network of communicating processes. Each process is either a task or a device. The network is similar to a Petri net in the Before P2 is Reopened
R P1
P2
P3
P4
After P2 is Reopened L
a/'~"~ b P1
c
~d' P2
e' . ~ . f ' It
g'.~.
P3
Fig. 4. Operation of the open-close S.C.
P4
sense that true preconditions generate "tokens" that propagate to the devices to which the task belongs. Communication is achieved by using common variables. Each vertex in the network (a task or a device) is represented by a network of processes containing one controller process and a set of communication processes, connecting the devices to their tasks. Tokens are represented as triplets containing a locking variable and other data such as time and userdefined data. 4.5. Implementation of the procedures All communication processes are connected in an open-close S.C. to the controller. 1. Step 1 : When a communication process receives a potential token (a valid precondition), it closes its switch and sends the locking variable to the controller. When the token is consumed (by another device), it reopens its switch. When the controller has its circuit shorted, step one is successfully ended. The purpose of the openclose S.C. is to notify the device when all necessary tokens exist (task can be performed). 2. Step 2: When all tokens are available, the controller tries atomic locking by unifying a term containing all locks with its name. If it succeeds it moves to step 3; otherwise it initializes the net. Success in this stage enables the device to be activated, defining the group of tokens to be removed (preconditions that are canceled). 3. Step 3: The controller sends new tokens on its output streams to set the post conditions, and initializes its input processes. 5. M O D E L EXTENSIONS 5.1. Adding task time Having implemented the system's heavy synchronization mechanism, adding time or other attributes to the tasks is a natural extension. Time is added as a task attribute which delays "token" flow. Each token carries a time attribute that is stamped at the moment of creation or task termination. It should be realized that the S.C. mechanism also guarantees chronological operation of the concurrent simulation. In other words, a slow process cannot create a token with an early time stamp which arrives late (a major difficulty in implementing concurrent discrete event simulation). The task always updates the time according to the latest time stamp on the corresponding tokens. To illustrate through Example 1, if the parts arrival times are: part a3, part b8 and part c12, and the assembly time of Robot 1 is 5 time units, the outgoing "tokens" have a time stamp of 17, indicating the moment the assembly is completed. These extensions add descriptive power to this modeling and simulation technique.
Modeling and simulation of multi-robot systems • D. BEN-ARIEH
5.2. Analysis of the models There are two main analysis approaches useful in simulation: verification of model correctness, and performance evaluation. Performance evaluation can be done using the timed models, but in this case the concurrent nature of the model is not obviously superior to the traditional discrete event simulation. The real power of this concurrent modeling technique lies in its ability to detect deadlocks, conflicts, boundedness and other properties of interest in discrete concurrent systems. Deadlocks occur when no task can be performed and the simulation is suspended. This property is easily detected by the FCP interpreter, since all processes are suspended as well. Similarly, correctness of communication protocols, automated systems, and the like can be verified using the model. Another advantage for analysis of the proposed modeling approach is the reactive nature of the simulation, which enables the user to interact with it through many observation processes.
6. S U M M A R Y
This paper presents reactive systems and presents the difficulties in implementing models of such systems, especially if a true reactive mode is maintained. Moreover, the reader is introduced to the concurrent programming paradigm and to FCP as a modeling tool for discrete reactive concurrent systems. Finally, the paper suggests solutions to the implementation difficulties, and demonstrates their construction, thus tying together the problem and the proposed solution. The advantages of the concurrent implementation are: 1. This implementation has high descriptive power, actually describing the system as it is. 2. This approach supports better understanding of the distributed mechanism. This is achieved also by enabling the user to activate selected events, interactively. 3. It is truly concurrent, thus eliminating the problems caused by implementing Algorithms 1 and 2. 4. The approach is modular, so a change in one part of the model does not affect the rest. 5. The implementation environment supports the modeling process (e.g. debugging, execution of part of the model, etc.). 6. The reactive nature of the system is easily available in the concurrent implementation, due to the reactive nature of FCP. This paper does not consider the question of what is the preferred modeling approach for such systems, but rather looks at a particular one. Further research is required in investigating other concurrent programming paradigms, and assessing
73
their suitability for reactive systems modeling. The question of the "best" modeling approach for reactive systems should be examined; better methods for some system types could be found. The concurrent logic programming approach should be reexamined when appropriate hardware is available. REFERENCES
1. Bowen, D. L., Byrd, L., Pereira, L. M., Pereira, F. C. N., and Warren, D. H. D.: Prolog on the DEC System-10 User's Manu~'l,Technical Report, Department of Artificial Intelligence,University of Edinburgh, 1981. 2. Clark, K. L., Gregory, S.: A relational language for paraUel programming, in Proc. Conf. on Functional Programming Languages and Computer Architecture, ACM, 171-178, 1981. 3. Clark, K. L., Gregory, S.: PARLOG: parallel programming in logic. ACM Trans. Programming Languages Systems 8(1): 1-49, 1986. 4. Harel, D., Pnueli, A.: On the development of reactive systems. In Logics and Models of Concurrent Systems, Apt, K. R. (Ed.), pp. 477-498. New York, Springer, 1985. 5. Hirata, M.: Parallel list processing language OC and its self description. Computer Software 4(3): 41-64, 1987 (in Japanese). 6. Kowalski R.: Logic for Problem Solving. Elsevier North Holland, 1979. 7. Mierowsky, C.: Design and implementation of Flat Concurrent Prolog, Technical Report CS84-21, Department of Computer Science, The Weizmann Institute of Science, Israel, 1984. 8. Merabet, A. A.: Synchronization of operations in a flexible manufacturing cell: the Petri net approach, d. Mfg. Systems 5(3): 161-169, 1987. 9. Nof, S. Y., Whinston, A. B., Bullers, W. I.: Control and decision support in automatic manufacturing systems. AIIE Trans. 12(2): 156-168, 1980. 10. Nof, S. Y., Hanna, D.: Operational characteristics of multi-robot systems with cooperation. Int. J. Prod. Res. 27(3): 447-492, 1989. 11. Peterson, J. L.: Petri Net Theory and the Modeling of Systems. Prentice-Hall, 1981. 12. Preiss, K., Shi, O.: Process planning by logic programming. Robotics Computer-Integr. Mfg. 5(1): 1-10, 1989. 13. Reisig,W.: Nets consisting of conditions and events. In Petri Nets: an Introduction, Brauer, W., Rozenberg, G., Salomaa, A. (Eds.), pp. 17-30. Berlin, Springer, 1985. 14. Shapiro, E.: Concurrent Prolog: a progress report. IEEE Computer 19(8): 44-58, 1986. 15. Shapiro E.: A subset of Concurrent Prolog and its interpreter. In Concurrent Prolog: Collected Papers, Vol. 1, Shapiro, E. (Ed.). Cambridge, M.I.T. Press, 1987. 16. Sheu, P. C., Kashyap, R. L.: Programming robot systems with knowledge. Robotics Computer-lntegr. Mfg. 4(3): 359-367, 1988. 17. Steusloff,H. U.: Advanced real-time languages for distributed industrial process control. IEEE Computer 37-46, Feb. 1984. 18. Takeuchi, A., Kouchi, F.: Parallel logic programming languages. In Lecture Notes in Computer Science 225, also Proc. of Third Int. Conf. on Logic Programming, Shapiro, E. (Ed.), pp. 242-254, 1986. 19. Ueda, K.: Guarded horn clauses, Concurrent Prolog: Collected Papers, Vol. 1, Ch. 4, Shapiro, E. (Ed.). Cambridge, M.I.T. Press, 1987.
•
0736-5845/91 $3.00 + 0.00 © 1991 Pergamon Press plc
Paper C O N C U R R E N T M O D E L I N G A N D SIMULATION OF MULTI-ROBOT SYSTEMS D. BEN-ARIEH Department of Industrial Engineering and Management, Ben-Gurion University of the Negev, P.O. Box 653, Beer Sheva, Israel
Multi-robot systems can be viewed as a distributed, asynchronous and concurrem mechanism. The components of such a system communicate with each other and with the external world and perform discrete tasks. Such tasks exhibit nondeterminism, concurrency, mutual exdusivencss, and similar properties. Due to the system complexity, it is desired to model it for purposes of verification, analysis, and simulation. This paper has two objectives: to present the diflkulties in modeling and simulating such distributed, concurrent systems, and to describe a new implementation paradigm towards these objectives using concurrent logic programming. This approach is described and examples given using FCP (Flat Concurrent Prolog) for a robotic manufacturing cell.
1. INTRODUCTION One way to perceive robots is as devices that read sensory data, change their geometry frequently, and alter the surrounding world. The task performed by a robot is the result of input data and planned action. When more than one robot cooperates, the system is more complicated, because the tasks of each robot are also dependent upon the other robots' moves (depending on the mode of cooperation, as discussed, for example, in Ref. 10). Multi-robot systems, therefore, are difficult to program and control. Several approaches have been proposed in order to present, simulate, and control multi-robot systems: Petri net s models excel in describing concurrency, conflict problems, and non-determinism; however, this approach needs extensions in order to model activity durations or complex flow among the system elements. A different approach utilizes predicate logic as the modeling paradigm 16 and Prolog as the modeling tool. 12 Other approaches utilize extensions to the Petri net models9 and formal languages.17 Multi-robot systems can be viewed as distributed and asynchronous mechanisms which perform discrete tasks. The components of such a system communicate with one other and with the external world, and exhibit non-determinism, concurrency, mutual exclusiveness, and similar properties. In order to analyze, simulate and verify a system's operation, one must model material and information flow among the elements of the system, as well as the communication processes.
Example 1 The following example is used to demonstrate the desired properties of a modeling tool. The system described in Fig. 1 consists of two robots that assemble two different parts in an unsynchronized fashion. Robot 1 uses parts A, B, and C, and Robot 2 uses parts C and D for the end products. In addition to the common part C, the two robots share the workspace near the output conveyor. The robots have no special priority; therefore, if both are ready, one is activated nondeterministicaUy. Some desirable properties of modeling tools are: 1. Expressiveness. The descriptive power of the modeling tool should be sufficient to represent the properties of interest in the system.
ROBOT 1 ~ ROBOT 2 OUTPUT CONVEYOR 67
Fig. 1. Multi-robot assembly example.
68
Robotics & Computer-Integrated Manufacturing • Volume 8, Number I, 1991
2.
Uniqueness. Every system should be represented by a single model. More than one model for a given system reflects a non-unique modeling tool. 3. Nonambiguity. An ambiguous modeling tool allows one model to represent more than one system. 4. Conciseness. The modeling tool should represent the system in an efficient, nonredundant model. 5. Ease of analysis. An important objective of modeling is analysis of the models. Therefore the modeling tool should permit analysis of the system's properties. 6. Abstraction. The modeling tool should hide system properties that are extraneous to the representation and analysis. 7. Ease of use. The modeling technique should be convenient and useful to non-specialists. Systems that are distributed, asynchronous, and interrupt-driven, with a discrete state space, such as multi-robot systems, are termed "reactive systems". 4 Modelingsuch systems is inherently difficult, as discussed in Section 2. This paper presents a different modeling approach, aimed at reactive systems in general, and multi-robots specifically. This modeling approach is demonstrated on the robotic assembly cell described in Example 1. The next section describes some difficulties in computerized modeling of concurrent systems of the sort discussed. Section 3 presents the concurrent logic programming paradigm. Section 4 describes the F C P implementation of reactive models. Section 5 presents extensions to the basic modeling approach. Section 6 concludes the article and states further research issues.
2. I M P L E M E N T A T I O N ISSUES O F MULTIROBOT SYSTEMS This section highlights the difficulties in precise system modeling using sequential and concurrent simulation languages. The system properties mentioned here exist in Example 1.
Assumptions This paper treats multi-robot systems as a collection of finite-state machines. Each machine can be in a finite number of states; moving to a new state implies two things: the preconditions of the new state are true, and the post-conditions are fulfilled. This notion is similar to that of condition/event systems. ~3 Naturally the machines can operate concurrently, while machines can affect one another's state and activate one another. Each state machine can be in only one state at any instant. Preconditions are not assumed to be true after a machine has changed states. This assumption is justified ifa task's precondition can include availability of resources that are consumed during the task operation (e.g. parts availability).
Definitions Device: A robot or a mechanical entity that performs discrete tasks and is controlled individually, conforming to "the state machine definition. Task: An individual activity performed by a specific device. Each task has associated preconditions and postconditions. Task T~irepresents task i performed on device j. • To is the set of preconditions that have to be true for task T~j to occur. T~ • is the set of post-conditions that task T~ fulfills. Conflicting tasks: Tasks T/k and Tjl are called conflicting tasks if they both occur and
Nonconflicting tasks: A set of tasks T = (tl, t 2 , . . . , t , } is a nonconflicting set if every ti, t j e T can occur and is not conflicting. Comment All the examples to follow can be represented in terms of Petri nets 11 in which tokens in the input places represent valid preconditions, the transitions that fire represent task execution, and output tokens cause postconditions to be true. Therefore some of the examples are described both in physical terms and in Petri net form. 2.1. Sequential implementation languages A few difficulties can be demonstrated using the following naive algorithm:
Algorithm 1: The naive approach 1. For every device Dj, j = 1. . . . . n, if •T~j is nonempty or true, activate the device. 2. Go to step 1. This algorithm generates a subset of the states in which the system can be. This property appears in Example 1 when all input parts are available. In this case, only Robot 1 is always activated. The sequential nature of the algorithm introduces an execution order of events that is not intended in the system. The example also shows that although the preconditions for robot 2 are true, this robot is never activated, thus introducing an unfair schedule into the model. In order to alleviate the problem, an improved algorithm is presented:
Algorithm 2 1. Scan all the devices and find a set {T} ___D. The set D denotes all the devices, and { T} is the set of all the devices with true preconditions for their tasks. 2. Randomly select t~ e T and perform this task. 3. Go back to step 1. The second algorithm gives an answer to the tasks ordering problem, but is subject to other limitations: 1. The solution is less efficient. While the first algor-
69
Modeling and simulation of multi-robot systems • D. BEN-ARIEH
ithm performs task selection in constant time At = o(1), the second algorithm scans all the devices first, i.e. At = o(n). This means that since task selection in real systems takes constant time, there will be some n for which our model is slower than the real system. 2. This model still selects the tasks consecutively, so concurrent events take on some execution order that is not intended. This creates a complete ordering of task execution which introduces a different meaning to the model. 3. The sequential execution generates states that exist in the model but not in the real system (which leads to nonunique representation). Also, different systems share the same model, due to the limitations of the modeling approach (ambiguous model). The following example is given in terms of a Petri net and describes two cases: Fig. 2(a) shows two independent robots that operate concurrently, and Fig. 2(b) shows two robots that share a common resource in a mutually exclusive manner. In the first case, • T~k c~ • T~ = O, which is not true in the second case. Both cases are modeled by Algorithm 2, demonstrating the ambiguity of this modeling approach. In reactive system models, independent events should be able to occur concurrently. Implementing this property leads to the third algorithm:
Algorithm 3 1. For all the tasks with valid preconditions, choose randomly a non-conflicting group T and execute all t~ ~ T. 2. Go back to step 1. This algorithm executes fhe task selection process as if performed in parallel. This algorithm too has flaws: 1. 2.
Selection time At is still a function of n, probably of a higher order. The model assumes that task selection and execution take the same amount of time in all tasks. This leads to the need to introduce time explicitly into the model.
2.2. Concurrent implementation models In this section some problems in concurrent implementation are presented. Conflict. One of the important tasks in concurrent modeling is the conflict. This problem is demonstrated
robot1 robot2 avaiable avaiable perfor
"ski T
perform
robot1 avaiable
Ttask j 7:/°;
0 0
robot2 avaiable ~ tP:;:o;m
0 "v'lab"O
Fig. 2. Two different systems with a similar model.
part A partB partC partD available available available available pe~f r ~ om ( ~ ~ ~ task A T
T
£orm taskB
Fig. 3. The conflict problem in concurrent implementation.
by the following example, illustrated in Fig. 3. Two robots are attempting an assembly process that uses a common part. If they both start concurrently, only one can finish the operation, while the other is suspended and cannot finish. Global state detection. Sometimes it is desired to detect the presence of a "distributed" precondition that is a combination of several conditions. For example, an assembly operation can be performed only when components are available in all input buffers. If the check is performed sequentially, the response is bounded by the scan time of the algorithm. If we perform the check concurrently, there is an implementation difficulty, since each test can take a different amount of time and the results can arrive at various times. This again implies a scanning mechanism, which violates the concurrency assumption. Moreover, if preconditions are not steady and can change state (e.g. an input part exists, but is immediately taken by another robot), the problem is harder. By the time the model algorithm scans the preconditions list and reaches the state in which they are all true, the early ones might have changed their state. This can cause execution of a task for which the preconditions are no longer valid. Solutions to these modeling difficulties are presented in Section 4. 3. C O N C U R R E N T L O G I C P R O G R A M M I N G : AN OVERVIEW Logic programming languages, based on predicate logic, perform logical inference as a basic computational step. These languages typically are written declaratively. A logic program is composed of a finite set of universally quantified Horn clauses. 6 Concurrent languages, which have recently received much attention, apply four different strategies to exercise parallelism in interpreting the programs, is The most attractive strategy is stream parallelism, which involves cooperation of goals executed in parallel through shared variables. Several parallel logic programming languages based on stream parallelism have been proposed, including Relational Language, 2 Concurrent Prolop. 14 Parlog, 3 Guarded Horn Clauses 19 and OC. 5 The flexibility of the computation imposes a need for synchronization among the active processes. This is performed using data flow constraints, which res-
70
Robotics & Computer-IntegratedManufacturing • Volume8, Number 1, 1991
trict the feasible unification modes, as discussed below. 3.1. Flat Concurrent Prolog (FCP) This section briefly introduces the properties of FCP (Flat Concurrent Prolog) for later discussion of its adequacy for modeling/simulation. A more complete description can be found in Shapiro 14 and Mierowsky, 7 for example. In this section the Edinburgh syntax of Prolog is used, 1 so lists, terms, and goals follow their regular notation. Unification is used according to its standard definition. A parallel logic program is a collection of flat guarded clauses of the form:
H: -- G1, G2... GmIB1, B2,.. Bn.
m, n >_O.
In this case, H as well as each G~and B~ are goals. H is the clause's head, the Gs are its guard, and the Bs its body. The "l" operator is the commit operator that exists if the guard is not empty. Each clause can be read declaratively as: " H is true if the Gs and Bs are true". A flat guarded clause is a clause whose guard predicates are in the set of predefined guard test predicates. Clauses with the same name and number of arguments are grouped into procedures. The guard is a part of the synchronization mechanism, as discussed below. In concurrent logic programs, each goal is viewed as a process, and the program as a whole is viewed as a network of concurrent processes communicating by shared logical variables. The basic computational mechanism in logic programming is process reduction. In this process, a call to goal A' causes the goal A to be reduced to B1 ... Bn. The conditions for reduction are that A' unifies with A, and that G 1 ... Gm are true. Computation proceeds by repeatedly selecting a process and attempting to reduce it using the clauses in the associated procedures. The semantics of such languages allow nondeterministic process and clause selection, which means that these operations can be performed in any order or in parallel• The computational process of F C P can perform termination, iterations, and branching. A unit clause (a clause with empty body) of the form A: - true, specifies that a process whose head unifies with A can terminate. An iterative clause (a clause with a single goal in its body) A: - B, specifies that a process in a state unifiable with A can change its state to B. A general clause A: - BI ... B,, specifies that a process in a state unifiable with A can create n - 1 new concurrent processes B 2...B~, and simultaneously change state to B~. 3.2. Synchronization Synchronization is one of the crucial issues in concurrent logic programming. It is the mechanism that restricts the freedom of clause scheduling and communication among active processes, and synchronizes the computation with external events.
Synchronization can be performed using the unification mechanism. Three approaches exist: Ask unification (also called input unification), Read-Only unification, and Test-and-Set unification, x5 General (standard) unification is termed Tell unification. Ask unification is the simplest, most useful mechanism, and is efficient for process modeling. In this paper only Ask unification and Test-and-Set unification are utilized. Ask unification is used in a reduction step, and allows a term in the calling clause to be instantiated to a less detailed term. If the other term is more detailed (i.e. has a value) the calling one is suspended until it gets a value also, and can be matched. As an example, the reduction of p(X) to the goal p(a) succeeds (matches) when X gets the value "a". The goal p(X) is suspended until X gets this value. On the other hand, p(a) matches p(X) immediately. Using this mechanism, process synchronization can be achieved as shown in the following example: The call is: move(X, Done), take(X, Done). (Two concurrent goals.) The goals are: move(X, Done): - (X, Done) = (part_a, done). take (X, done): - take (X). The reduction of take(X, Done) to take(X, done) take(X) is suspended until the variable " D o n e " is instantiated to "done", by the process move(X, Done). This causes the process "take" to start only after the process "move" is finished. By sharing the variables in the call, processes "move" and "take" have the same variables; this causes the values to transfer as needed to activate the process "take". The F C P language employs atomic unification, which is a vital property for a concurrent programming language (and modeling of reactive systems). Atomic unification states that unifying (equating) terms is performed instantaneously, so that an attempt by two different processes to bind the same variable to two different values always fails. In this case, only one of the unifications succeeds, and causes the other one to fail (this point is further discussed in Section 4). A more sophisticated synchronization mechanism is "Test and Set" unification. Clause structure in this mode is slightly different: •
-
A: -- Ask, Tell fBody. The Ask and Tell are conjunctions of goals (possibly empty), where the Ask goals are predicates (system tests as in the flat guarded clause), and the Tell part contains only equality goals. The Ask part is essentially the same as the guard part seen so far. However, the Tell part that is not empty works as follows: initially, the goal is unified with the clause's head using Ask unification, and the Ask tests are performed. If they fail or suspend, so does the clause. If they succeed, the Tell unification is performed, equating terms and variables. This process can succeed or fail but not
Modeling and simulationof multi-robot systems • D. BEN-ARIEH suspend. If it succeeds, the result is the substitutions performed in the Tell part and the processes performed in the body. If it fails, the clause fails. This synchronization mechanism can be demonstrated in the following example: Two tasks are assigned to two robots by two process managers; each sends one task to both robots. Each one of the robots receives the two tasks. The task is of the form "task(X)", where X is a variable which gets the name of the robot that performs that task. The tasks should be received by each robot in such a way that each one gets only one task, and the two tasks received are different. The goals are: (1)
(2) (3)
manager(X, To_robot l, To_robot 2): T o _ r o b o t 1 = task(X), To_robot_2 = task(X). receive(Id, task(X1), _ ) : - true: Id = X1 Itrue. receive(Id, _, t a s k ( X 2 ) ) : - true: Id = X21true.
selected. The other clauses are then abandoned. In concurrent logic programming there is no backtracking, so the commitment to the selected clause is final. 4. C O N C U R R E N T I M P L E M E N T A T I O N OF M O D E L I N G SYSTEMS This section presents solutions to the problems raised in Section 2, and a concurrent implementation of reactive system modeling. 4.1. Conflict resolution One very important property of a concurrent modeling language in general, which F C P has, is an atomic unification mechanism. The implication of this mechanism is that two terms can be either unified or not unified, but never partially unified. As an example, when two processes concurrently try to unify terms that have a common variable, such as: process l: - (X1, X2) = (a, a). process 2: - (X2, X1) = (b, b).
The starting call to initiate the system is: manager(Taskl, M11, M12), manager(Task2, M22), receive(robotl, M l l , M21), receive(robot2, M22).
71
M21, M12,
In the above example two "manager" processes are initiated together with the "receive" processes. The "manager" processes send the message task(X) to each robot, and each robot writes its name on X. Since the variable X is sent to both robots, only one robot can write on X (X cannot have multiple values); the other robot gets the task from the other manager. This synchronization mechanism causes each robot to receive its task only from one manager, in a mutually exclusive manner. In other words, any received task from one manager constrains the other receiver to get the task from the other manager. The example demonstrates the nondeterministic choices possible in this approach, and the atomic "Test and Set" unification that guarantees mutual exclusion of the choices made. A second control and synchronization mechanism in FCP, besides unification, is the commit operator. Its procedural meaning is that the reduction of process A t to clause A: -- G[B is suspended until A1 is unifiable with A and the guard is determined to be true. Thus, the guard part is another mechanism for preventing or halting erroneous process actions. In concurrent logic programming, concurrency is achieved by reducing several processes in parallel. There are two kinds of parallelism: AND parallelism and OR parallelism. AND parallelism is exercised when a goal is reduced to n - 1 new processes, all active concurrently. OR parallelism can be performed when, given a process to reduce, all clauses applicable for its reduction may be tried in parallel. However, in F C P all applicable clauses are tried in parallel, but only the first one that has a true value for its guard is
The result can either be (X1 = a and X2 = a) or (X1 = b and X2 = b). A partial success in any unification process is infeasible, i.e. X1 = a, X2 = b cannot be a result of such a process. This property enables the modeler to use unification of terms as a distributed locking mechanism. 4.2. Global state detection: the short-circuit technique
4.2.1. Simple short circuit. The S.C. (Short Circuit) technique is a popular concurrent programming technique for detecting termination of several concurrent processes. The main concept is to "wire" all relevant processes to a circuit such that each process controls an open switch on that circuit. Each process closes its switch when a pre-defined local state is reached (e.g. termination state). A message sent from one end of the circuit reaches the other end only when all wired switches are closed, i.e. the desired global state is reached. In FCP, S.C. is implemented by using common variables as "wires" and the unification of variables as switch closing. As an example, detecting a global termination state of four processes is performed in the following way: system( .... Left-Right): - / * circuit creation*/ p( . . . . Left-Ml), p( .... MI-M2), p( .... M2-M3), p( . . . . M3-Right). p( . . . . L-R): --/* end condition*/ L = R./*close switch for each process*/ In the example, each process closes the switch using the unification L = R. When all processes are coneluded the variable Left is equal to Right, and any simple query for the value of Right can detect it.
72
Robotics & Computer-Integrated Manufacturing • Volume 8, Number 1, 1991
4.2.2. The open-close S.C. technique. The S.C. algorithm discussed so far has an irreversible switch closing, a property useful only if state change is permanent. When a global, reversible state must be detected, a different type of S.C. must be used: the open-close S.C. This algorithm is implemented by using an extra interrupt circuit on which special messages can be sent to perform switch state changing. When a closed switch has to be opened again, it is replaced with a new open switch and an interrupt is sent to the process's right neighbor to connect the new switch. The interrupt is propagated through all the neighbors with closed switches to change their connection. This mechanism is demonstrated in Fig. 4. After one switch is opened, there will be another attempt to check the closed circuit. 4.3. The synchronization mechanism The synchronization mechanism of multi-robot systems is composed of the following two procedures:
Tasks procedure 1. Verify that all the preconditions required for the task execution are available. 2. Instantaneously lock all of them (so no other task can change them). This atomic locking activity can either succeed or fail, but cannot lock half of the preconditions and then fail, creating conflicting events concurrently. 3. Cancel all the locked preconditions, and generate the corresponding post conditions.
Devices procedure 1. For all devices that are affected by the new post conditions, check preconditions validity. 2. Activate only the devices with true preconditions for their tasks. If additional requirements, such as fairness and liveness of the procedures, are added to the model, it becomes hard to implement. It is obvious that only a concurrent language with a strong locking mechanism is desired. This is implemented in FCP, using Tell unification and the fact that unification is performed atomically. 4.4. Representation of the system The system is represented as a network of communicating processes. Each process is either a task or a device. The network is similar to a Petri net in the Before P2 is Reopened
R P1
P2
P3
P4
After P2 is Reopened L
a/'~"~ b P1
c
~d' P2
e' . ~ . f ' It
g'.~.
P3
Fig. 4. Operation of the open-close S.C.
P4
sense that true preconditions generate "tokens" that propagate to the devices to which the task belongs. Communication is achieved by using common variables. Each vertex in the network (a task or a device) is represented by a network of processes containing one controller process and a set of communication processes, connecting the devices to their tasks. Tokens are represented as triplets containing a locking variable and other data such as time and userdefined data. 4.5. Implementation of the procedures All communication processes are connected in an open-close S.C. to the controller. 1. Step 1 : When a communication process receives a potential token (a valid precondition), it closes its switch and sends the locking variable to the controller. When the token is consumed (by another device), it reopens its switch. When the controller has its circuit shorted, step one is successfully ended. The purpose of the openclose S.C. is to notify the device when all necessary tokens exist (task can be performed). 2. Step 2: When all tokens are available, the controller tries atomic locking by unifying a term containing all locks with its name. If it succeeds it moves to step 3; otherwise it initializes the net. Success in this stage enables the device to be activated, defining the group of tokens to be removed (preconditions that are canceled). 3. Step 3: The controller sends new tokens on its output streams to set the post conditions, and initializes its input processes. 5. M O D E L EXTENSIONS 5.1. Adding task time Having implemented the system's heavy synchronization mechanism, adding time or other attributes to the tasks is a natural extension. Time is added as a task attribute which delays "token" flow. Each token carries a time attribute that is stamped at the moment of creation or task termination. It should be realized that the S.C. mechanism also guarantees chronological operation of the concurrent simulation. In other words, a slow process cannot create a token with an early time stamp which arrives late (a major difficulty in implementing concurrent discrete event simulation). The task always updates the time according to the latest time stamp on the corresponding tokens. To illustrate through Example 1, if the parts arrival times are: part a3, part b8 and part c12, and the assembly time of Robot 1 is 5 time units, the outgoing "tokens" have a time stamp of 17, indicating the moment the assembly is completed. These extensions add descriptive power to this modeling and simulation technique.
Modeling and simulation of multi-robot systems • D. BEN-ARIEH
5.2. Analysis of the models There are two main analysis approaches useful in simulation: verification of model correctness, and performance evaluation. Performance evaluation can be done using the timed models, but in this case the concurrent nature of the model is not obviously superior to the traditional discrete event simulation. The real power of this concurrent modeling technique lies in its ability to detect deadlocks, conflicts, boundedness and other properties of interest in discrete concurrent systems. Deadlocks occur when no task can be performed and the simulation is suspended. This property is easily detected by the FCP interpreter, since all processes are suspended as well. Similarly, correctness of communication protocols, automated systems, and the like can be verified using the model. Another advantage for analysis of the proposed modeling approach is the reactive nature of the simulation, which enables the user to interact with it through many observation processes.
6. S U M M A R Y
This paper presents reactive systems and presents the difficulties in implementing models of such systems, especially if a true reactive mode is maintained. Moreover, the reader is introduced to the concurrent programming paradigm and to FCP as a modeling tool for discrete reactive concurrent systems. Finally, the paper suggests solutions to the implementation difficulties, and demonstrates their construction, thus tying together the problem and the proposed solution. The advantages of the concurrent implementation are: 1. This implementation has high descriptive power, actually describing the system as it is. 2. This approach supports better understanding of the distributed mechanism. This is achieved also by enabling the user to activate selected events, interactively. 3. It is truly concurrent, thus eliminating the problems caused by implementing Algorithms 1 and 2. 4. The approach is modular, so a change in one part of the model does not affect the rest. 5. The implementation environment supports the modeling process (e.g. debugging, execution of part of the model, etc.). 6. The reactive nature of the system is easily available in the concurrent implementation, due to the reactive nature of FCP. This paper does not consider the question of what is the preferred modeling approach for such systems, but rather looks at a particular one. Further research is required in investigating other concurrent programming paradigms, and assessing
73
their suitability for reactive systems modeling. The question of the "best" modeling approach for reactive systems should be examined; better methods for some system types could be found. The concurrent logic programming approach should be reexamined when appropriate hardware is available. REFERENCES
1. Bowen, D. L., Byrd, L., Pereira, L. M., Pereira, F. C. N., and Warren, D. H. D.: Prolog on the DEC System-10 User's Manu~'l,Technical Report, Department of Artificial Intelligence,University of Edinburgh, 1981. 2. Clark, K. L., Gregory, S.: A relational language for paraUel programming, in Proc. Conf. on Functional Programming Languages and Computer Architecture, ACM, 171-178, 1981. 3. Clark, K. L., Gregory, S.: PARLOG: parallel programming in logic. ACM Trans. Programming Languages Systems 8(1): 1-49, 1986. 4. Harel, D., Pnueli, A.: On the development of reactive systems. In Logics and Models of Concurrent Systems, Apt, K. R. (Ed.), pp. 477-498. New York, Springer, 1985. 5. Hirata, M.: Parallel list processing language OC and its self description. Computer Software 4(3): 41-64, 1987 (in Japanese). 6. Kowalski R.: Logic for Problem Solving. Elsevier North Holland, 1979. 7. Mierowsky, C.: Design and implementation of Flat Concurrent Prolog, Technical Report CS84-21, Department of Computer Science, The Weizmann Institute of Science, Israel, 1984. 8. Merabet, A. A.: Synchronization of operations in a flexible manufacturing cell: the Petri net approach, d. Mfg. Systems 5(3): 161-169, 1987. 9. Nof, S. Y., Whinston, A. B., Bullers, W. I.: Control and decision support in automatic manufacturing systems. AIIE Trans. 12(2): 156-168, 1980. 10. Nof, S. Y., Hanna, D.: Operational characteristics of multi-robot systems with cooperation. Int. J. Prod. Res. 27(3): 447-492, 1989. 11. Peterson, J. L.: Petri Net Theory and the Modeling of Systems. Prentice-Hall, 1981. 12. Preiss, K., Shi, O.: Process planning by logic programming. Robotics Computer-Integr. Mfg. 5(1): 1-10, 1989. 13. Reisig,W.: Nets consisting of conditions and events. In Petri Nets: an Introduction, Brauer, W., Rozenberg, G., Salomaa, A. (Eds.), pp. 17-30. Berlin, Springer, 1985. 14. Shapiro, E.: Concurrent Prolog: a progress report. IEEE Computer 19(8): 44-58, 1986. 15. Shapiro E.: A subset of Concurrent Prolog and its interpreter. In Concurrent Prolog: Collected Papers, Vol. 1, Shapiro, E. (Ed.). Cambridge, M.I.T. Press, 1987. 16. Sheu, P. C., Kashyap, R. L.: Programming robot systems with knowledge. Robotics Computer-lntegr. Mfg. 4(3): 359-367, 1988. 17. Steusloff,H. U.: Advanced real-time languages for distributed industrial process control. IEEE Computer 37-46, Feb. 1984. 18. Takeuchi, A., Kouchi, F.: Parallel logic programming languages. In Lecture Notes in Computer Science 225, also Proc. of Third Int. Conf. on Logic Programming, Shapiro, E. (Ed.), pp. 242-254, 1986. 19. Ueda, K.: Guarded horn clauses, Concurrent Prolog: Collected Papers, Vol. 1, Ch. 4, Shapiro, E. (Ed.). Cambridge, M.I.T. Press, 1987.