Abstract. A hybrid symbolic-numeric system, referred to as OPTDEX, (Optimal Design Expert) for the optimal design of mechanical components and systems has ...
Engineering with Computers 2, 111-123 (1987)
9 Springcr-Verlag New York Inc. 1987
Interacrve Hybrid (Symbolic-Numeric) System Approach to Near Optimal Design of Mechanio_l Components Wei-Hua Chieng and David A . Hoeltzel The Department of Mechanical Engineering, Columbia University, New York, New York 10027
Abstract. A hybrid symbolic-numeric system, referred to as OPTDEX, (Optimal Design Expert) for the optimal design of mechanical components and systems has been developed. The system is written in Golden Common LISP and IBM Professional (Ryan-McFarland) FORTRAN for execution on the IBM PC/AT microcomputer. Graphical output has been implemented using the Graphical Kernal System (GKS) standard. This microcomputer-based implementation makes the system particularly attractive as an easily accessible, low-cost engineering analysis and design tool. Experience with the system indicates that the time required to achieve, at least partially optimized engineering design solutions, is similar to that which may be expected with standard, nonoptimization-based microcomputer computation. Any added computational time may be justified and subsequently offset by increased long-term design efficacy. The OPTDEX protocol (Fig. 1) assumes a modular form, whereby each level can be modified, updated, and enhanced independently of the others to accommodate various design philosophies and the subdivision of large-scale design problems. A "design cell" approach has been adopted that has the capability of addressing the design of various mechanical components and systems. The current version of the OPTDEX design cell library, which is undergoing revision and expansion, includes speed reducer, bearing, coupling, and shaft design capabilities. This modular structure and generalized design cell approach, which underlies the OPTDEX system, establishes the basis of a formalized methodology for mechanical engineering design, which may be extended to include other design-related disciplines as well. For example, with the addition of appropriate design cells, the system can be configured for VLSI circuit design in electrical engineering, scheduling, and job routing in industrial engineering, and structural design in civil engineering.
1
Introduction
Presently, optimization in engineering design is an all too underutilized means of achieving significant engineering design refinements. This is primarily Reprint requests: W.-H. Chieng, The Department of Mechanical Engineering, Columbia University, New York, NY 10027.
due to the high level of sophistication required to apply optimization techniques successfully as well as the general lack of availability of easily implementable design optimization codes. In short, an expert is typically required to formulate and guide a design optimization problem through to successful fruition. In an effort to remedy these shortcomings, attempts are being made to simplify the application of nonlinear optimization algorithms in engineering design practice. Recently, a number of investigators from fields such as mechanical engineering, Jha [1]; systems engineering, Betts [2]; and applied mathematics have begun to consider the problem: Artificial Intelligence +
Mechanical Design +
Optimization Method
Hybrid System for Optimized Mechanical Design Although progress in expert systems research has been made in several specialized mechanical design areas such as linkage synthesis [3] and air cylinder analysis [4], a general underlying theory of what an expert system should be within the context of a mechanical design problem remains unresolved by the artificial intelligence-in-design research community. Rasdorf [5] and Brown et al. [6] offer a prototype of routine design and procedures for failure handling. Betts [21 emphasizes the need for a careful interfacing of needs and requirements between optimization algorithms and engineering systems to which these algorithms are applied. It is here, where mismatch between theory and practice occurs, that advances must be made if optimization
112
is to be readily understood, implemented, and applied to real-world design problems. From a systems engineering standpoint, the problem appears to be one of determining an appropriate hierarchy of design, optimization, and artificial intelligence factors for problem formulation as well as the effective generation--implementation-of numerical procedures--algorithms--for problem solution. The OPTDEX system affords a structured approach to engineering design optimization that can span numerous engineering specialties. OPTDEX attempts to simulate the human engineering decision-making process, beginning with symbolic rough estimation, proceeding to advanced estimation, and finally, to numerical evaluation. The system offers a general methodology for design optimization problem formulation and solution. A prototype system has been implemented, based on a framework-like approach to problem reduction, which divides the global design objective into sets of subtasks, aided by both constraint propagation, which maintains the skeleton of the planning process, and the redesign process, which is due to the nonmonotonicity of symbolic estimations and numerical evaluations.
2 Design Optimization The application of optimization methodology to system design can result in remarkable results in both terms of system efficacy and design flexibility. Various computer programs have been specifically developed for the application of nonlinear programming algorithms to engineering design optimization problems. Several of the more widely known and distributed design optimization codes include ADS by Vanderplaats [7]; OPT and BIAS by Gabriele, Root, and Ragsdell [8,9]; and OPTIVAR by Siddall [10]. These programs can be effective in solving design optimization problems, provided the design problem has been properly posed. The basic underlying philosophy of nonlinear programming algorithms, however, is that no one strategy can be relied on to be the best for any given problem. As a result, there is always some complicated best match between problem and optimization strategy [11]. Expert optimizers have the capability to switch from one method to another in an attempt to speed the convergence process. The expertise required to perform this switching can be such that most novice optimizers will find it quite difficult, if
W.-H. Chieng et al.
not impossible, to perform on a timely basis. The EXADS program [12] represents a-beginning in the application of an expert system front end to a general purpose design optimization code. It is in the formulation of problems and selection of methods and strategies that knowledgebased expert systems can speed the design optimization process.
3 Expert Systems An engineering design expert system is one that handles real-world, complex design problems requiring an expert's interpretation and solves these problems using a computer model of expert human reasoning, reaching the same conclusions that the human expert would reach if faced with a comparable problem [13]. If a computer program is to perform a design task in a manner similar to that of an expert, it requires a large amount of knowledge. As a result, such systems must be organized in a structured fashion if confusion is to be avoided and efficiency is to be achieved. Production systems [14] represent a method of organizing expert system programs into three basic groups [15], which include: 1. Factual knowledge. This knowledge represents a specific case which is acquired through dialogue with the system user to establish facts about the current problem. 2. Procedural knowledge. This knowledge is acquired in advance from a domain (engineering design) specialist and forms the foundation of a knowledge base. 3. Control knowledge. This knowledge contains control strategies that enable the system to try alternatives and to deal with failed attempts. The production system approach adopted in the current design optimization system contains a (1) design data base, (2) list of design-oriented production rules, and (3) control schemes for choosing the appropriate design production rules to apply to the data base. An extended application of a frame-based (schema ~) approach is also used as a formalism of knowledge representation, where a frame can be 1 S c h e m a is a large set of facts with variables. For example, an abstract schema is the n a m e given to the predicate calculus version of a s c h e m a , w h e r e a s a concrete schema is the n a m e given to the actual data structure implementation.
Interactive Hybrid System Approach
113
viewed as a stereotypical representation of the concept of any object. Within a conceptual hierarchy, classes of data items share attributes, procedures, and default values (representation of a hierarchical data structure is shown in Fig. 3), whereas procedure invocations are inherited from farther up in the hierarchy.
t
4 Hybrid Systems When numerical--analysis system--and symb o l i c - e x p e r t system--computations are in some way coupled, the resulting program may be classified as a hybrid system or knowledge-based system [16]. Hybrid system approaches are typically found in engineering analysis applications where an expert system is required to set up the data that defines the problem, execute the analysis programs, and retrieve the output results from subsequent evaluation. Design optimization problems are ideally suited for formulation as hybrid problems with a symbolic processor selecting an appropriate optimization method and a numerical processor performing the actual optimization analysis. In fact, the first operational expert systems for applying existing nonlinear programming algorithms to engineering design problems must, of necessity, be hybrid systems [17]. The OPTDEX system operates in this fashion and may be classified as a hybrid system.
~
Top
teve!
~s:sn n ~ n ~ , r O'LDH)
Yesi~,o~I pr~uc~ e quoue _
__~,U
& prlOr'l'~y e,ss49r~en'k
~slgn m~na~r
level r
@
Y'__L i I._~1 c...,,~.,~ t p r f o r ' l ' t y Qssl~rlnefl'l; q~,~.
I
9
nptlP, lZO.'tlOi~ l e v e l desJ~l I.Io,n~geP
Le~rnlng
.@ +"" r
Yes
Vr.~tuQI sIPtch
IF.w~phlcllvll S l'le+no+olr" (G'+L-M)
Fig. 1. Flow control in the OPTDEXsystem
5 Design Methodology in the OPTDEX System OPTDEX is currently configured as a hybrid powertransmission-assembly design framework that emulates the intelligence of a human designer, manages the domain design knowledge, and controls the numerical processing. Based on observations of the problem-solving strategies of the human designer and modeling of the taxonomy and topology of the design process, it appears that design processing is structured, gradually, from the symbolic to the numerical, from a general knowledge representation to a more specific analytical representation. Symbolically, rough design estimations and plans are generated by the toplevel design manager. Due to the propagation of constraints, the design proceeds with advanced design estimations at the cell design level. The advanced design estimates are used either to support or negate the updated plan. Time-consuming nu-
merical evaluations are applied later, at the optimization design level stage, to quantify those estimations numerically. Since numerical optimization processes typically suffer from mathematical limitations (constraints), prenumerical (symbolic) optimization has been employed. When design contradictions occur, due to inaccuracies among estimations, intermediate failure-driven replanning guides the design modification process. The graphics level design manager translates internal machine achievements into explicit graphical representations for user feedback and subsequent evaluation. Learning associated with reasoning, natural language understanding, and pattern recognition generates a cognitive redesign procedure from the machine-user interface. The logical flow of design information and processing within the OPTDEX system contains five major subdivisions (Fig. 1):
114
W.-H. Chieng et al.
(~ct~ve (and qns~ pi Input_petit) b;p*ea pl ~ rlph) (J~ed p~. 200 ~ _ e P F e c ~ p~ v i ~ k ~ O
(~ve
(conemc't pl p~))
(o.chmve bma ~s1~d p l 1000 rpeO (r (sp4.ed p;~ ~:00 r~.m) ))
(end (hos_~ieec'~ P,~ ",eee,,-~-Uoea .'~Q"& 'O~m~_ef.F~'~ pt vibr~'bon)) ))
~.~.. ~ - ~
(sho.~%_conn p l p P - )
(and (cell beeu~m4a~om'l,o~_o~ pl)) (celt be~lnQ (p~tl~_O? p~J) )
~
(.$h~'t_~.onn p l pl+) ~,sho~f'tLconn pP- p~}
(l~nWln9 pl+)
))
ml~"od~"~ot~
Cmld (celt b e ~ , n 9 (~:~sl~_o? pl+))
(F1ndln9 p~-)
(~.d'4eve ~e~lblr" p3 ~po~m.r_Mne_of' p% pE)))
(f1~dk~; p3)
(Plndln9 ( $ 1 ~ c e _ o F . . s p e e d ~ r _ o F
(~ $~por~d
pc- a o o ,,p,o )) = loe~Pln@ t~ ~q~.~r.ed ~% ~
by ~
f'~:tlo~
J
po~on
oe PL
Fledln~ I ~ v ~ v l s ~.d~l'Uon~ ptwlt~n~
J
Fig. 2. Basic planning example in the TLDM using a production system
%
//Gear
// . Speed
~/ ~ reducer ,~
///Bearing ,
.OlO Beltpulley
9
, ,
Hellcat Gears
~ ~
FLat belt •
Speed ch~ngln 9 '
~lver
>f
Single patr Train Planetary
Spur Gears Internal G. Bevel Gears
V-Belt
.
, .
Sp'lra[ Jaw
Square Jaw . ~ O t d h a m C , - - ~ Straight s l o t t e d Coupling ~ " F t e x i b l e C , I ~ Generalized ,~Jaw
Celt man&get
C.
Cross t y p e
~~
shaft
'Ctu•
~
U-Joint
Weiss type
~ S|mpte ~'~ Compound
Straight Spiral Splrold Timing belt Bet• pulley train Single Mult;Iple Single Pair Traditional Modl?led
Remarks '
1. A Inheritance net o? mechanical power transmission Functlon generator
components, 2. The value oF empty a t t r i b u t e - s l o t o? a node Is assigned to be the F i r s t value Found when climbing t h e hler~rchlc~l da•
Fig. 3. Inheritance net for the data base of the cell level design manager (CLDM)
structure,
Interactive Hybrid System Approach
5.1 Top Level Design Manager [TLDM] The key task of this level is the representation of the overall design methodology, taking advantage of a knowledge-based expert system (KBES) approach and formulating design problems heuristically. The TLDM is designed to perform as a planning program based on the knowledge contained within the design rules. Figure 2 depicts a basic planning example that might occur in the TLDM. The knowledge is encoded in the form of antecedent-consequence pairs of IF-THEN rules. An example of these rules may be expressed as follows: RULE_TLDM_01 if ?x is_an out_port has_effect intermittent_motion and ?p is_ a point_in_design_ space directly_connected_with ?x and ?p can_not have_effect intermittent_motion and function: enough_ space_for a_cell clutch in_ between then create_point named +ip add cell clutch to production_queue position function: insert_in_region [(position_of ?x) (position_of ?p) and local_ boundary_ conditions input is ?p and output is ?x (This function drives the inference engine to search the boundary conditions of ?x and ?p, binding it to the local boundary list of clutch +ip) delete the influence intermittent_motion from power_line (input_port ?intermediate_points _list ?x) and store_ protect (need clutch named ?ip) and_of now to begin_of cell_design ( Nomenclature : ?x, ?p are variables, which will be initiated from the fact base. +ip is a new variable, which will be created from the pseudo-assignment process.
Aside from the planning rules, protection and replanning rules are also included. A noteworthy point concerning the data base is data dependency. After the replanning project is complete, the program must delete all relatives of the failed design plan. Data dependency has been implemented using a sequential numbering of plans. Once a data deletion operation occurs, the inference engine can easily search for redundant data and delete it. When the design process passes through the TLDM, it breaks down and propagates the global boundary conditions into local cell boundary conditions which become queries in a production queue for the CLDM. As an example:
! 15
(cell name coupling position (1.2 3.2 4.1) * specified according to user defined origin and units* input_ torque 499 lb-in speed 250 rpm .
.
.
.
.
.
5.2 Cell Level Design Manager [CLDM] The purpose of this level is to represent real-world design problems. This level contains symbolic optimization capabilities, which are based on domain knowledge, for the formation of cells to be designed in an optimal sense. The CLDM is a heuristic search program (Fig. 3) with a hierarchical data structure. As a classical data base management process (noncreative design process), this level concentrates on the optimizing search, for example, choosing the best coupling for the preceding example, in the abstracted domain knowledge space. The problem still remains as to how to evaluate commonsense knowledge. Possible topologies have been suggested by numerous investigators, For example: 1. Certainty factor. The MYCIN [18] program introduced the certainty factor (CF) calculation. Maximizing the CF on disjunction (OR) nodes and minimizing the CF on conjunction (AND) nodes, the overall axiom CFs are evaluated and compared. 2. Fuzzy logic. Zadeh [19] introduced the explanatory data base frame (EDF) to explain and evaluate commonsense knowledge. EDF converts a symbolic existency into a numerical expression so that a comparison between two different axioms could be established. The topology of the updated CLDM version is currently based on the first of t h e s e - - C F evaluat i o n - s i n c e CF topology is much easier to implement than EDF in many cases. For adaptation to more general problems, the implementation of the latter technique (EDF) has been started and will be applied to later versions of OPTDEX.
5.3 Optimization Level Design Manager (OLDM) The optimization level design manager (OLDM) contains existing nonlinear programming algorithms--(mathematical optimization methods--
W.-H. Chieng et al.
116
rig,
4=_~ Fig. 4c
c:ettquetA~deslgn
Power trensMIsslon componen~ design equations data bo.=e
ADs opaClrdz~,tlon ~eaChod exper ~r syi;t eln
~pH'd P e , ~ Eqns Lo~dtng
proces;lzlng controlter
enable
t, equo.tlon ~o.no.geMar.~
ADS slfttlng
Equation
Acquisition Master (EAM~=
d~xta b~se
A. EqulXtlon l.~o.no,ge~en't
Equcxttons;' (xr
L Addition.
~. Iletetlon, 3. HodIFicatlon. B. Equation ga;e R~lntenance
t=l ........ J
,k
Naturat t a n g u a g e ~
Eqns o u ~ J processing
i ~__
I
IF~176176/
I,~e,n~gel~erc~, ~', Hiero.PchK:~l
L
I~sertlon,
/
-
/
Ft9. 4b
pPo@rams
programs
Eqo~176176 m, /
l, Contro.dlctlon
AuXltle.ry
Al~ optllnlZatlon
5
IEx~cu~,on o r
I
2 k
I I~.r*tIv, resu{~
~
For = .pec,e,c I
I. . . .
|
i
Result violation checking [ IL e r r o r sen~ln~ [
.
I
Fig. 4. Schematic of the optimization level design manager (OLDM) including: (a) design equation data base; (b) LISP to FORTRAN compiler; and (c) expert system for convergence criteria and optimization method selection.
that perform the actual numerical optimization for a discrete design. For a specific design problem the program first goes into the design equation data base (Fig. 4a) and searches for all applicable equations. The selection of design equations is based on a hierarchical data structure. The optimization application programs (FORTRAN) require the design objective functions and the design constraints. The design objective is assigned as:
developed for this purpose, using Golden Common LISP (Fig. 4b). After the optimization programs are implemented, the next step is to establish the best optimization method for the problem. In order to avoid exhaustive testing of all possible algorithms (although some optimizers believe that this is necessary), an expert system (Fig. 4c) has to be implemented which judges the convergence criteria and controls the optimization switching process.
OBJ -- Weighting_factor_l * Obj_ 1 + Weighting_factor 2 * Obj_2 + "" + Weighting_factor_n * Obj_n When different objective functions, which might contain evaluations for the stress, manufacturability, and cost are assigned by the user, it is possible to change only the weighting factor of the corresponding design objective. For some available nonlinear programming codes, such as ADS, the programming methodology is quite regular. It is, therefore, a straightforward process to translate the design equations into FORTRAN code. A compiler program (ADSC) has been
( last_strategy is ?x and last_execution exists error) or
(end_of optimizer_testing and end_of_ l-D_search_testing) or not function : improvement_in_the_last_three_test then delete add
updated_strategy ?x updated_strategy function : Next_priority_strategy
Additional information includes rules to judge step length which determine convergence and control the optimization process.
Interactive Hybrid System Approach
5.4 GraphicsLevel Manager (GLM) The graphics level manager (GLM) displays the final result of a design in a standard format. This graphics process differs from general graphics tools in that it is totally controlled by the OPTDEX system, not the user. The GLM contains a data structure typical of that found in finite element programs, that is, a sequential list of X, Y, and Z coordinates that define the boundaries of the mechanical component or system. The GLM acquires parameterized design data, for the specific component, from the design data base, enabling it to plot the component. The GLM then displays both the physical design Space and the component according to three views--top, front, and side--and a hidden line plot. Solid, geometric modeling--a time-consuming graphics representat i o n k i s supported in the newest GLM version. This implementation provides a more realistic final design representation. Dimensional scale factors and component dimensions are also provided. Figure 5 depicts a representative display produced by the GLM. Design sensitivity analysis [20] can also be applied in the GLM as well. The mathematical design search space is interactively observed by plotting local contours. Design sensitivity plots of the objective function versus selected design variables with constraints may be specified by the user to determine which variables play key roles in the optimization process.
5.5 Learning Manager (LM) The capability to understand the designer's suggestions are represented here, since the top level designer only includes rules of thumb that are implemented during the development stage of OPTDEX. For special applications, there may be rules requested by the user that do not currently exist in the data base. The system needs to understand how to perform a new design process in accordance with the user's definition of this new process. In the absence of learning ability, the system can only think as an expert's system and not as an expert system. Design learning, as it appears in the OPTDEX system, differs from the process of pure learning in that the primary user of the system will be a novice (nonexpert). The ability of the LM to acquire
117
knowledge about the design process will, therefore, be limited by the inexperience of the user. Learning can be divided into two parts: The first is failure driven; the second is new concept driven. Failure-driven leaning is triggered by the occurrence of a failure. As a result of this failure, the learning manager (LM) will automatically adjust the rules of the TLDM and retrieve a new path for redesign processing. An example of the new concept learning process might be the successful deign of a power transmission assembly, that is, a design in which no constraints have been violated. The result might appear as:
Input_port
Output_port
However, the user has found that this design is not inertially balanced (left to right) and requests a balanced design. If this is a failure-driven learning mechanism, then, based on the fact that the LM holds no failure rules for an unbalanced design, appropriate action cannot be taken. An alternative way of applying concept learning is through "specialization" or "generalization" [21J. When a situation arises involving a novice user, who introduces a new concept, generalization rules will not be produced since the new concept represents new data that is unable to match any data already in the data base. If all negative instances are assigned, then many overspecified rules will be created, permanently affecting some important design rules in a detrimental way. In order to alleviate this problem, the idea of learning authority is suggested, whereby the origin of any new learning concept must be determined. For novice users, the revised rules will only remain in effect temporarily, being automatically erased at the completion of a design session.
6 Design Example Using OPTDEX A design production example that demonstrates processing in the OPTDEX design optimization sys-
118
Chieng et al.
J
I
SubJect : Design_space_input
/%.
Phase I: ~uto Plot; ~-3 : side vieus 4 : hid-line plot Notes : 1.3-])_graphics fo~ KBS sgstem, OPTDEX.
2.demo_91ot 3.scale_factor: 1:17 Radius_of first 9enerated circle
//
!
I
I
is I. in 4. I/0_ponts : InpoPt : (pos O 3 1) (vec 1 8 I~)
out ...poPt: (pos 17 4 3) (vec 1 8 ,S)
,,.
Ph~.~eI I '.Change v i e~s; ~ftee finish l~stplot user specified design_space_and_I/O_requirements
Input shaft
output shaft #2
/
J
/
The physical design space bounded by planar surfaces.
output shaft #1 I/O port specification: Input port: Output_port #1: Output_port #2: motion_type rotary rotary rotary speed: 2400 rpm ccw 80 rpm ccw 400 rpm cw torque: 100 lb-in 2000 ib-in .GE. 220 lb-in position: (1.5, 1.5, 1.5) (12, 15, 1.5) (0, 5.25, 15) unit: in in in vector: (0, 1, 0) (I, 0, 0) (-1, 0, 0) 6. effect: NIL intermittent_motion vibration 7. note: The vector_of in_port points into_design_space, and the_vector_of out_port points out_of space.
1. 2. 3. 4.
TLDM > *specification error** 1. The total output power is greater than that of the input. NIL User response > (spec out_port_l speed 1500 rpm) TLDM > pass specification_checking TLDM > suggestion_request: 1. The speed_reducer near in_port, can user suggest input position_of_it? 2. The speed_reducer is_not near out_port 1 and impossible_connect_them_ directly, can user suggest (p 1) an_intermediate_point? 3. The speed_reducer is_not near out_port 2 and impossible_connect_them_ directly, can user suggest (p 2) an_intermediate_point? NIL
120
W.-H, Chieng et al.
A F TE R USER'S A P P R O P R I A T E A C T I O N S
TLDM > *production-list*: ((cell bearing #1 (pos 1.5 1.5 4.5 unit: in) (speed 2400 unit: rpm) (load radial: 100 thrust: (depend_on speed_reducer #1) unit: lb-in)) (cell bearing #2 (post 12 15 15 unit: in) (speed 80 unit: rpm) (load radial: 1500 thrust: 750 unit: lb-in) (spec_effect intermittent_motion)) (cell speed_reducer #1 (pos center: 6, 3, 3 unit: in) (no ._ of_ output 2) (speed_ratio 30 : 6) (max_speed 2400 unit: rpm) (max_torque 1000 unit: lb-in) (power 4 unit: hp) (efficiency .8) (cost_limit no) (noise_limit no) (shaft offset 6.3 2.7 unit: in) (shaft_misalignment 0 unit: degree) (power density .333 unit: hp/in^3) (axillary_condition no)) (cell coupling #1 (pos 1.5 15 1.5 unit: in) (speed 400 unit: rpm) (torque (> 220) unit: lb-in) (speed_variation default) (cost_limit no) (shaft_misalignment (> 10) unit: degree) (spec_effect vibration)(shaft_offset no)) (cell clutch #1 (pos center 5.25 15 1.5 unit: in) (torque 1500 unit: lb-in) (speed 80 unit: rpm) (power 2 :unit: hp) (noise_limit no) (cost_limit no) (frequency default) (effective_damping_ratio default)) TLDM > pass top_level_design_manager TLDM > go_to cell_level_design_ manager (The system then proceeds to the Cell Level Design Manager {CLDM}, where it provides feedback to the user regarding the (non-generic) selection of components.) CLDM > speed_reducer #1 : the_best_choice is spur_gear train with euclidean distance -30 produce: (thrust_load_of_neighbor_bearing_ no) CLDM > bearing #1 : the_best_choice is radial_contact roller_bearing with euclidean_distance -35 straight roller_bearing with euclidean_distance -35 CLDM > bearing #2: the_best_choice is double_row spherical_roller_bearing with euclidean_distance -10 add_boundary_conditions: (add bearing #2 (material composite_material)) CLDM > coupling #1 9 the_best_choice is universal_joint with euclidean_distance -20 product: (and (not (see_effect ?x vibration)) (shaft_connect ?x coupling #1)) CLDM > clutch #1 : *,~*failed*~* error: not enough_information to_reach a best_choice !!!! At this point the CLDM has failed and the process stops until new boundary conditions are entered. The reason for this "immediate interruption" is that the effect of any changed local boundary conditions will be propagated to all the design components and the old design may not satisfy the new boundary conditions.
Interactive Hybrid System Approach
121
bearing #3
bearing #4 speed_reducer #1 bearing #1
~
coupling #1 bearing #8 speed_reducer #3 (speed-ratio 1) /
/t/
\
bearing #6
\
-
speed_reducer #2 bearing#9
bearing#5
clutch #1
bearing #7
bearing #2
A schematic interpretation of productions from the TLDM.
AFTER APPROPRIATE COMMUNICATION AND MODIFICATIONS C L D M > go_to optimization_level_design_manager O L D M > spur_gear train design_equations: Auther : Steven, Chieng C o m m e n t : Compound gear train, the shafts may carry two or more gears. Objective = W1 * obj_on_space_occupation + W2 * obj_on_cost + N I L 1. obj _ on_ space_ occupation: Length * height * width Definition: Length : minimum space is needed along the x axis.
O L D M > enter values for W1, W2, requirement: W1 + W2 = 1.. User response > (W1 0.75) User response > (W2 0.25) O L D M > (continue) 8 active constraints will be used 1. knowledge domain: statics purpose: H e r t z stress concentration for gear_tooth_surface modeling: two ball_surface contact expression: 0 > o-max - sqrt ((F/7rfcosch) * [ (l/p] + l/p2) E / 2 (l-v2)]) F : tangential_tooth_load unit: N f : pressure_angle unit: radian 2. knowledge domain : kinematics purpose: speed_constraint for bearing lubrication
122
W.-H. Chieng et al.
OLDM > modifications?
User response > no OLDM > (continue) equation_attributes (implicity defined) for establishing_optimization_methods: (function_evaluation_cost (level 8)) !! high (differentiable_ to_ order 1) (nonlinearity (level 7)) !! fairly-high the best_first_method: (ADS (ISTRAT 0) (IOPT 4) (IONED 7)) !! ISTRAT 0: No strategy. IOPT 4: Method of feasible direction. !! IONED 7: Polynomial interpolation for constrained function. OLDM > running spur_gear train design
7
Conclusion
Optimization theory has and will continue to represent an important aspect of engineering design. However, its usefulness depends, to a great extent, on its successful implementation for domain specific problems. The prototype of a mechanical problem solver--OPTDEX--represents an approach to the methodological representation and optimum solution of mechanical design problems. Experience with the OPTDEX system has demonstrated that significant enhancements to the outcome of the design process can be realized with relatively little additional computational effort over that with nonoptimization-based computational design time. Planned refinements/additions to the OPTDEX system include: 1. Advanced learning manager for advanced user instruction 2. Addition of manufacturability (fabrication) and cost (financial) managers 3. Addition of other components and systems 4. More sophisticated optimization level design manager to reduce search time 5. More sophisticated graphics design manager for improved visual function evaluation, design sensitivity, and mechanical system description.
Acknowledgments This research was supported by grants from the IBM and NCR Corporations.
References 1. Jha, N.K. (1985) Engineering optimization and expert systems. In: Proceedings of 1985 ASME International Computers in Engineering Conference, pp. 97-101 2. Betts, J.T. (1983) Frontiers in engineering optimization. ASME J. Mech. Transm. Autom. Des. 105, 151-154 3. Thompson, T.R., Riley, D.R., Erdman, A.G. (1985) An expert systems approach to type synthesis of mechanisms. In: Proceedings of 1985 ASME International Computers in Engineering Conference, pp. 71-75 4. Kumar, A., Kinzel, G.L., Singh, R. (1985) A preliminary expert system for mechanical design. Proceedings of 1985 ASME International Computers Engineering Conference, pp. 29-35 5. Rasdorf, W.J. (1985) Perspectives on knowledge in engineering design. In: Proceedings of 1985 ASME International Computers in Engineering Conference, pp. 249-253 6. Brown, D.C., Chandrasekaran, B. (1984) An expert system for mechanical design: A progress report. In: Proceedings of 1984 ASME International Computers in Engineering Conference, pp. 343-344 7. Vanderplaats, G.N. (1984) ADS--A FORTRAN Program for Automated Design Synthesis. NASA Contract Report 172460 8. Root, R.R., Ragsdell, K.M. (1978) BIAS: A Nonlinear Programming Code in FORTRAN IV--Users Manual. West Lafayette, IN: Purdue Research Foundation 9. Gabriele, G.A., Ragsdell, K.M. (1984) OPT: A Nonlinear Programming Code in FORTRAN 77. Design Optimization Laboratory, University of Missouri, Columbia, MI 10. Siddall, J.N. (1982) OPTIVAR: Designers Optimization Subroutines. McMaster University, Hamilton, Ontario 11. Siddall, J.N. (1982) Optimal Engineering Design: Principles and Applications. Marcel Dekker 12. Rogers, J.L., Barthelemy, J.F. (1985) An expert system for choosing the best combination of options in a general-purpose program for automated design. In: Proceedings of 1985 ASME International Computers in Engineering Conference, pp. 255-260 13. Weiss, S.M., Kulikowski, A.A. (1984) A Practical Guide to Designing Expert Systems. Rowman & Allanheld Publishers
Interactive Hybrid System Approach
14. Nilsson, N.J. (1980) Principles of Artificial Intelligence. Tioga Publishing 15. Forsyth, R. (1984) Expert systems principles and case studies. London: Chapman & Hall
123
18. 19.
16. Zumsteg, J.R., Flaggs, D.L. (1985) Knowledge-based analysis and design for aerospace structures. In: Applications of Knowledge-Based Systems to Engineering Analysis and Design. ASME pub. AD-10, pp. 67-80
20.
17. Papalambros, P.Y. (1986) Knowledge-based systems in optimal design. In Proceedings of NATO/NASA/NSF/USAF
21.
Computer Aided Optimal Design Conference, Vol. 3, pp. 311-363 Shortliffe, E.H. (1976) Computer-Based Medical Consultations: MYCIN. New York: American Elsevier Zadeh, L.A. (1983) Commonsense knowledge representation based on fuzzy logic. IEEE, Comput. October, 61-65 Haug, E.J.; Arora, J.S. (1979) Applied Optimal Design: Mechanical and Structural Systems. New York: Wiley, pp. 164-178 Charniak, E.; McDermott, D. (1985) Introduction to Artificial Intelligence. Reading, MA: Addison-Wesley