- Email: [email protected]
Temporal logic programming for assembly sequence planning
Artificial Intelligence in Engineering 8 (1993) 253-263 © 1994 Elsevier Science Limited Printed in Great Britain. All rights reserved 0954-1810/94/$07.00
ELSEVIER
Temporal logic programming for assembly sequence planning 10am Tian Seow & R. Devanathan Division of Instrumentation and Control, School of Electrical and Electronic Engineering, Nanyang Technological University, Nanyang Avenue, Singapore 2263 A temporal-constraint logic programming framework for the specification and automatic verification and synthesis of assembly sequences is developed. The implemented tool is based on the formulated and derived precedence properties for a general mechanical assembly. This tool, called the Mechanical Assembly Sequence Satisfiability Checker (MASS-C), supports the use of a subset of temporal logic for assembly constraint specification. MASS-C provides the logic programming framework by which the designer can be relieved of the tedium of finding the assembly sequences, and the assembly sequence planning process manifests itself in the implicit modelling of assembly sequences by acquiring and formulating the set of correct and complete assembly constraints as a logic program. MASS-C implements a class of temporal expressions as predicates for logic programming of assembly constraints. It provides facilities to either verify an assembly sequence or synthesise all assembly sequences that satisfy the specified constraints composed as a logic program. Two examples illustrate the use of MASS-C for such verification and synthesis. Key words: assemblysequence planning, knowledgerepresentation and reasoning, logic programming, temporal logic, constraint, state-graph.
geometric (precedence) constraints are synonymous. Additional non-geometric requirements, called soft constraints, for purposes such as the ease of assembly, should also be imposed. Such constraints are called planner directives in Ayoub and Doty. 3 We distinguish the set of hard constraints from the soft constraints because algorithms2 are becoming available to automatically derive the former and this therefore forms a good base by which the latter (the soft constraints), asserting some user-defined criteria, can be imposed to select the assembly sequences. The purpose of this paper is to develop a formal language for specification and automated analysis of these constraints so as to yield the feasible assembly sequences. Automation can relieve the designer of the tedium of finding the assembly sequences. The assembly sequence planning process can manifest itself in the impficit modelling of assembly sequences by acquiring and specifying the set of assembly constraints for a given product assembly. The fundamental approach to finding the most appropriate (i.e. the best or optimal) assembly sequences is to represent all the possible ways to assemble the product to allow for exploration of the space of all possibilities. Various criteria are then
1 INTRODUCTION Assembly planning plays a fundamental role in the manufacture of most mechanically assembled products with discrete parts. High-level research in this field concerns itself primarily with assembly sequence planning, which has become a necessary link between the design and production of most assembled products. The main objective of this planning exercise is to find a set of feasible assembly sequences, each of which shows a different order of assembly tasks by which a mechanical assembly can be systematically connected from its various parts into a configuration that achieves the functions of the final product or mechanism. Assembly sequence planning can be regarded as a design process of identifying, specifying and satisfying all the constraints including the geometric or inherent ordering (precedence) constraints. Assembly sequences are dominantly constrained by product geometry. 1 Precedence constraints that are strictly invariant for a given assembly and cannot be violated in any assembling environment are called hard constraints. As such constraints are largely determined by the geometric properties of the assembly, we assume in our work, as is the case for Huang and Lee,2 that hard constraints and 253
254
Kiam Tian Seow, R. Devanathan Table 1. Some temporal operators and their intuitive meanings
Operator Eventually <>
Until/2
Precede 79
Always []
Intuitive meaning The formula <>P is true if, in the sequence of states, starting from the initial state so, there is some state in the future in which P is true. The formula Pb/Q is true if, in the sequence of states starting from So there is a state in which the formula Q is true, and for all states before then, the formula P is true. The formula PPQ is true if, in the the sequence of states starting from So, P becomes true before Q ever becomes true. The formula l i P is true if, P is true in all states of the sequence of states starting from the initial state So.
imposed to find those sequences. Existing techniques include an algorithmic search over a graphical representation such as the A N D / O R graph, 4 using admissible heuristics of some evaluation criteria. 5 Such an approach is rigid as many other specific criteria cannot be easily incorporated due to the current lack of mechanical manipulation capability on the A N D / O R graph. As a result, better sequences could be overlooked and little insight can be gained into the selected sequences. A more useful approach is the pragmatic development in computer-aided tools, especially those developed by Baldwin et aL 6 and Abell. 7 Here, evaluation and selection of assembly sequences are done by manual editing via computer-guided instructions and criteria options. In Delchambre, s all temporal constraints are specified by a single predicate precedence-order only. In this paper, we view assembly sequences as the semantics of temporal logic. We show that temporal logic, being a formal language, provides a solid basis on which a supporting verification and synthesis tool can be built using PROLOG. 9 This tool, called the Mechanical Assembly Sequence Satisfiability Checker (MASS-C), supports the use of a subset of temporal logic for assembly constraint specification for a general assembly. The tool implements a class of temporal expressions, involving the use of operators like Precede, 79; Until, H; Always, [q; and Eventually, <>; as predicates for logic programming of assembly constraints. It also has predicates to either verify an assembly sequence or synthesise all assembly sequences that satisfy the specified constraints composed as a logic program. The paper is organised as follows: section 2 provides the background on the proposed temporal framework, including the fundamental state-theorems and
process-axioms, the assembly sequence properties and the assembly state-based description of the basic precedence constraint, that forms the basis of the implementation. Section 3 presents the P R O L O G implementation and section 4 documents the current programming framework of MASS-C. Section 5 illustrates the use of MASS-C for verification and synthesis with two simple examples. Section 6 discusses and highlights the main strengths of the proposed framework. Section 7 summarises the main issues of the paper and points to some future work.
2 BACKGROUND Suppose there are exactly n tasks for a product assembly, then the status of these tasks (that is, whether each task is done or not) at each stage where some tasks just begin execution constitute an abstract state of the assembly process. By viewing all such possible states, a total of 2n of them, as the problem space, the process of assembly becomes a process of state-transitions in this problem space. Propositional temporal logic 1°'11 is a language of propositional logic augmented with temporal operators to facilitate reasoning over the space of sequences of states. The logical 'AND', 'OR', 'Negation', 'Implication' and 'Equivalence' connectives in propositional logic are denoted by the symbols A, V, % ~ and ~ or - , respectively. The sum ( ~ ) and product (l-I) symbols denote a string of logical 'OR' and 'AND' operations respectively. Temporal operators include Always, []; Eventually, <>; Until, /2; and Precede, 79. A logic formula containing at least one such operator is called a temporal formula. The temporal operators and their intuitive meanings are as tabulated in Table 1. Any formula that is not qualified by a temporal operator is assumed to be true only in the initial state So. The assembly problem space is formalised as a Mechanical Assembly Planning Structure (MAPS) which completely encompasses all feasible assembly sequences. MAPS is a simple Kripke structure 12 or state-transition graph 34 of discrete states associated with all defined assembly task symbols (defined in section 2.1) that constitute the assembly. We view assembly sequences as the semantics or semantic interpretations of temporal logic. A semantics interpretation (simply denoted as tr E 34) is said to satisfy a temporal formula asserting an assembly constraint if it evaluates the formula to be true. We first present an assembly scenario that characterizes the dynamic logic status of every defined task in assembly sequences, so as to sufficiently restrict the semantics to sequences (termed legal sequences or interpretations) for automated analysis.
Temporal logic programming for assembly sequence planning 2.1 The assembly scenario
The scenario of the general assembly process for mechanical assemblies can be formulated in terms of two state theorems and two process axioms. We first define some important terminologies. An assembly process task (or simply, assembly task) refers to an exclusive abstract entity whose execution results in the involved assembly parts being installed in their final relative positions. A set of the most common and basic assembly (or mating) tasks in industry 13 includes {simple-peg-insertion, multi-peg-insertion, screw, push-and-twist, force-fit, insert-and-retain, sticking, welding and place-on}. (1) Definition I (assembly process task symbol). It is a boolean or logic variable p (that is, having a logic value of TRUE or FALSE) that indicates whether an assembly task it represents has been done or not.
255
Given a set of tasks {Pl, P2, P3} for an assembly, if at a discrete instance of the assembly process, only the assembly task denoted by Pl is done and the other two tasks remain undone, then syntactically, the assembly process state may be described by the state formula (Pl A -'P2 A -'P3)-
2.1.1 Process state theorems Suppose {Pl, P2, ..- , Pn} is a list of n process task symbols that constitute the whole assembly. Then clearly, the following two theorems give the status of the initial and final states of any assembly process sequence. (1) Initial state theorem (NOR theorem). In the initial state of any assembly sequence, all assembly tasks are not done, that is n Pi =
False
i=1
A more general term to assert the DONE status of a group of tasks is given by the following definition. (2) Definition 2 (assembly process task formula). It is any formula P that contains at least one assembly process task symbol and satisfies the following conditions: (i) it does not have any '-~' connective; (ii) it does not have any temporal operators. Therefore, an assembly process task formula is a simple logic expression, in positive form, of 'A's and 'V's only, relating the process task symbols. For a given set of tasks {Pl, P2, P3}, some examples of assembly process task formulae are • Pl,
• Pl Ap2, • Pl Vp3, • Pl V (P2 Ap3). The significance of this concept will become clearer in section 2.1.2 when it is used to formulate the discrete change in the logic value of every defined task as the assembly process evolves through its states by which a given assembly can be efficiently and completely connected up. The state of an assembly can be asserted by the logic status of every assembly task symbol and is defined below. (3) Definition 3 (assembly process state). It is a discrete instance st of an assembly sequence that assigns to every task symbol a true or false value to indicate whether the assembly task is done or not done, respectively. (An assembly process-state is discrete in that it is the instance at which some tasks begin execution and no other task is being executed.)
(2) Final state theorem (AND theorem). In the final state of any assembly sequence all assembly tasks are done, that is n
r i p i = True i=1
2.1.2 Process axioms Suppose P is any assembly process task-formula. Then APX1 : ~- Q ( P ~ NP) APX2 : ~- <>P
(task persistence property) (task liveness property)
Intuitively, APX1 may be paraphrased as 'whenever P becomes true in an assembly process state, it will always remain true in subsequent states of the assembly process'. APX2 may be interpreted as 'there is a future assembly process state in which P is true'. APX1 and APX2 are necessity properties. APX1 constitutes a necessary condition that for process efficiency, in robotic assembly, for example, every assembly task, once done, should not be undone or redone at all throughout the rest of the assembly process. The 'DONE' status of every assembly task should persist, hence it is called the task persistence property. APX2 constitutes the nature of the assembly process in that every assembly task should eventually be executed for a complete assembly. This is 'something good' that must occur, and hence it is called the task liveness property. Collectively, these properties imply that every assembly task must be done once and only once.
These two axioms, together with the NOR theorem, form a general set .A which characterizes the fundamental nature of assembly sequences. (General axiom set ,A: axioms that apply to every task-symbol.)
Kiam Tian Seow, R. Devanathan
256
Legal Assembly Sequence Representations Pl Serial
Sinitial ~
Concurrent
s~iti~t~
Pl ,P2
P2
P3
Sl' ~
s2' ~ P3
S2' ~
Sfinal
Sfinal
[Pl,P2,P3] [[Pl,P2],P3]
Assembly Process State-formulae: ---+:
sinJtial : ('~Pl A ~P2 A "~P3)
Transition that switches the task symbols in 7- to logic TRUE and henceforth.
Sl' S2'
: (Pl A "~P2 A "~P3) : (Pl Ap2 A "~P3) S.fmal : (Pl Ap2 Ap3)
Fig. 1. Examples of legal state-sequences and their corresponding ordered lists. It has been shown in Ref. 14 that
Fig. 2. Semantics generator of I-A pjT~Pk .
~- [-l(e --~ l-]e) A ~ e --- --,PHI-IP
With the definitions and fundamental axioms, many assembly sequence properties have been formulated and mechanically proved using well-established rules and theorems of temporal logic, l°'u'15 These useful properties facilitate automatic and efficient reasoning so as to generate feasible assembly sequences. In particular, it is shown that the following properties provide a formal basis for the implementation of the control mechanism to check for assembly sequence satisfiability
Thus the 'condensed' axiom for assembly is APCX : t- ~ P H N P 2.2 The theoretical framework
2.2.1 Syntactic definition In our application, we are strictly reasoning in the assembly domain ,4 in which any legal sequence, if represented as an ordered list, is a sequence of all defined task symbols that appear once and only once. This is a symbolic view of a legal sequence that conforms to the assembly domain ,4 globally, as illustrated in Fig. 1 showing examples of a serial and a concurrent legal state sequence and their corresponding symbolic ordered lists for an assembly of three tasks {p~, P2, P3}. Therefore, it is sufficient to specify the model characteristic temporal constraints, with the convention that every task that constitutes the assembly is not done initially and would eventually be executed, once and only once, without having to explicitly state so. (Model characteristic constraints: specific assembly constraints to be satisfied by any L E G A L sequence of a particular assembly for feasibility.) Formally, if f(Pl, P2 . . . . , Pn) is an assembly constraint, where p / i s a task symbol, this implies
I-Af(Pl'P2"'"Pn)=F( ~piA[~piH[-Ipi] ) i = 1 Af(pl,p2,.--
APT6 APT8 APT10
P179P3V P2~P3 I- P3R(P1 V P2) ~-~P379P1A P37~P2 t- P3P(PI A P2) ~ P3PP1 V P37aP2 F- (P1 A P2)79P3~-~P17~P3A P2"PP3 F (PI V P2)~P3 ~
APT15 ~- P2LIP1 ~ I - l ( P 1 V -'P2) APT16 F
P279P1~ <>(~P1AP2)
The 'Precede' operator 7~ is defined (see Ref. 11, p. 163, Table A.1) as
el~P 2 -----~(-~pl/dP2 ) Some general theorems ~1 used include T7 F- I-q(P1 A P2) ~ [--1P1 A [-]P2 T8 b ~(P1 V P:) ~ ~P1 V ~ P 2 The Assembly Process Theorem (APT) numbers given above correspond to those given in Seow and Devanathan. 16 The proofs of these APT properties are provided in Seow and Devanathan) 4'16
2.2.2 Semantics definition
,Pn)
The basic 'Precede' constraint is expressed by
In the assembly domain .4, unless otherwise stated or implied, any assembly property or constraint P is simply written as F P or P instead of ~A p. We also use the convention that PA =f(Pl,P2,.--,Pn)
APT4
if, and only if,
P=(~'PiA[-~PiLtl--]Pi]) Af(pI'p2'''''pn)i=I
pjT~Pk where pj and Pk are assembly task-symbols. Figure 2 shows a semantics generator (automaton) of the basic 'Precede' constraint. This is the basic underlying structure upon which MASS-C is built. To evaluate this basic constraint formula, consider any finite sequence of discrete assembly process states whose tasks include pj and Pk- If this sequence starts in node q0,
Temporal logic programming for assembly sequence planning
257
Table 2. Symbol redefinitions
Symbolic representations in Theoretical framework
PI~°P2 ~P2HPI []-~(State) <>(state/) A V
MASS-C precede (LPI, L_PI) not_until(L_P2, L_P1) always_not(L_State) eve(Lstate/)
traverses along the transitions, and ends in the accepting node q2, represented by a double concentric circle, it is said to satisfy this basic assembly constraint pjT:'pk. In the next section, we present the implementation of MASS-C, a flexible logic programming framework that allows the assembly constraints to be represented as a logic program of the respective temporal predicates. The automaton of the basic element, pflgpk, sufficeS for our implementation because a useful class of assembly constraints can actually be expressed in terms of it using the assembly sequence properties stated under section 2.2.1. 3 IMPLEMENTATION MASS-C is implemented in Quintus PROLOG 9 on the IPC SUN SPARC workstation. Our current implementation contains two main modules. The first module implements a library of temporal operators, applicable in the assembly domain .4, as predicates for logic programming of assembly constraints. The temporal operators and their corresponding logic predicates, as implemented in MASS-C, are shown in Table 2, where L_X is a symbolic prefix list notation for the formula X. The second module contains verification and synthesis predicates. The synthesis predicate in a generator, producing all assembly sequences whose properties conform to the specified assembly constraints. The verification predicate checks and reports if its input sequence satisfies the constraints or not. Interested readers may refer to Appendix 1 for the implementation details of MASS-C.
4 THE LOGIC FRAMEWORK This section presents the basic steps to follow in the logic programming of assembly constraint specification. (1) Write the specification logic program (arbitrarily named as example.pl). (a) Declare all tasks. Use set_of_tasks/1 to declare all tasks for the assembly as a list of task symbols. (b) Specify hard constraints. Use the keyword hard constraint/O as the predicate name to
RING LENS
REFLECTOR
CASE
BATTERY1
BATTERY2
END
Fig. 3. A simple product in exploded view. write the PROLOG program of hard specifications. The body of this predicate can consist of only those temporal predicates whose arguments are instantiated with positive logic formulae of tasks declared in step(a) only. (c) Specify soft constraints. Use the keyword soft_constraint/O as the predicate name to write the PROLOG program of additional specifications. The body of this predicate is written similarly as for hard_constraint. (2) Load MASS-C and the program example.pl. (a) Compile the programs in the interpretive mode: compile (MASS-C); and compile (example). (3) Invoke the respective predicates: (a) Type generate(Seq). All assembly sequences that satisfy the specified constraints would be generated (b) Type verify(seq). A 'yes' or 'no' answer would be output to indicate whether the sequence, seq, satisfies the constraints or not, respectively. For information on the temporal predicates, see Appendix 3.
5 EXAMPLES 5.1 Example 1
A simple assembly as studied by De Mello 17 is used to illustrate the proposed framework. An exploded view of the assembly is shown in Fig. 3. There are notably three distinct assembly tasks to be performed to connect up the product. The symbols representing these tasks and their corresponding component parts are defined as follows: • P1: screw task, connecting CAP and RECEPTACLE; • P2: screw task, connecting RECEPTACLE and HANDLE; • P3: insert task, connecting RECEPTACLE and STICK. We declare all the task-symbols for the assembly by the following fact: set of tasks([pl,p2,p3]). We note that geometrically, the stick must be in the
Kiam Tian Seow, R. Devanathan
258
CAP
STICK
RECEPTACLE
HANDLE
Fig. 4. A flashlight in exploded view. receptacle before both ends are attached. In other words, P3 should be done before both Pl and P2 are done. The model-characteristic hard constraint 7-/4 is 7"/A = p37~(pl Ap2)
Therefore, the hard_constraint/0 is written as precede(p3, [and,pl,p2]). Consider the following soft constraints: (1) 81 = O-'(-,p~ ^ -'P2 ^P3) (2) S 2 = O(-~Pl A -~P3AP2)
,-ql specifies that the discrete process-state (-~pl A "P2 Ap3) must not appear in the sequence. ,-q2 specifies that (-~Pl A -~P3 A P2) must be one of the discrete process states in the sequence. Suppose we want to yield sequences that satisfy both the constraints, i.e. our soft constraints ,.q is given by
8 = 8 1 ^82 Thus, the soft_constraint/0 may be written as
always_not([and,[not and,pl,p2],p3]),/* Sl* / eve([and,[not and,pl,p3],p2]). /* ,S2 */ After successfully compiling the programs in the Quintus PROLOG interpretive mode, we can synthesise or verify the sequences by simply invoking the respective predicates. To synthesise, type generate(Seq), and press <>. The PROLOG interpreter returns the serial sequence: Seq-- ~o2,p3,pl] no
In our example, only one serial sequence satisfies the constraints. Suppose we want to check if the concurrent sequence [[p2,p3],pl] satisfies the specified constraints. Type verify([[p2,p3],pl]), and press << Enter >>. The PROLOG interpreter returns the answer: no This means that the input sequence does not satisfy the constraints.
5.2 Example 2 The second example uses a flashlight assembly as studied by De Mello. 17 An exploded view of the assembly is shown in Fig. 4. This more practical
example illustrates that MASS-C is capable of selecting the assembly sequences from a large space of geometrically feasible sequences, based on the specified assembly constraint formulae, thereby relieving the designer of the tedium of manually working out all the desired possibilities. There are six distinct assembly tasks to be performed to connect up the product. The symbols representing these tasks and their corresponding component parts are defined as follows: • Pl: force-fit task, connecting RING and LENS; • P2: screw task, connecting BULB and REFLECTOR; • P3: screw task, connecting RING and CASE; • Pd: place-on task, connecting REFLECTOR and CASE; • P5: insert task, connecting BATTERIES and CASE; • P6: screw task, connecting END and CASE. We declare all the task-symbols for the assembly by the following fact: set of tasks([pl,p2,p3,pd,p5,p6]). By geometric reasoning, the hard_constraint/0 is: hard constraint: precede(p5,[and,p4,p6]), precede([and,pl,p2,pd]),p3). The soft_constraint/0 for some (user-identified) soft constraints is: soft_constraint:precede([and,p5,p6], [or,pl,p2,p3,pd]), precede(p2,pd), always_not([ and, [not_and,p3,pd,p6], [and,pl,p2,p5]]), eve([ and, [not,p3], [and,pl,p2,pd,p5,p6]]), not_until(p 1,p2). To synthesize, type generate(Seq), and press << Enter >>. The PROLOG interpreter returns the serial sequence: Seq = Seq = Seq = Seq =
[p5,p6,p2,pl,pd,p3] [p5,p6,p2,pd,pl,p3] [p6,pS,p2,pl,pd,p3] [p6,pS,p2,pd,pl,p3]
no
In this example, four serial sequences satisfy the constraints. Suppose we want to check if the concurrent sequence [[p6,p5] ,p2, [pl,pd],p3] satisfies the specified constraints. Type verify([[p6,pS],p2, [pl,pd],p3]). and press << Enter >>. The PROLOG interpreter returns the answer: yes This means that the input sequence satisfies the constraints. It should be noted that in the two examples above,
Temporal logic programming for assembly sequence planning
259
Table 3. Various proposed representations of assembly task precedence No.
1 2
Symbolic representations as used in Proposed framework
Huang 2
De Mello 2°
Ayoub 3, Fox 18
pl"Pp2 -~p2blPl
MP(pl,P2) NL(pl ,P2)
Pl < P 2 Pl -( P2
Pl < P 2 --
although a 'yes' or 'no' answer may not be exactly what the designer expects from an assembly sequence planning system, that is what the current verifier is designed for. A more fully developed MASS-C should keep track of the constraints that are satisfied or violated. These would be output via an 'explanation' window interface if requested.
6 DISCUSSION A representation scheme is considered complete if it has the ability to represent disjunctive ordering constraints, thereby encompassing the set of all assembly sequences. It can be easily shown that the proposed framework, by its logical formalism including disjunction (logical 'OR'), is complete. In the rest of the discussion, we highlight that the main strengths of the proposed framework for assembly sequence planning, over previous work, 2'3'17-1°9 lie in its precise formalism, temporal expressiveness and analytical (i.e. mechanical manipulation) capability. Existing complete schemes are limited to at most two operators (see Table 3, where element no. 1 indicates that task Pl must precede task P2, and element no. 2 indicates that Pl must precede or be simultaneous with task P2)- The richer set of temporal operators that the proposed framework offers allows an easier and more direct way of specifying the assembly constraints. Take for instance, under section 5.1, we see that 82 directly specifies that the assembly process state described by the state-formula (~Pl A ~P3 A P2) is an eventual state of the sequence. If any of the existing schemes such as Huang 2 is used, such a constraint can only be indirectly specified as MP (P2,Pl Vp3). This is certainly not a natural and an easy way of specifying a desired assembly state. Such a limitation is magnified in a larger state problem than the simple example, when expressing one or more desirable state formulae in terms of the M P 0 predicate becomes obviously cumbersome. In the proposed framework, property APT16 allows the equivalent precedence constraint to be directly derived from the desired assembly process state. This means that the framework actually provides a flexible means to specify and analyse the precedence relationships among the assembly tasks involved. A similar reasoning using property APT15 argues for the Always [] operator as used in $1. The definition of the 'Precede' element as a state transition diagram, as shown in Huang (Ref. 2, p. 221),
De Fazio 19
Pl ~ P 2 --
is not precise enough as to provide the basis for automatic generation of assembly sequences by computer software implementation. Using the formalism of temporal logic, the 'Precede' element corresponds to an automaton as shown in Fig. 2. Together with some rigorously derived algebraic properties shown under section 2.2.1, they form a formal and precise foundation for the implementation of MASS-C for automatic analysis of assembly sequences. De Mello and Sanderson 2° have proposed a representation based on the 'AND/OR' graph. However, the conclusion of De Mello and Sanderson 4 indicates that there is a current lack of mechanical manipulation on 'AND/OR' graph. As a result, temporal constraints such as the soft constraints S under section 5.1, arising from many other specific criteria, cannot be easily and directly incorporated for qualitative analysis. In the 'AND/OR' graph representation, there is no equivalent inference mechanism to select all the conforming assembly sequences as demonstrated under section 5.1. A detailed discussion and comparison with existing representations may be found in Scow. 21 7 CONCLUSION A temporal logic framework is proposed for specifying and analyzing mechanical assembly sequences. Propositional temporal logic of Manna and Pneuli is the assertion language for representing and analysing all constraints or conditions that assembly sequences must satisfy. Based on the defined temporal framework, we show how a simplified programming framework, MASS-C, is implemented to support assembly sequence planning as an automated temporal constraint-based design. MASS-C is developed with the philosophy that such planning can be done by first acquiring and formulating the assembly constraints for a given mechanical assembly. Two examples demonstrate the automatic verification and synthesis of assembly sequences that satisfy the formulated assembly constraints composed as a logic program. The main objective of our implementation is to show the feasibility of automatic verification and synthesis based on the formal support of our defined theoretical framework. A full-scale implementation would include many CAD and expert features, some of which are listed below. • A multi-window user-interface for effective on-line evaluation of the effects of different constraints on the available sequences.
260
Kiam Tian Scow, R. Devanathan
• A facility to check for and explain possible conflicting assembly constraints between the hard and soft specifications. • A graphics interface to visualise assembly sequences, as a state-graph, for example.
ACKNOWLEDGEMENTS The authors thank the anonymous referees for their comments.
REFERENCES 1. Sanderson, A. C., De Mello, L. S. H. & Zhang, H., Assembly sequence planning. Artificial Intelligence Magazine, 11(1) (1990) 62-81. 2. Huang Y. F. & Lee, C. S. G., Precedence knowledge in feature mating operation assembly planning. In Proceedings of the IEEE "International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1989, pp. 216-21. 3. Ayoub, R. G. & Doty, K. L., A representation for discrete assembly sequences in task planning. Proceedings of the IEEE 13th Annual International Computer Software and Applications Conference, IEEE Computer Society, Washington, DC, 1989, pp. 746-53. 4. De Mello L. S. H. & Sanderson, A. C., And/or graph representation of assembly plans. IEEE Trans. Robotics Automation, 6(2) (1990) 188-99. 5. De Mello, L. S. H. & Sanderson, A. C., Evaluation and selection of assembly plans. In Proceedings of the IEEE International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1990, pp. 1588-93. 6 Baldwin, D. F., Abell, T. E., Lui, M. C. M., De Fazio, T. L. & Whitney, D. E., An integrated computer-aid for generating and evaluating assembly sequences for mechanical products. IEEE Trans. Robotics Automation, 7(1) (1991) 78-84. 7. Abell, T. E., An interactive software tool for editing and evaluating mechanical assembly sequences based on fixturing and orientation requirements. Master's thesis, Mechanical Engineering, MIT, MA, USA, 1989. 8. Delchambre, A., A pragmatic approach to computer-aided assembly planning. In Proceedings of the IEEE International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1990, pp. 1600-5. 9. Quinus Corporation, an Intergraph Corporation, Quintus Prolog Release 3.1.1 for the SUN 3/4, II: Language and Library Manual, February 1991. 10. Manna, Z. & Pneuli, A., A temporal proof system. Foundations of Computer Science IV, Distributed Systems: Part 2, Semantics and Logic, eds J. de Bakker & J. V. Leeuwen. Mathematical Centre Tracts I59, Amsterdam, The Netherlands, 1983, pp. 163-255. 11. Ostroff, J. S., Appendix A: Formal overview of temporal logic and Appendix B: Temporal logic theorems and rules. Temporal logic for Real Time Systems, Research Studies Press Ltd, John Wiley & Sons Inc., New York, USA, 1989, pp. 155-71, 172-83. 12. Clarke, E. M., Brown, M. C., Emerson, E. A. & Sistla, A. P., Using temporal logic for automatic verification of finite state systems. Logics and Models of Concurrent Systems
(NATO ASI series, Vol. F13), ed. K. Apt. Springer Verlag, Berlin, Heidelberg, Germany, 1985, pp. 3-26. 13. Whitney, D. E., et al., Computer-Aided Design of Flexible Assembly Systems (First and Final Reports, Report No: CDSL-R-1947 and CDSL-R-2033). C.S. Draper Laboratory, Inc., Cambridge, MA, USA. 14. Scow, K. T. & Devanathan, R., Temporal logic formulation of assembly sequence properties. In Proceedings of the IEEE International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1992, pp. 1208-13. 15. Ross, K. A. & Wright, C. R. B., Discrete Mathematics (2nd edn). Prentice Hall, Inc. Englewood Cliffs, NJ, USA, 1988. 16. Scow, K. T. & Devanathan, R., A temporal logic framework for assembly sequence planning. In Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems, IEEE Computer Society, Picataway, NJ, 1992. 17. De Mello, L. S. H., Task sequence planning for robotic assembly. PhD thesis, Electrical and Computer Engineering, Carnegie-Mellon University, 1989. 18. Fox, B. R., A representation for serial robotic tasks. PhD thesis, Computer Science, University of Missouri-Rolla, 1987. 19. De Fazio, T. L. & Whitney, D. E., Simplified generation of all mechanical assembly sequences. IEEE J. Robotics Automation, RA-3(6) (1987) 640-58. (Also, corrections: IEEE J. Robotics Automation, RA-4(6) (1988) 705-708. 20. De Mello, L. S. H. & Sanderson, A. C., Representations of mechanical assembly sequences. IEEE Trans. Robotics Automation, 7(2) (1991) 211-27. 21. Scow, K. T., Robotic-task sequence representation and analysis. Master of Engineering Thesis, School of Electrical and Electronic Engineering, Nanyang Technological University, Singapore, June 1992. 22. Bharath, R., PROLOG: Sophisticated Applications in Artificial Intelligence (lst edn). Windcrest Books, Blue Ridge Summit, PA, 1989.
APPENDIX 1: IMPLEMENTATION DETAILS OF MASS-C AI.1 The library module The programming technique called recursion 22 is the basic design strategy used. Lists are a natural form of data structure for recursive programs. Therefore, we use the list structure to represent the explicit assembly sequences, both serial and parallel, as well as the assembly process task formula in prefix list form. As an ordered list o f tasks, a parallel or concurrent sequence has at least one member which is a list subset containing two or more task symbols, representing task concurrency. A serial sequence is just an ordered list whose members are single task symbols. AI.I.1 The "Precede' operator 79 This section presents the description of the semantics interpretation in fig. 2 in P R O L O G , and shows how to check for sequence satisfiability for the basic and general 'Precede' constraint expressions. Fig. AI.1 shows an implementation structure of Fig. 2, from the symbolic
Temporal logic programming for assembly sequence planning
~ ~\
P ~=pj or P ~=Pk orP ~=listwithpjorP k j
'J
P~cpjorP=~Pk orP~=1istwithpjorD K
ant1
o
wit,outC~1 P = 13 or P == llSt and Pj
Fig. AI.1. Implementation structure for the semantics generator of F-Apj79Pk. P is a transition variable (can be instantiated with a task-symbol or symbolic list). The list in each state indicates only the DONE status of the two tasks, pj and Pk. point of view. The task symbol or list of task symbols that can be associated with any transition in Figure A 1.1 corresponds to the same transition in Fig. 2 which causes a switch from logic FALSE in the exiting node to logic T R U E in the entering node and henceforth, for the same assembly tasks. Two parts can be identified. (A) The simple state-graph. In this structure, each transition can be instantiated by a member (constant task symbol or task list) of a list representing a possible sequence to be verified. A transition can be instantiated with the member only if it satisfies the associated transition rule. When a transition rule is satisfied, a node transits to another with all the task symbols the former has collected plus the task-symbol or task list instantiating the transition. (B) The recursive control. The sequencing mechanism is apparent in Fig. A1.1 from the starting node q0 indicated by >, and the accepting node q2 indicated by a double concentric circle, that a sequence must, respectively, begin and end in to be considered satisfiable. This recursive mechanism (also termed the basic satisfiability check) successively inputs all the members of a sequence to the simple state graph starting initially from node q0, and checking if the accepting node q2 is reached after the last member has been input. Appendix 2 documents the description of some predicates (jtlist/3, nthO/3, argument_extract~2 and store/l) used in the program development.
(A.1) The simple state graph description: precede~4. In P R O L O G , a state graph may be expressed as a set of rules under the same predicate name. Each rule expresses the condition by which a current state transits to the next state. In our application, our predicate has an additional argument, the variable list of two task symbols of the precede relation. Hence, referring to . AI.1 with j---1 and k - - 2 , the state graph for l~Pp2 may be coded by a four-argument predicate precede(Varlist,Curr_state,Next_state,Transition) as follows:
261
Rule 1: For self-transitions: q0 ~ q0, ql ~ ql and P
q2 ~ q2. (1 a) P is a symbol. precede(Varlist,Curr_state,Next_state,P):isa_symbol(P), not member(P,Varlist), jtlist(Curr_state,[P],Next state),!. (lb) PL is a list. precede(Varlist,Currstate,Next_state,PL):isa list(PL) disjoint(PL),Varlist), jtlist(Curr_state,PL,Next state),!. Rule 2: for transition: q0 ~ ql. (2a) P1 is a symbol. precede(Varlist,Currstate,Next_state,P1):isa_symbol(P1), nth0(0,Varlist,P1), nth0(l,Varlist,P2), not member(P1,Currstate), not member(P2,Curr_state), jtlist(Curr_state,[P1],Next_state),!. (2b) PL1 is a list. precede(Varlist,Curr._state,Next_state,PL 1):isa_list(PL 1), nth0(0,Varlist,P 1), member(P1,PL1), nth0(1,Varlist,P2), not member(P2, Curr_state), not member(P2,Cur_state), not member( P2,PL l ),
jtlist( Curr_state,P L1,Next_state ),!. Rule 3: For transition: ql ~ q2. (3a) P2 is a symbol. precede(Varlist,Curr_state,Next_state,P2):isa_symbol(P2), nth0(0,Varlist,P1), member(P 1,Curr state), nth0(1,Varlist,P2), not member (P2, Curr_state), jtlist(Currstate,[P2],Next_state),!. (3b) PL2 is a list. precede(Varlist,Curr state,Next_state,PL2):isa_list(PL2), nth0(0,Varlist,P1), member(P1,Curr_state), not member( P1,PL2), nth0(l,Varlist,P2),
member(P2,PL2), not member(P2,Currstate),
jtlist( Curr_state,P L2,Next_state ),!. (B.1) Basic satisfiability check: basic_precede_seq_ check~3. Conceptually, this checking mechanism is built on top of precede/4 as it recursively invokes precede/4 to verify if
262
Kiam Tian Seow, R. Devanathan
an input task or task list of a sequence satisfies the basic precedence constraint starting from a given current state. This predicate may be coded by a three-argument predicate basic_ precede_seq_check(Varlist,Curr_state, Input seq) as follows: • The boundary case basic_precede_seq_check(Varlist,Curr_state, [] ):subset(Varlist,Curr_state),!. • The recursive control basic_ precede_seq check(Varlist,Curr_state, [HITail]):precede(Varlist,Curr_state,Next_state,H), basic_ precede_seq_check(Varlist,Next_state,Tail). The implemented mechanism works this way: The whole input legal sequence (input_seq), starting from an initialised state Curr_state, is 'cycled' through the states via basic_precede seq_check/3 recursively channeling the 'Head' of the remaining sequence to precede/4. The input sequence satisfies the precede constraint if all successive 'Heads' succeed the precede/ 4 predicate, and, as dictated in the boundary case, Curr_state is in the accepting node after the arrival of the last member of the sequence. General satisfiability check." precede/2 This two-argument precede predicate is one of the assembly temporal operators for the logic programming of assembly constraints. Like the other operators that would follow, it is implemented in such a way that the satisfiability check is transparent to the designer. The arguments are process task formulae represented in prefix list notation. Conceptually, precede/2, which can support the more general positive logic expressions involving the precede operator P, is built on top of basic_ precede_seq _check/ 3. The boundary case of precede/2 initialises the argument Curr_state of basic_precede_seq_check/3 to an empty list (meaning no task is done initially), and is given by precede(Argl,Arg2):isa_symbol(Argl), isa_symbol(Arg2), sequence(Seq), basic_ precede_seq check([Arg 1,Arg2],[ ],Seq),!. The derived assembly sequence properties (or rules) provide the formal basis for the implementation of the control mechanism. The prefix list notation used for the task formulae facilitates parsing. Hence, we have
By APT4: precede([or [Orhst],Arg2):equal(Orlist,[Task 1I_ ]), precede(Taskl,Arg2),!. precede([orlOrlist],Arg2):equal(Orlist,[_[Rest]), precede([or )Rest],Arg2), !. By APT 6: precede(Argl,[orL[Arg2]]):precede(Argl,Arg2),!. precede(Argl,[orlOrlist]):equal(Orlist,[Task 11Rest]), precede(Argl,Task), precede(Argl,[orlRest]),!. By APT 8: precede(Arg 1,[andlAndlist]):equal(Andlist,[Task 1I_ ]), precede(Argl,Taskl),!. precede(Argl,[andlAndlist]):equal(Andlist,[_lRest]), precede(Argl,[andIRest]),!. Al.l.2 The other temporal operators In the context of assembly, the other three temporal operators Until L/, Always [] and Eventually O can be easily implemented by directly coding some related assembly sequence properties. Hence, we have By definition for 'Precede' operator." not_until(Argl,Arg2):not precede(Argl,Arg2),!. By APT15: always_not([and,Neg list,Arg2]):argument_extract([-Neg_list,Arg 1), not_until(Arg2,Argl),!. By/'7: always_not([or h[[and, Neg_list ,Arg2]]]):argument_extract(Neg_list,Arg l), not_until(Arg2,Argl),!. always_not([orlOrasm_states]):equal(Or_asm_states,[Asm_statel Rest]), always_not(Asm state), always_not([or IRest]), !.
By APTIO: precede([andl[Argl]],Arg2):precede(Argl,Arg2),!.
By APT16: eve([and,Neg_list,Arg2]):argument_extract(Neg_list,Argl), precede(Arg2,Agl),!.
precede([andlAndlist],Arg2):equal(Andlist,[Task 1 IRest]), precede(Task l,Arg2), precede([andlRest],Arg2),!.
By TS: eve([or IOr_asm_states] ):equal(Or_asm_states,[Asm_statel_ ]), eve(Asm_state),!.
Temporal logic programming for assembly sequence planning eve([orlOr_asm_states]):equal(Or_asm_states,[_lRest]), eve([orlRest]),!.
263
appears in the sequence, once and only once.
APPENDIX 2: SUPPORTING PREDICATES
A1.2 The verification and synthesis module
A1.2.1 The synthesis predicate This predicate is implemented using the generate and test method. Essentially, it comprises two sub-modules, the guessing and checking predicates. The guessing module generates every solution (legal sequence) that is verified by the checking module. Here, the process_seq_generate/1 predicate plays the role of the guessing module while the specification/0 predicate plays the role of the checking module. The program is written as follows: generate(Seq):process_seq _generate(Seq), store(Seq), specification. PROLOG provides the backtracking mechanism by which every legal serial assembly sequence, represented as a list, is permutatively generated by the process_seq_generate/1 predicate using the list of all tasks declared in the set of tasks/1 predicate. Each sequence is then checked against the assembly constraints by the specification/0 predicate. Only the sequences that satisfy the constraints are accepted and output. The specification predicate is defined by specification:hard_constraint, soft constraint. Keeping the hard and soft constraints separate facilitates the more frequent modification to the soft_constraint/0 predicate. This helps to analyse and evaluate the effects of different soft constraints on the available sequences, which are determined by the hard_constraint/0 predicate.
(1) jlist(Listl, List2, List3): combines two lists Listl and List2 to form a joint list List3. (2) nthO(n, List, Elem): is true when Elem is the Nth element of the list List, counting the first as element 0. (3) argument_extract(NList, List): removes all the 'Negation' connectives ('not' or 'not_and') from list NList. The extracted argument, logically negated, is returned in list List. (4) store(List): deletes the previous sequence(_) and asserts the sequence(List) clause in the (top) first position in its predicate.
APPENDIX 3: ASSEMBLY CONSTRAINT LOGIC PROGRAMMING
A3.1 Available specification predicates
(A ) Auxiliary predicate: (1) set_of_tasks(List) ~ to declare all assembly task symbols in the List.
( B) Temporal predicates: (1) precede(Argl,Arg2) ~ to state that Argl precedes Arg2. (2) not_until(Arg2,Argl) ~ to state that Arg2 is not true or done until Argl has become true. (3) always_not(Arg) ~ to state that Arg is a list of infeasible assembly states. (4) eve(Arg) ~ to state that Arg is a list of feasible assembly states.
A3.2 Available specification predicate arguments
A1.2.2 The verification predicate This predicate is written similarly. The only difference is the use of process_axiom_check/1 predicate instead of process_seq_generate/1. The program is as follows: verify(Seq):process_axiom__check(Seq), store(Seq), specification. Note that process_seq__generate/1 enumerates only legal serial sequences whereas process_axiom_check/1 verifies if its input sequence, which can also be concurrent, is legal, that is, every assembly task defined for the given assembly, as declared in set of tasks/1 predicate,
(i) Argl and Arg2 are positive propositional logic formulae of assembly tasks in prefix list or single symbol notation. (2) Arg is a positive propositional logic formula in the prefix form: [orl Or_.asm states], where each member State or Or_asm_states is of the form: (a) [and,[not,Argl],Arg2] or (b) [and,[not_andfArg_list],Arg2], such that: Argl = [orlArg_list] In the simplest case, Arg = State.
ELSEVIER
Temporal logic programming for assembly sequence planning 10am Tian Seow & R. Devanathan Division of Instrumentation and Control, School of Electrical and Electronic Engineering, Nanyang Technological University, Nanyang Avenue, Singapore 2263 A temporal-constraint logic programming framework for the specification and automatic verification and synthesis of assembly sequences is developed. The implemented tool is based on the formulated and derived precedence properties for a general mechanical assembly. This tool, called the Mechanical Assembly Sequence Satisfiability Checker (MASS-C), supports the use of a subset of temporal logic for assembly constraint specification. MASS-C provides the logic programming framework by which the designer can be relieved of the tedium of finding the assembly sequences, and the assembly sequence planning process manifests itself in the implicit modelling of assembly sequences by acquiring and formulating the set of correct and complete assembly constraints as a logic program. MASS-C implements a class of temporal expressions as predicates for logic programming of assembly constraints. It provides facilities to either verify an assembly sequence or synthesise all assembly sequences that satisfy the specified constraints composed as a logic program. Two examples illustrate the use of MASS-C for such verification and synthesis. Key words: assemblysequence planning, knowledgerepresentation and reasoning, logic programming, temporal logic, constraint, state-graph.
geometric (precedence) constraints are synonymous. Additional non-geometric requirements, called soft constraints, for purposes such as the ease of assembly, should also be imposed. Such constraints are called planner directives in Ayoub and Doty. 3 We distinguish the set of hard constraints from the soft constraints because algorithms2 are becoming available to automatically derive the former and this therefore forms a good base by which the latter (the soft constraints), asserting some user-defined criteria, can be imposed to select the assembly sequences. The purpose of this paper is to develop a formal language for specification and automated analysis of these constraints so as to yield the feasible assembly sequences. Automation can relieve the designer of the tedium of finding the assembly sequences. The assembly sequence planning process can manifest itself in the impficit modelling of assembly sequences by acquiring and specifying the set of assembly constraints for a given product assembly. The fundamental approach to finding the most appropriate (i.e. the best or optimal) assembly sequences is to represent all the possible ways to assemble the product to allow for exploration of the space of all possibilities. Various criteria are then
1 INTRODUCTION Assembly planning plays a fundamental role in the manufacture of most mechanically assembled products with discrete parts. High-level research in this field concerns itself primarily with assembly sequence planning, which has become a necessary link between the design and production of most assembled products. The main objective of this planning exercise is to find a set of feasible assembly sequences, each of which shows a different order of assembly tasks by which a mechanical assembly can be systematically connected from its various parts into a configuration that achieves the functions of the final product or mechanism. Assembly sequence planning can be regarded as a design process of identifying, specifying and satisfying all the constraints including the geometric or inherent ordering (precedence) constraints. Assembly sequences are dominantly constrained by product geometry. 1 Precedence constraints that are strictly invariant for a given assembly and cannot be violated in any assembling environment are called hard constraints. As such constraints are largely determined by the geometric properties of the assembly, we assume in our work, as is the case for Huang and Lee,2 that hard constraints and 253
254
Kiam Tian Seow, R. Devanathan Table 1. Some temporal operators and their intuitive meanings
Operator Eventually <>
Until/2
Precede 79
Always []
Intuitive meaning The formula <>P is true if, in the sequence of states, starting from the initial state so, there is some state in the future in which P is true. The formula Pb/Q is true if, in the sequence of states starting from So there is a state in which the formula Q is true, and for all states before then, the formula P is true. The formula PPQ is true if, in the the sequence of states starting from So, P becomes true before Q ever becomes true. The formula l i P is true if, P is true in all states of the sequence of states starting from the initial state So.
imposed to find those sequences. Existing techniques include an algorithmic search over a graphical representation such as the A N D / O R graph, 4 using admissible heuristics of some evaluation criteria. 5 Such an approach is rigid as many other specific criteria cannot be easily incorporated due to the current lack of mechanical manipulation capability on the A N D / O R graph. As a result, better sequences could be overlooked and little insight can be gained into the selected sequences. A more useful approach is the pragmatic development in computer-aided tools, especially those developed by Baldwin et aL 6 and Abell. 7 Here, evaluation and selection of assembly sequences are done by manual editing via computer-guided instructions and criteria options. In Delchambre, s all temporal constraints are specified by a single predicate precedence-order only. In this paper, we view assembly sequences as the semantics of temporal logic. We show that temporal logic, being a formal language, provides a solid basis on which a supporting verification and synthesis tool can be built using PROLOG. 9 This tool, called the Mechanical Assembly Sequence Satisfiability Checker (MASS-C), supports the use of a subset of temporal logic for assembly constraint specification for a general assembly. The tool implements a class of temporal expressions, involving the use of operators like Precede, 79; Until, H; Always, [q; and Eventually, <>; as predicates for logic programming of assembly constraints. It also has predicates to either verify an assembly sequence or synthesise all assembly sequences that satisfy the specified constraints composed as a logic program. The paper is organised as follows: section 2 provides the background on the proposed temporal framework, including the fundamental state-theorems and
process-axioms, the assembly sequence properties and the assembly state-based description of the basic precedence constraint, that forms the basis of the implementation. Section 3 presents the P R O L O G implementation and section 4 documents the current programming framework of MASS-C. Section 5 illustrates the use of MASS-C for verification and synthesis with two simple examples. Section 6 discusses and highlights the main strengths of the proposed framework. Section 7 summarises the main issues of the paper and points to some future work.
2 BACKGROUND Suppose there are exactly n tasks for a product assembly, then the status of these tasks (that is, whether each task is done or not) at each stage where some tasks just begin execution constitute an abstract state of the assembly process. By viewing all such possible states, a total of 2n of them, as the problem space, the process of assembly becomes a process of state-transitions in this problem space. Propositional temporal logic 1°'11 is a language of propositional logic augmented with temporal operators to facilitate reasoning over the space of sequences of states. The logical 'AND', 'OR', 'Negation', 'Implication' and 'Equivalence' connectives in propositional logic are denoted by the symbols A, V, % ~ and ~ or - , respectively. The sum ( ~ ) and product (l-I) symbols denote a string of logical 'OR' and 'AND' operations respectively. Temporal operators include Always, []; Eventually, <>; Until, /2; and Precede, 79. A logic formula containing at least one such operator is called a temporal formula. The temporal operators and their intuitive meanings are as tabulated in Table 1. Any formula that is not qualified by a temporal operator is assumed to be true only in the initial state So. The assembly problem space is formalised as a Mechanical Assembly Planning Structure (MAPS) which completely encompasses all feasible assembly sequences. MAPS is a simple Kripke structure 12 or state-transition graph 34 of discrete states associated with all defined assembly task symbols (defined in section 2.1) that constitute the assembly. We view assembly sequences as the semantics or semantic interpretations of temporal logic. A semantics interpretation (simply denoted as tr E 34) is said to satisfy a temporal formula asserting an assembly constraint if it evaluates the formula to be true. We first present an assembly scenario that characterizes the dynamic logic status of every defined task in assembly sequences, so as to sufficiently restrict the semantics to sequences (termed legal sequences or interpretations) for automated analysis.
Temporal logic programming for assembly sequence planning 2.1 The assembly scenario
The scenario of the general assembly process for mechanical assemblies can be formulated in terms of two state theorems and two process axioms. We first define some important terminologies. An assembly process task (or simply, assembly task) refers to an exclusive abstract entity whose execution results in the involved assembly parts being installed in their final relative positions. A set of the most common and basic assembly (or mating) tasks in industry 13 includes {simple-peg-insertion, multi-peg-insertion, screw, push-and-twist, force-fit, insert-and-retain, sticking, welding and place-on}. (1) Definition I (assembly process task symbol). It is a boolean or logic variable p (that is, having a logic value of TRUE or FALSE) that indicates whether an assembly task it represents has been done or not.
255
Given a set of tasks {Pl, P2, P3} for an assembly, if at a discrete instance of the assembly process, only the assembly task denoted by Pl is done and the other two tasks remain undone, then syntactically, the assembly process state may be described by the state formula (Pl A -'P2 A -'P3)-
2.1.1 Process state theorems Suppose {Pl, P2, ..- , Pn} is a list of n process task symbols that constitute the whole assembly. Then clearly, the following two theorems give the status of the initial and final states of any assembly process sequence. (1) Initial state theorem (NOR theorem). In the initial state of any assembly sequence, all assembly tasks are not done, that is n Pi =
False
i=1
A more general term to assert the DONE status of a group of tasks is given by the following definition. (2) Definition 2 (assembly process task formula). It is any formula P that contains at least one assembly process task symbol and satisfies the following conditions: (i) it does not have any '-~' connective; (ii) it does not have any temporal operators. Therefore, an assembly process task formula is a simple logic expression, in positive form, of 'A's and 'V's only, relating the process task symbols. For a given set of tasks {Pl, P2, P3}, some examples of assembly process task formulae are • Pl,
• Pl Ap2, • Pl Vp3, • Pl V (P2 Ap3). The significance of this concept will become clearer in section 2.1.2 when it is used to formulate the discrete change in the logic value of every defined task as the assembly process evolves through its states by which a given assembly can be efficiently and completely connected up. The state of an assembly can be asserted by the logic status of every assembly task symbol and is defined below. (3) Definition 3 (assembly process state). It is a discrete instance st of an assembly sequence that assigns to every task symbol a true or false value to indicate whether the assembly task is done or not done, respectively. (An assembly process-state is discrete in that it is the instance at which some tasks begin execution and no other task is being executed.)
(2) Final state theorem (AND theorem). In the final state of any assembly sequence all assembly tasks are done, that is n
r i p i = True i=1
2.1.2 Process axioms Suppose P is any assembly process task-formula. Then APX1 : ~- Q ( P ~ NP) APX2 : ~- <>P
(task persistence property) (task liveness property)
Intuitively, APX1 may be paraphrased as 'whenever P becomes true in an assembly process state, it will always remain true in subsequent states of the assembly process'. APX2 may be interpreted as 'there is a future assembly process state in which P is true'. APX1 and APX2 are necessity properties. APX1 constitutes a necessary condition that for process efficiency, in robotic assembly, for example, every assembly task, once done, should not be undone or redone at all throughout the rest of the assembly process. The 'DONE' status of every assembly task should persist, hence it is called the task persistence property. APX2 constitutes the nature of the assembly process in that every assembly task should eventually be executed for a complete assembly. This is 'something good' that must occur, and hence it is called the task liveness property. Collectively, these properties imply that every assembly task must be done once and only once.
These two axioms, together with the NOR theorem, form a general set .A which characterizes the fundamental nature of assembly sequences. (General axiom set ,A: axioms that apply to every task-symbol.)
Kiam Tian Seow, R. Devanathan
256
Legal Assembly Sequence Representations Pl Serial
Sinitial ~
Concurrent
s~iti~t~
Pl ,P2
P2
P3
Sl' ~
s2' ~ P3
S2' ~
Sfinal
Sfinal
[Pl,P2,P3] [[Pl,P2],P3]
Assembly Process State-formulae: ---+:
sinJtial : ('~Pl A ~P2 A "~P3)
Transition that switches the task symbols in 7- to logic TRUE and henceforth.
Sl' S2'
: (Pl A "~P2 A "~P3) : (Pl Ap2 A "~P3) S.fmal : (Pl Ap2 Ap3)
Fig. 1. Examples of legal state-sequences and their corresponding ordered lists. It has been shown in Ref. 14 that
Fig. 2. Semantics generator of I-A pjT~Pk .
~- [-l(e --~ l-]e) A ~ e --- --,PHI-IP
With the definitions and fundamental axioms, many assembly sequence properties have been formulated and mechanically proved using well-established rules and theorems of temporal logic, l°'u'15 These useful properties facilitate automatic and efficient reasoning so as to generate feasible assembly sequences. In particular, it is shown that the following properties provide a formal basis for the implementation of the control mechanism to check for assembly sequence satisfiability
Thus the 'condensed' axiom for assembly is APCX : t- ~ P H N P 2.2 The theoretical framework
2.2.1 Syntactic definition In our application, we are strictly reasoning in the assembly domain ,4 in which any legal sequence, if represented as an ordered list, is a sequence of all defined task symbols that appear once and only once. This is a symbolic view of a legal sequence that conforms to the assembly domain ,4 globally, as illustrated in Fig. 1 showing examples of a serial and a concurrent legal state sequence and their corresponding symbolic ordered lists for an assembly of three tasks {p~, P2, P3}. Therefore, it is sufficient to specify the model characteristic temporal constraints, with the convention that every task that constitutes the assembly is not done initially and would eventually be executed, once and only once, without having to explicitly state so. (Model characteristic constraints: specific assembly constraints to be satisfied by any L E G A L sequence of a particular assembly for feasibility.) Formally, if f(Pl, P2 . . . . , Pn) is an assembly constraint, where p / i s a task symbol, this implies
I-Af(Pl'P2"'"Pn)=F( ~piA[~piH[-Ipi] ) i = 1 Af(pl,p2,.--
APT6 APT8 APT10
P179P3V P2~P3 I- P3R(P1 V P2) ~-~P379P1A P37~P2 t- P3P(PI A P2) ~ P3PP1 V P37aP2 F- (P1 A P2)79P3~-~P17~P3A P2"PP3 F (PI V P2)~P3 ~
APT15 ~- P2LIP1 ~ I - l ( P 1 V -'P2) APT16 F
P279P1~ <>(~P1AP2)
The 'Precede' operator 7~ is defined (see Ref. 11, p. 163, Table A.1) as
el~P 2 -----~(-~pl/dP2 ) Some general theorems ~1 used include T7 F- I-q(P1 A P2) ~ [--1P1 A [-]P2 T8 b ~(P1 V P:) ~ ~P1 V ~ P 2 The Assembly Process Theorem (APT) numbers given above correspond to those given in Seow and Devanathan. 16 The proofs of these APT properties are provided in Seow and Devanathan) 4'16
2.2.2 Semantics definition
,Pn)
The basic 'Precede' constraint is expressed by
In the assembly domain .4, unless otherwise stated or implied, any assembly property or constraint P is simply written as F P or P instead of ~A p. We also use the convention that PA =f(Pl,P2,.--,Pn)
APT4
if, and only if,
P=(~'PiA[-~PiLtl--]Pi]) Af(pI'p2'''''pn)i=I
pjT~Pk where pj and Pk are assembly task-symbols. Figure 2 shows a semantics generator (automaton) of the basic 'Precede' constraint. This is the basic underlying structure upon which MASS-C is built. To evaluate this basic constraint formula, consider any finite sequence of discrete assembly process states whose tasks include pj and Pk- If this sequence starts in node q0,
Temporal logic programming for assembly sequence planning
257
Table 2. Symbol redefinitions
Symbolic representations in Theoretical framework
PI~°P2 ~P2HPI []-~(State) <>(state/) A V
MASS-C precede (LPI, L_PI) not_until(L_P2, L_P1) always_not(L_State) eve(Lstate/)
traverses along the transitions, and ends in the accepting node q2, represented by a double concentric circle, it is said to satisfy this basic assembly constraint pjT:'pk. In the next section, we present the implementation of MASS-C, a flexible logic programming framework that allows the assembly constraints to be represented as a logic program of the respective temporal predicates. The automaton of the basic element, pflgpk, sufficeS for our implementation because a useful class of assembly constraints can actually be expressed in terms of it using the assembly sequence properties stated under section 2.2.1. 3 IMPLEMENTATION MASS-C is implemented in Quintus PROLOG 9 on the IPC SUN SPARC workstation. Our current implementation contains two main modules. The first module implements a library of temporal operators, applicable in the assembly domain .4, as predicates for logic programming of assembly constraints. The temporal operators and their corresponding logic predicates, as implemented in MASS-C, are shown in Table 2, where L_X is a symbolic prefix list notation for the formula X. The second module contains verification and synthesis predicates. The synthesis predicate in a generator, producing all assembly sequences whose properties conform to the specified assembly constraints. The verification predicate checks and reports if its input sequence satisfies the constraints or not. Interested readers may refer to Appendix 1 for the implementation details of MASS-C.
4 THE LOGIC FRAMEWORK This section presents the basic steps to follow in the logic programming of assembly constraint specification. (1) Write the specification logic program (arbitrarily named as example.pl). (a) Declare all tasks. Use set_of_tasks/1 to declare all tasks for the assembly as a list of task symbols. (b) Specify hard constraints. Use the keyword hard constraint/O as the predicate name to
RING LENS
REFLECTOR
CASE
BATTERY1
BATTERY2
END
Fig. 3. A simple product in exploded view. write the PROLOG program of hard specifications. The body of this predicate can consist of only those temporal predicates whose arguments are instantiated with positive logic formulae of tasks declared in step(a) only. (c) Specify soft constraints. Use the keyword soft_constraint/O as the predicate name to write the PROLOG program of additional specifications. The body of this predicate is written similarly as for hard_constraint. (2) Load MASS-C and the program example.pl. (a) Compile the programs in the interpretive mode: compile (MASS-C); and compile (example). (3) Invoke the respective predicates: (a) Type generate(Seq). All assembly sequences that satisfy the specified constraints would be generated (b) Type verify(seq). A 'yes' or 'no' answer would be output to indicate whether the sequence, seq, satisfies the constraints or not, respectively. For information on the temporal predicates, see Appendix 3.
5 EXAMPLES 5.1 Example 1
A simple assembly as studied by De Mello 17 is used to illustrate the proposed framework. An exploded view of the assembly is shown in Fig. 3. There are notably three distinct assembly tasks to be performed to connect up the product. The symbols representing these tasks and their corresponding component parts are defined as follows: • P1: screw task, connecting CAP and RECEPTACLE; • P2: screw task, connecting RECEPTACLE and HANDLE; • P3: insert task, connecting RECEPTACLE and STICK. We declare all the task-symbols for the assembly by the following fact: set of tasks([pl,p2,p3]). We note that geometrically, the stick must be in the
Kiam Tian Seow, R. Devanathan
258
CAP
STICK
RECEPTACLE
HANDLE
Fig. 4. A flashlight in exploded view. receptacle before both ends are attached. In other words, P3 should be done before both Pl and P2 are done. The model-characteristic hard constraint 7-/4 is 7"/A = p37~(pl Ap2)
Therefore, the hard_constraint/0 is written as precede(p3, [and,pl,p2]). Consider the following soft constraints: (1) 81 = O-'(-,p~ ^ -'P2 ^P3) (2) S 2 = O(-~Pl A -~P3AP2)
,-ql specifies that the discrete process-state (-~pl A "P2 Ap3) must not appear in the sequence. ,-q2 specifies that (-~Pl A -~P3 A P2) must be one of the discrete process states in the sequence. Suppose we want to yield sequences that satisfy both the constraints, i.e. our soft constraints ,.q is given by
8 = 8 1 ^82 Thus, the soft_constraint/0 may be written as
always_not([and,[not and,pl,p2],p3]),/* Sl* / eve([and,[not and,pl,p3],p2]). /* ,S2 */ After successfully compiling the programs in the Quintus PROLOG interpretive mode, we can synthesise or verify the sequences by simply invoking the respective predicates. To synthesise, type generate(Seq), and press <
In our example, only one serial sequence satisfies the constraints. Suppose we want to check if the concurrent sequence [[p2,p3],pl] satisfies the specified constraints. Type verify([[p2,p3],pl]), and press << Enter >>. The PROLOG interpreter returns the answer: no This means that the input sequence does not satisfy the constraints.
5.2 Example 2 The second example uses a flashlight assembly as studied by De Mello. 17 An exploded view of the assembly is shown in Fig. 4. This more practical
example illustrates that MASS-C is capable of selecting the assembly sequences from a large space of geometrically feasible sequences, based on the specified assembly constraint formulae, thereby relieving the designer of the tedium of manually working out all the desired possibilities. There are six distinct assembly tasks to be performed to connect up the product. The symbols representing these tasks and their corresponding component parts are defined as follows: • Pl: force-fit task, connecting RING and LENS; • P2: screw task, connecting BULB and REFLECTOR; • P3: screw task, connecting RING and CASE; • Pd: place-on task, connecting REFLECTOR and CASE; • P5: insert task, connecting BATTERIES and CASE; • P6: screw task, connecting END and CASE. We declare all the task-symbols for the assembly by the following fact: set of tasks([pl,p2,p3,pd,p5,p6]). By geometric reasoning, the hard_constraint/0 is: hard constraint: precede(p5,[and,p4,p6]), precede([and,pl,p2,pd]),p3). The soft_constraint/0 for some (user-identified) soft constraints is: soft_constraint:precede([and,p5,p6], [or,pl,p2,p3,pd]), precede(p2,pd), always_not([ and, [not_and,p3,pd,p6], [and,pl,p2,p5]]), eve([ and, [not,p3], [and,pl,p2,pd,p5,p6]]), not_until(p 1,p2). To synthesize, type generate(Seq), and press << Enter >>. The PROLOG interpreter returns the serial sequence: Seq = Seq = Seq = Seq =
[p5,p6,p2,pl,pd,p3] [p5,p6,p2,pd,pl,p3] [p6,pS,p2,pl,pd,p3] [p6,pS,p2,pd,pl,p3]
no
In this example, four serial sequences satisfy the constraints. Suppose we want to check if the concurrent sequence [[p6,p5] ,p2, [pl,pd],p3] satisfies the specified constraints. Type verify([[p6,pS],p2, [pl,pd],p3]). and press << Enter >>. The PROLOG interpreter returns the answer: yes This means that the input sequence satisfies the constraints. It should be noted that in the two examples above,
Temporal logic programming for assembly sequence planning
259
Table 3. Various proposed representations of assembly task precedence No.
1 2
Symbolic representations as used in Proposed framework
Huang 2
De Mello 2°
Ayoub 3, Fox 18
pl"Pp2 -~p2blPl
MP(pl,P2) NL(pl ,P2)
Pl < P 2 Pl -( P2
Pl < P 2 --
although a 'yes' or 'no' answer may not be exactly what the designer expects from an assembly sequence planning system, that is what the current verifier is designed for. A more fully developed MASS-C should keep track of the constraints that are satisfied or violated. These would be output via an 'explanation' window interface if requested.
6 DISCUSSION A representation scheme is considered complete if it has the ability to represent disjunctive ordering constraints, thereby encompassing the set of all assembly sequences. It can be easily shown that the proposed framework, by its logical formalism including disjunction (logical 'OR'), is complete. In the rest of the discussion, we highlight that the main strengths of the proposed framework for assembly sequence planning, over previous work, 2'3'17-1°9 lie in its precise formalism, temporal expressiveness and analytical (i.e. mechanical manipulation) capability. Existing complete schemes are limited to at most two operators (see Table 3, where element no. 1 indicates that task Pl must precede task P2, and element no. 2 indicates that Pl must precede or be simultaneous with task P2)- The richer set of temporal operators that the proposed framework offers allows an easier and more direct way of specifying the assembly constraints. Take for instance, under section 5.1, we see that 82 directly specifies that the assembly process state described by the state-formula (~Pl A ~P3 A P2) is an eventual state of the sequence. If any of the existing schemes such as Huang 2 is used, such a constraint can only be indirectly specified as MP (P2,Pl Vp3). This is certainly not a natural and an easy way of specifying a desired assembly state. Such a limitation is magnified in a larger state problem than the simple example, when expressing one or more desirable state formulae in terms of the M P 0 predicate becomes obviously cumbersome. In the proposed framework, property APT16 allows the equivalent precedence constraint to be directly derived from the desired assembly process state. This means that the framework actually provides a flexible means to specify and analyse the precedence relationships among the assembly tasks involved. A similar reasoning using property APT15 argues for the Always [] operator as used in $1. The definition of the 'Precede' element as a state transition diagram, as shown in Huang (Ref. 2, p. 221),
De Fazio 19
Pl ~ P 2 --
is not precise enough as to provide the basis for automatic generation of assembly sequences by computer software implementation. Using the formalism of temporal logic, the 'Precede' element corresponds to an automaton as shown in Fig. 2. Together with some rigorously derived algebraic properties shown under section 2.2.1, they form a formal and precise foundation for the implementation of MASS-C for automatic analysis of assembly sequences. De Mello and Sanderson 2° have proposed a representation based on the 'AND/OR' graph. However, the conclusion of De Mello and Sanderson 4 indicates that there is a current lack of mechanical manipulation on 'AND/OR' graph. As a result, temporal constraints such as the soft constraints S under section 5.1, arising from many other specific criteria, cannot be easily and directly incorporated for qualitative analysis. In the 'AND/OR' graph representation, there is no equivalent inference mechanism to select all the conforming assembly sequences as demonstrated under section 5.1. A detailed discussion and comparison with existing representations may be found in Scow. 21 7 CONCLUSION A temporal logic framework is proposed for specifying and analyzing mechanical assembly sequences. Propositional temporal logic of Manna and Pneuli is the assertion language for representing and analysing all constraints or conditions that assembly sequences must satisfy. Based on the defined temporal framework, we show how a simplified programming framework, MASS-C, is implemented to support assembly sequence planning as an automated temporal constraint-based design. MASS-C is developed with the philosophy that such planning can be done by first acquiring and formulating the assembly constraints for a given mechanical assembly. Two examples demonstrate the automatic verification and synthesis of assembly sequences that satisfy the formulated assembly constraints composed as a logic program. The main objective of our implementation is to show the feasibility of automatic verification and synthesis based on the formal support of our defined theoretical framework. A full-scale implementation would include many CAD and expert features, some of which are listed below. • A multi-window user-interface for effective on-line evaluation of the effects of different constraints on the available sequences.
260
Kiam Tian Scow, R. Devanathan
• A facility to check for and explain possible conflicting assembly constraints between the hard and soft specifications. • A graphics interface to visualise assembly sequences, as a state-graph, for example.
ACKNOWLEDGEMENTS The authors thank the anonymous referees for their comments.
REFERENCES 1. Sanderson, A. C., De Mello, L. S. H. & Zhang, H., Assembly sequence planning. Artificial Intelligence Magazine, 11(1) (1990) 62-81. 2. Huang Y. F. & Lee, C. S. G., Precedence knowledge in feature mating operation assembly planning. In Proceedings of the IEEE "International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1989, pp. 216-21. 3. Ayoub, R. G. & Doty, K. L., A representation for discrete assembly sequences in task planning. Proceedings of the IEEE 13th Annual International Computer Software and Applications Conference, IEEE Computer Society, Washington, DC, 1989, pp. 746-53. 4. De Mello L. S. H. & Sanderson, A. C., And/or graph representation of assembly plans. IEEE Trans. Robotics Automation, 6(2) (1990) 188-99. 5. De Mello, L. S. H. & Sanderson, A. C., Evaluation and selection of assembly plans. In Proceedings of the IEEE International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1990, pp. 1588-93. 6 Baldwin, D. F., Abell, T. E., Lui, M. C. M., De Fazio, T. L. & Whitney, D. E., An integrated computer-aid for generating and evaluating assembly sequences for mechanical products. IEEE Trans. Robotics Automation, 7(1) (1991) 78-84. 7. Abell, T. E., An interactive software tool for editing and evaluating mechanical assembly sequences based on fixturing and orientation requirements. Master's thesis, Mechanical Engineering, MIT, MA, USA, 1989. 8. Delchambre, A., A pragmatic approach to computer-aided assembly planning. In Proceedings of the IEEE International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1990, pp. 1600-5. 9. Quinus Corporation, an Intergraph Corporation, Quintus Prolog Release 3.1.1 for the SUN 3/4, II: Language and Library Manual, February 1991. 10. Manna, Z. & Pneuli, A., A temporal proof system. Foundations of Computer Science IV, Distributed Systems: Part 2, Semantics and Logic, eds J. de Bakker & J. V. Leeuwen. Mathematical Centre Tracts I59, Amsterdam, The Netherlands, 1983, pp. 163-255. 11. Ostroff, J. S., Appendix A: Formal overview of temporal logic and Appendix B: Temporal logic theorems and rules. Temporal logic for Real Time Systems, Research Studies Press Ltd, John Wiley & Sons Inc., New York, USA, 1989, pp. 155-71, 172-83. 12. Clarke, E. M., Brown, M. C., Emerson, E. A. & Sistla, A. P., Using temporal logic for automatic verification of finite state systems. Logics and Models of Concurrent Systems
(NATO ASI series, Vol. F13), ed. K. Apt. Springer Verlag, Berlin, Heidelberg, Germany, 1985, pp. 3-26. 13. Whitney, D. E., et al., Computer-Aided Design of Flexible Assembly Systems (First and Final Reports, Report No: CDSL-R-1947 and CDSL-R-2033). C.S. Draper Laboratory, Inc., Cambridge, MA, USA. 14. Scow, K. T. & Devanathan, R., Temporal logic formulation of assembly sequence properties. In Proceedings of the IEEE International Conference on Robotics and Automation, IEEE Computer Society, Los Alamitos, CA, 1992, pp. 1208-13. 15. Ross, K. A. & Wright, C. R. B., Discrete Mathematics (2nd edn). Prentice Hall, Inc. Englewood Cliffs, NJ, USA, 1988. 16. Scow, K. T. & Devanathan, R., A temporal logic framework for assembly sequence planning. In Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems, IEEE Computer Society, Picataway, NJ, 1992. 17. De Mello, L. S. H., Task sequence planning for robotic assembly. PhD thesis, Electrical and Computer Engineering, Carnegie-Mellon University, 1989. 18. Fox, B. R., A representation for serial robotic tasks. PhD thesis, Computer Science, University of Missouri-Rolla, 1987. 19. De Fazio, T. L. & Whitney, D. E., Simplified generation of all mechanical assembly sequences. IEEE J. Robotics Automation, RA-3(6) (1987) 640-58. (Also, corrections: IEEE J. Robotics Automation, RA-4(6) (1988) 705-708. 20. De Mello, L. S. H. & Sanderson, A. C., Representations of mechanical assembly sequences. IEEE Trans. Robotics Automation, 7(2) (1991) 211-27. 21. Scow, K. T., Robotic-task sequence representation and analysis. Master of Engineering Thesis, School of Electrical and Electronic Engineering, Nanyang Technological University, Singapore, June 1992. 22. Bharath, R., PROLOG: Sophisticated Applications in Artificial Intelligence (lst edn). Windcrest Books, Blue Ridge Summit, PA, 1989.
APPENDIX 1: IMPLEMENTATION DETAILS OF MASS-C AI.1 The library module The programming technique called recursion 22 is the basic design strategy used. Lists are a natural form of data structure for recursive programs. Therefore, we use the list structure to represent the explicit assembly sequences, both serial and parallel, as well as the assembly process task formula in prefix list form. As an ordered list o f tasks, a parallel or concurrent sequence has at least one member which is a list subset containing two or more task symbols, representing task concurrency. A serial sequence is just an ordered list whose members are single task symbols. AI.I.1 The "Precede' operator 79 This section presents the description of the semantics interpretation in fig. 2 in P R O L O G , and shows how to check for sequence satisfiability for the basic and general 'Precede' constraint expressions. Fig. AI.1 shows an implementation structure of Fig. 2, from the symbolic
Temporal logic programming for assembly sequence planning
~ ~\
P ~=pj or P ~=Pk orP ~=listwithpjorP k j
'J
P~cpjorP=~Pk orP~=1istwithpjorD K
ant1
o
wit,outC~1 P = 13 or P == llSt and Pj
Fig. AI.1. Implementation structure for the semantics generator of F-Apj79Pk. P is a transition variable (can be instantiated with a task-symbol or symbolic list). The list in each state indicates only the DONE status of the two tasks, pj and Pk. point of view. The task symbol or list of task symbols that can be associated with any transition in Figure A 1.1 corresponds to the same transition in Fig. 2 which causes a switch from logic FALSE in the exiting node to logic T R U E in the entering node and henceforth, for the same assembly tasks. Two parts can be identified. (A) The simple state-graph. In this structure, each transition can be instantiated by a member (constant task symbol or task list) of a list representing a possible sequence to be verified. A transition can be instantiated with the member only if it satisfies the associated transition rule. When a transition rule is satisfied, a node transits to another with all the task symbols the former has collected plus the task-symbol or task list instantiating the transition. (B) The recursive control. The sequencing mechanism is apparent in Fig. A1.1 from the starting node q0 indicated by >, and the accepting node q2 indicated by a double concentric circle, that a sequence must, respectively, begin and end in to be considered satisfiable. This recursive mechanism (also termed the basic satisfiability check) successively inputs all the members of a sequence to the simple state graph starting initially from node q0, and checking if the accepting node q2 is reached after the last member has been input. Appendix 2 documents the description of some predicates (jtlist/3, nthO/3, argument_extract~2 and store/l) used in the program development.
(A.1) The simple state graph description: precede~4. In P R O L O G , a state graph may be expressed as a set of rules under the same predicate name. Each rule expresses the condition by which a current state transits to the next state. In our application, our predicate has an additional argument, the variable list of two task symbols of the precede relation. Hence, referring to . AI.1 with j---1 and k - - 2 , the state graph for l~Pp2 may be coded by a four-argument predicate precede(Varlist,Curr_state,Next_state,Transition) as follows:
261
Rule 1: For self-transitions: q0 ~ q0, ql ~ ql and P
q2 ~ q2. (1 a) P is a symbol. precede(Varlist,Curr_state,Next_state,P):isa_symbol(P), not member(P,Varlist), jtlist(Curr_state,[P],Next state),!. (lb) PL is a list. precede(Varlist,Currstate,Next_state,PL):isa list(PL) disjoint(PL),Varlist), jtlist(Curr_state,PL,Next state),!. Rule 2: for transition: q0 ~ ql. (2a) P1 is a symbol. precede(Varlist,Currstate,Next_state,P1):isa_symbol(P1), nth0(0,Varlist,P1), nth0(l,Varlist,P2), not member(P1,Currstate), not member(P2,Curr_state), jtlist(Curr_state,[P1],Next_state),!. (2b) PL1 is a list. precede(Varlist,Curr._state,Next_state,PL 1):isa_list(PL 1), nth0(0,Varlist,P 1), member(P1,PL1), nth0(1,Varlist,P2), not member(P2, Curr_state), not member(P2,Cur_state), not member( P2,PL l ),
jtlist( Curr_state,P L1,Next_state ),!. Rule 3: For transition: ql ~ q2. (3a) P2 is a symbol. precede(Varlist,Curr_state,Next_state,P2):isa_symbol(P2), nth0(0,Varlist,P1), member(P 1,Curr state), nth0(1,Varlist,P2), not member (P2, Curr_state), jtlist(Currstate,[P2],Next_state),!. (3b) PL2 is a list. precede(Varlist,Curr state,Next_state,PL2):isa_list(PL2), nth0(0,Varlist,P1), member(P1,Curr_state), not member( P1,PL2), nth0(l,Varlist,P2),
member(P2,PL2), not member(P2,Currstate),
jtlist( Curr_state,P L2,Next_state ),!. (B.1) Basic satisfiability check: basic_precede_seq_ check~3. Conceptually, this checking mechanism is built on top of precede/4 as it recursively invokes precede/4 to verify if
262
Kiam Tian Seow, R. Devanathan
an input task or task list of a sequence satisfies the basic precedence constraint starting from a given current state. This predicate may be coded by a three-argument predicate basic_ precede_seq_check(Varlist,Curr_state, Input seq) as follows: • The boundary case basic_precede_seq_check(Varlist,Curr_state, [] ):subset(Varlist,Curr_state),!. • The recursive control basic_ precede_seq check(Varlist,Curr_state, [HITail]):precede(Varlist,Curr_state,Next_state,H), basic_ precede_seq_check(Varlist,Next_state,Tail). The implemented mechanism works this way: The whole input legal sequence (input_seq), starting from an initialised state Curr_state, is 'cycled' through the states via basic_precede seq_check/3 recursively channeling the 'Head' of the remaining sequence to precede/4. The input sequence satisfies the precede constraint if all successive 'Heads' succeed the precede/ 4 predicate, and, as dictated in the boundary case, Curr_state is in the accepting node after the arrival of the last member of the sequence. General satisfiability check." precede/2 This two-argument precede predicate is one of the assembly temporal operators for the logic programming of assembly constraints. Like the other operators that would follow, it is implemented in such a way that the satisfiability check is transparent to the designer. The arguments are process task formulae represented in prefix list notation. Conceptually, precede/2, which can support the more general positive logic expressions involving the precede operator P, is built on top of basic_ precede_seq _check/ 3. The boundary case of precede/2 initialises the argument Curr_state of basic_precede_seq_check/3 to an empty list (meaning no task is done initially), and is given by precede(Argl,Arg2):isa_symbol(Argl), isa_symbol(Arg2), sequence(Seq), basic_ precede_seq check([Arg 1,Arg2],[ ],Seq),!. The derived assembly sequence properties (or rules) provide the formal basis for the implementation of the control mechanism. The prefix list notation used for the task formulae facilitates parsing. Hence, we have
By APT4: precede([or [Orhst],Arg2):equal(Orlist,[Task 1I_ ]), precede(Taskl,Arg2),!. precede([orlOrlist],Arg2):equal(Orlist,[_[Rest]), precede([or )Rest],Arg2), !. By APT 6: precede(Argl,[orL[Arg2]]):precede(Argl,Arg2),!. precede(Argl,[orlOrlist]):equal(Orlist,[Task 11Rest]), precede(Argl,Task), precede(Argl,[orlRest]),!. By APT 8: precede(Arg 1,[andlAndlist]):equal(Andlist,[Task 1I_ ]), precede(Argl,Taskl),!. precede(Argl,[andlAndlist]):equal(Andlist,[_lRest]), precede(Argl,[andIRest]),!. Al.l.2 The other temporal operators In the context of assembly, the other three temporal operators Until L/, Always [] and Eventually O can be easily implemented by directly coding some related assembly sequence properties. Hence, we have By definition for 'Precede' operator." not_until(Argl,Arg2):not precede(Argl,Arg2),!. By APT15: always_not([and,Neg list,Arg2]):argument_extract([-Neg_list,Arg 1), not_until(Arg2,Argl),!. By/'7: always_not([or h[[and, Neg_list ,Arg2]]]):argument_extract(Neg_list,Arg l), not_until(Arg2,Argl),!. always_not([orlOrasm_states]):equal(Or_asm_states,[Asm_statel Rest]), always_not(Asm state), always_not([or IRest]), !.
By APTIO: precede([andl[Argl]],Arg2):precede(Argl,Arg2),!.
By APT16: eve([and,Neg_list,Arg2]):argument_extract(Neg_list,Argl), precede(Arg2,Agl),!.
precede([andlAndlist],Arg2):equal(Andlist,[Task 1 IRest]), precede(Task l,Arg2), precede([andlRest],Arg2),!.
By TS: eve([or IOr_asm_states] ):equal(Or_asm_states,[Asm_statel_ ]), eve(Asm_state),!.
Temporal logic programming for assembly sequence planning eve([orlOr_asm_states]):equal(Or_asm_states,[_lRest]), eve([orlRest]),!.
263
appears in the sequence, once and only once.
APPENDIX 2: SUPPORTING PREDICATES
A1.2 The verification and synthesis module
A1.2.1 The synthesis predicate This predicate is implemented using the generate and test method. Essentially, it comprises two sub-modules, the guessing and checking predicates. The guessing module generates every solution (legal sequence) that is verified by the checking module. Here, the process_seq_generate/1 predicate plays the role of the guessing module while the specification/0 predicate plays the role of the checking module. The program is written as follows: generate(Seq):process_seq _generate(Seq), store(Seq), specification. PROLOG provides the backtracking mechanism by which every legal serial assembly sequence, represented as a list, is permutatively generated by the process_seq_generate/1 predicate using the list of all tasks declared in the set of tasks/1 predicate. Each sequence is then checked against the assembly constraints by the specification/0 predicate. Only the sequences that satisfy the constraints are accepted and output. The specification predicate is defined by specification:hard_constraint, soft constraint. Keeping the hard and soft constraints separate facilitates the more frequent modification to the soft_constraint/0 predicate. This helps to analyse and evaluate the effects of different soft constraints on the available sequences, which are determined by the hard_constraint/0 predicate.
(1) jlist(Listl, List2, List3): combines two lists Listl and List2 to form a joint list List3. (2) nthO(n, List, Elem): is true when Elem is the Nth element of the list List, counting the first as element 0. (3) argument_extract(NList, List): removes all the 'Negation' connectives ('not' or 'not_and') from list NList. The extracted argument, logically negated, is returned in list List. (4) store(List): deletes the previous sequence(_) and asserts the sequence(List) clause in the (top) first position in its predicate.
APPENDIX 3: ASSEMBLY CONSTRAINT LOGIC PROGRAMMING
A3.1 Available specification predicates
(A ) Auxiliary predicate: (1) set_of_tasks(List) ~ to declare all assembly task symbols in the List.
( B) Temporal predicates: (1) precede(Argl,Arg2) ~ to state that Argl precedes Arg2. (2) not_until(Arg2,Argl) ~ to state that Arg2 is not true or done until Argl has become true. (3) always_not(Arg) ~ to state that Arg is a list of infeasible assembly states. (4) eve(Arg) ~ to state that Arg is a list of feasible assembly states.
A3.2 Available specification predicate arguments
A1.2.2 The verification predicate This predicate is written similarly. The only difference is the use of process_axiom_check/1 predicate instead of process_seq_generate/1. The program is as follows: verify(Seq):process_axiom__check(Seq), store(Seq), specification. Note that process_seq__generate/1 enumerates only legal serial sequences whereas process_axiom_check/1 verifies if its input sequence, which can also be concurrent, is legal, that is, every assembly task defined for the given assembly, as declared in set of tasks/1 predicate,
(i) Argl and Arg2 are positive propositional logic formulae of assembly tasks in prefix list or single symbol notation. (2) Arg is a positive propositional logic formula in the prefix form: [orl Or_.asm states], where each member State or Or_asm_states is of the form: (a) [and,[not,Argl],Arg2] or (b) [and,[not_andfArg_list],Arg2], such that: Argl = [orlArg_list] In the simplest case, Arg = State.