1.5 A COMPUTER BASED BOOLEAN DESIGN REPRESENTATIONFirst, while the scope of operators is clearly defined in Boolean algebra, they can be somewhat confusing to comprehend. The problem of changing operator scope will require that any computer program understand the rules for their application. This would require some form of complex algorithm to determine operator scope before the simplest operation could be performed. To simplify this problem a Nested Boolean form is adopted which is very scope specific, similar to that used in Woo[1977]. This form puts each operator in a set of brackets. As in normal algebra, nested terms in brackets must be performed first. This method does not in any way restrict the use of any of the Boolean operators, but removes any question of ambiguity in interpretation. A detailed discussion will follow, but an example of this is, ( + ( * A B ) ( * A ( ~ C ) ) ) (3.2) While the first equation above would require some interpretation as to order, the second form specifies that the NOT operation, and the AND operations must be performed before the OR operation. The only addition is the generous use of brackets, and the collection of an operator over a list of terms. In a more logical form the equality of both representations may be shown by first considering the premise that precedence of operations in an expression is directly based upon either conventions of priority for operations, or precedence that is clearly indicated by bracketed terms. Therefore, when considering the conventional precedence of operators, a high priority operator would be forced to occur first, as if it were in brackets. When brackets are used anyway, they duplicate the brackets in the Nested Boolean representation. Secondly, because of the nature of design, we would attempt to economize on effort by reusing terms, and sets. As is seen in the expression above (3.2), A is reused in the same equation. Say for example that A is a common screw. In the equation above it would be used twice. The problem arises in that the set that defines the geometry of the screw, also defines attributes such as position. In the representation above, both of the screws would overlap in space. This assertion is obviously nonsense, so to overcome it, enhancements were added to the equations. These come in the form of attribute sets that may be appended to any symbol, or term in an equation. An example is seen below, ( + ( * A;move_to_B B ) ( * A;Fixture ( ~ C );Move_to_A );Move_to_spot ) In this case some terms and symbols have been augmented with additional property sets that effectively become part of the original set. Therefore in this case we have defined only one A, but after adding ‘move_to_B’ to one, and ‘Move_to_A’ to the other, they now become separate, and individual sets. This starts to explore the subtle differences of equations of sets to be discussed later. Thirdly, the exclusive use of Boolean operators is not realistic here because of the use of sets, and the irrationality of product representation. Therefore the Boolean operators have been supplemented with some other operators and constraints. As discussed before, assemblies are difficult to model within one solid model. As a result we use the assembly operator used in many solid modelers. This allows parts which may overlap in a geometrical model (e.g., a press fit) to coexist separately. This also allows the designer to specify when an assembly is actually desired. 1.5.1 A File Format for Product DescriptionWhile the mathematical descriptions in the previous section outlined the theoretical model of the product, it was necessary to describe the part in some file format for verification of the method, and for other stages of testing. The file format chosen was a text format, which would allow easy editing and verification. A sample of the file format is shown in Figure 1.5 A Sample File Defining a Part. Within the file the sets are defined by giving the set name, and then a list of properties, delimited by the ‘{‘ and ‘}’ brackets. All of the properties are arbitrary, except for the ‘EQUATION’ property. The purpose of the ‘EQUATION’ property is to indicate how other sets combine into this one. This format has been left particularly loose, so as to not restrict future development. The problems with fixed fields are emphasized by the number of special cases required for small differences, as can be seen in vonRimscha [1989]. One potential problem that could result from the free form representation is the inadvertent creation of a recursive reference for a child to a parent, which is physically impossible. Within my thesis I will use a few properties that can be considered standard, such as ‘translate_y’. Most of the attributes will be easy to identify from their name only. The selection of properties should be done on an application specific basis. A readily available example of this is, that by choosing ‘translate_y’ we assume all coordinates are Cartesian, whereas we may have a robotics based design which considers cylindrical coordinates the norm, such as ‘translate_r’. A number of properties have been identified in other work that must be stored in addition to the basic solid model for completeness. Some of these other properties are tolerances and material [Braid, 1986]. The file below is one of the test files used to verify the software written. It depicts a nut and bolt assembly (as indicated by the ‘main’ classifier). Notably, this set only contains an equation. In a practical use this would probably contain some information from the designer. The expression contains a Boolean equation that refers to ‘nut’, and to ‘bolt’. And, the set ‘bolt’ is modified by adding ‘move_to_hole’. The ‘move_to_hole’ set is now appended onto the ‘bolt’ set for the assembly operation. EQUATION: ( + C ( & D;test1 ( ~ E ) ) A Sample File Defining a Part (cont’d)This particular structure can be of use because the process planner in not just receiving geometry, but also some insight to the designers methodology. For example, the assembly of the nut and bolt in a traditional solid model would just be two separate non-overlapping geometries. In this model we can clearly (and easily) identify the two separate parts that are assembled. The file format not only represents the final geometry, but the designer’s perceptions of the design. When the file format is loaded it can be easily interpreted into a Boolean equation. The example below uses substitution to expand the equation in the main set to a final geometric description. ( : nut bolt;move_to_hole ) (3.3) ( : ( & A ( ~ B ) ) bolt;move_to_hole ) (3.4) ( : ( & A ( ~ B ) ) ( + C ( & D;test1 ( ~ E ) ) );move_to_hole ) (3.5) The final equation is of the type that can be used to drive a solid modeler. The figure below was automatically generated from the ‘nut_and_bolt’ file above, and coincidently also helped verify the correctness of the low level boolean algebra routines. 
(modelled rendered using ACIS [Spatial Technology, 1991]) The representation here was developed to facilitate testing of the system. In review it is safe to say that this system could eventually benefit by the incorporation of a more formal language structure, such as that of PDL [H. A. ElMaraghy, 1991], or ALPS [Mantyla, 1993]. |