2nd-cad a tool for conceptual systems design in electromechanical domain jcise-vargas-2004

8/8/2019 2nd-CAD a Tool for Conceptual Systems Design in Electromechanical Domain JCISE-Vargas-2004

1/9

Noe Vargas-Hernandezemail: [email protected]

Jami J. Shahemail: [email protected]

Design Automation Lab,Mechanical & Aerospace Engineering

Department,Arizona State University,

Tempe, Arizona 85287-6106

2nd-CAD: A Tool for ConceptualSystems Design inElectromechanical DomainThis paper presents a framework and information model for the development of

SECOND-CAD (Systems Engineering CONceptual Design-CAD), or 2nd-CAD, a Com- puter Aided Conceptual Design (CACD) tool for Electromechanical Systems. The concep-tual design tasks supported include functional design, behavior modeling, and component selection from standard industrial supply catalogs for mechanical, uid, and electricengineering domains. 2nd-CAD is composed of three entity catalogs the designer uses tocreate three interconnected structures for function, behavior, and component. The logicalmodel behind 2nd-CAD is one of the major contributions of this research. It allows theuser to dene entities based on popular taxonomies; this eases data exchange with other tools. When constructing structures, only technically feasible relationships are permitted and if an element in a structure is modied, the change is propagated throughout thestructure. It reuses the entities information content to create new structures and since thethree structures are interconnected, changes can be traced for design validation. 2nd-CADs functional requirements, logical design, and physical implementation are discussed in this paper. DOI: 10.1115/1.1683856

1 IntroductionMost of the Computer Aided Design CAD tools available

nowadays focus on embodiment and detail stages of design. Fewtools exist for supporting the conceptual design stage; this is un-fortunate considering that decisions made at this stage have thegreatest inuence on the cost and characteristics of the nal prod-uct 1 . The objective of this research is to present a framework and information model for the development of a rst version of SECOND-CAD Systems Engineering CONceptual Design-CAD , or 2nd-CAD, a Computer Aided Conceptual DesignCACD tool for Electromechanical Systems. The conceptual de-

sign tasks supported include functional design, behavior model-ing, and component selection from standard industrial supplycatalogs for mechanical, uid, and electric engineering domains.Electromechanical systems have become increasingly important ineveryday life since traditional mechanical products now include agrowing number of electric and electronic components examplesrange from washing machines to airplanes . A key characteristicof electromechanical systems is the transformation of energy, ma-terial, and signal to accomplish a technical task; because of this,functional structures are an ideal abstract representation of thesystem requirements. The overall system function is decomposeduntil the subfunctions are simple enough to be designed. The typeof design process needed for the decomposed functions dependson the situation, Shah and Wilson 2 identied four classes of designs: Novel i.e. from rst principles , Evolutionary i.e. modi-fying an existing design , Parametric i.e. following a character-ized design procedure , and Selection i.e. searching standard

components from catalogs . The designed or selected componentshave individual behaviors i.e. responses to inputs that whencombined with other components create synergistic effects thatdene the system behavior 3 ; analysis tools are used to simulatecertain aspects of the system behavior e.g. energy activity, signalprocessing, material transformation . Based on the behavioranalysis results, changes may be needed on the component de-signs or even at the functional structure level. Design validationcan be thought as a three-way dialog between the behavior model,

component system, and functional structure; it ensures the use of feasible components that observe the required behavior and per-form the specied function. Hence, function, behavior, and com-ponent structures provide three complementary aspects of designinformation that are key during the design process. The designprocess can be viewed as a multiple-option sequence of taskswhere design information evolves in successive transformations.Every task transforms knowledge from an initial state i.e. inputto a nal state i.e. output to be used in subsequent tasks 2,4 .The input of conceptual design is a design specication i.e. a listof requirements in technical terms and the output is a concept;however, there is no unique denition for what a concept is, andthe boundary between conceptual and embodiment stage is not

clear-cut. What is invariable in most denitions 1,3 is that aconcept denes key information of the systems design e.g. work-ing principles, material, working geometry, etc. . The transforma-tion from abstract i.e. a design specication to concrete i.e.material, geometry, etc. is what complicates the categorization,representation, analysis, and synthesis of design information. Acommon characteristic of function, behavior, and componentstructures is that they use the same energy, material, and signalows as connections during their analysis. Further, they share sub-sets of information through the synthesis i.e. concretization of the system. Nevertheless, multiple categories exist for functions,behaviors, and components, and although the information may besimilar, its representation is different.

2 State of the Art

Traditionally, designers have performed functional decomposi-tion using paper and pencil or an equivalent sketching computertool . Diagramming tools are used to analyze functional struc-tures, their information representation ranges from drawing ele-ments i.e., lines, points, text, etc. such as in PowerPoint, to ge-neric system modeling tools such as DOME 5 and MetaEdit 6 ,based on meta-model object specications. The main limitation isthat the correctness of the structures entities and connections areresponsibility of the designer. The result can be a functional struc-ture that is inexible i.e., difcult to modify , error prone e.g.containing incorrect connections , difcult to reuse in subsequentdesign tasks i.e. need to be reinterpreted every time , hard toexchange with other tools because of different representations ,

Contributed by the Committee for publication in the J OURNAL OF COMPUTINGAND INFORMATION SCIENCE IN ENGINEERING . Manuscript received July 2003;Revised January 2004. Guest Editors: I. Horvath and D. Rosen.

28 Vol. 4, MARCH 2004 Copyright 2004 by ASME Transactions of the ASME


2/9

and not directly related to other design structures e.g. unrelated tobehavior or component structures . To model the behavior, thedesigner has to reinterpret the functional or component structure;this is difcult since function, behavior, and components are typi-cally independent. Results from the behavior analysis may requirea change in the functional structure; this may be difcult since thebehavior was manually reinterpreted from the functional structureand inter-structure relations may not exist. Various tools exist formodeling the behavior of a system e.g. Matlab 7 , Labview 8 ,Mathcad 9 , Working Model 10 , Symbols2000 11 , Dymola12 , and other multipurpose circuit analysis tools and/or in-house

programs . Behavior modeling tools are based on logical or math-ematical representations of physical phenomena e.g. electrictransformer, mechanical transmissions, hydraulic valves, etc. .Since these physical principles are well established and widelyaccepted, most tools use the same set of basic behaviors. What issometimes different is how these are named e.g. current, amper-age, I and i refer to the same , model visualization i.e. presenta-tion: boxes, icons, diagrams, etc. , utilities for modeling i.e.searching, connecting, modifying, etc. , data format i.e. represen-tation of information , and analysis available e.g. linear solving,optimization capability, advanced solving, etc. . To design a com-ponent, the designer must create a specication i.e. a list of pa-rameters from dispersed and unrelated functional and behaviorinformation. If the component is to be selected, as is the case of 2nd-CAD, the designer can use online search engines such as

McMaster 13 , Grainger 14 , and Thomas Register 15 to nd atting component. Because of their dissimilar information repre-sentations, it is difcult to relate a component structure to a be-havior or functional structure.

Current research in conceptual design can be grouped into threeareas: knowledge representation, analysis, and synthesis. Knowl-edge representation models range from simple categorizations of functions to comprehensive ontologies i.e. denes elements andhow to connect them . Szykman et al. 16 identies two maintypes of representations: Grammatical and mathematical. Gram-matical representations dene functions using verbs and adjec-tives, the natural language resembles the designers language, butit is difcult to implement in a computer tool. Some examples of grammatical representations: Kirschman and Fadel 17 , Lai andWilson 18 , Stone and Wood 19 , and Collins et al. 20 . Math-

ematical representations dene functions in terms of input andoutput variables and their transformations; computational imple-mentation is easier, but it requires translation to the designersnatural language. Some examples of mathematical representa-tions: Pahl and Beitz 1 , Suh 21 , Hubka and Eder 3 , andSzykman et al. 22 . Functional analysis adds a reasoning schemei.e. how to create structures; decomposition to knowledge repre-

sentation either grammatical or mathematical . Kitamura and Mi-zoguchi 23 propose and ontology based description that includesfunctional knowledge i.e. how a function achieves it with whatthey call way of function achievement. Chakrabarti and Bligh24 identied three reasoning approaches: First, each component

is dened by the functions it provides and the ones it needs, ini-tially nding the components that fulll the solution, then, itera-tively solving the components required function 25 . Second, theparadigm model 26 compares functional requirements against asolution in terms of desired attributes; identies wrong compo-nents that make solution unsatisfactory and iteratively renesthem. Third, the systematic approach uses solution neutral func-tions, decomposing until functions are realizable 1 . Functionalsynthesis has the objective of concretizing the functional modelinto a component i.e. device, artifact, part, form or geometryand/or behavior. Horvath et al. 27 provide a formal methodologyfor the development of ontologies for modeling concepts. Chakra-barti and Tang 28 present a tool called FucnSION that uses adatabase of functional elements to provide an exhaustive set of solution concepts to synthesize the functional requirements. Bradyand Juster 29 propose a Conceptual Design Tool CDT for as-

semblies that use a functional structure as an input and describespartial geometry in terms of abstract geometry. Zhang et al. 30presents a knowledge base for conceptual synthesis where aphysical behavior can be derived from a desired function or be-havior and a causal relation can be established between functionsand behaviors. From the state of the art it can be concluded that noCACD tool exists capable of a continuous representation of de-sign information during conceptual design. This has various con-sequences: Design information is seldom reused; instead it is re-interpreted at each step. The propagation of changes is a complextask, mostly on the hands of the designer. Design validation can

be difcult since there is no direct relation between components,behaviors, and functions. The capture of the design history for themost part is neither enforced nor supported. Data exchange iscomplicated by the variety of knowledge representations andcategorizations.

3 Functional Requirements for 2nd-CADThe fundamental reason for the problems with current CACD

tools is the variety of approaches for categorization, representa-tion, analysis, and synthesis during conceptual design. These is-sues were taken into consideration in the development of 2nd-CAD; the principle is to use research work done in categorization,representation, analysis, and synthesis. The objective of the 2nd-CAD is to provide the user with catalogs of elements to createinterconnected multilayered structures of functions, behaviors,

and components. 2nd-CAD must capture design intent, easechange of propagation, promote information reuse, allow data ex-change, preserve design history, maintain technical feasibility of the design, and permit design validation. Central to 2nd-CAD arethe catalogs and structures. The catalogs elements i.e. function,behavior, and component must be modeled in a manner that ac-commodates elements from existing categorizations as well asuser-dened entries, in order to achieve this, the entity modelsmust be standardized i.e. able to represent existing categoriza-tions and integrated i.e. have a common information content .The structure must be modeled in a way that only allows techni-cally feasible connections avoiding strict rules, that limit the de-signer unnecessarily, and eliminating lax rules, that can make of 2nd-CAD an equivalent of a diagram-sketching implementation.The information content of the structures must allow the reuse of information when deriving a new structure e.g. reuse the functionstructure to create a model behavior , and the exchange of data tobe used in downstream applications such as behavior analysis,component synthesis, parametric design, component layout, de-tailed geometry design, etc. 2nd-CAD must offer the user thenecessary functionality to search, view and edit the elements of function, behavior, and component catalogs, and to search, view,edit, connect, and check-in/out of elements in a structure. 2nd-CAD must provide continuous support for the creation of func-tion, behavior, and component structures for the ow of energysignal and material ows can be addressed in the future and for

mechanical, electric, and uid domains. 2nd-CAD must observeappropriate operation i.e. correctness, efciency, etc. , allow re-visions i.e. exibility, scalability, etc. , and support transitionsi.e. portability, interoperability, etc. ; these quality factors will be

discussed in the evaluation section. It is also required that 2nd-CAD have a graphical user interface GUI that is easy to use. Thefundamental issue for the development of 2nd-CAD is the designof an enabling information model that adequately represents thestated requirements 3133 . This is particularly challenging sinceno CACD tool exist with these characteristics.

4 Logical Design of 2nd-CADIn this section, an information model is created based on the

functional requirements of 2nd-CAD described in the previoussection. This information model is used in section 5 as the basisfor the implementation of 2nd-CAD. Since the intention is for theuser to select entities from catalogs to create structures, data mod-

Journal of Computing and Information Science in Engineering MARCH 2004, Vol. 4 29


3/9

els are needed for representing function, behavior, and componententities, and the corresponding transactions necessary to populateand manipulate the catalogs. Data models are also needed forrepresenting connection i.e. ow, composition, and mapping re-lationships, and the corresponding transactions necessary to createand manipulate structures. The modeling strategy is as follows:First, available categorizations of functions, behaviors, and com-ponents are examined. In each case the information represented isanalyzed in order to distill a standardized i.e., general entitymodel capable of representing most of the existing categoriza-tions entities. The obtained entity models function, behavior, andcomponent are compared to dene an integrated information hi-erarchy that can help during design synthesis. The standardizedand integrated entity models are used to create catalogs of basicfunctions, behaviors, and components. Second, the relationshipsneeded to analyze functional structures, behavior models, andcomponent systems, and the relationships needed to interrelatethese structures during synthesis are modeled. In each case, theconnection rules are dened in terms of relationship constraints.The entity and relationship models together with the correspond-ing transactions and constraints dene the logical model of 2nd-CAD.

4.1 Entity Modeling. As explained in the state of the art,various categorizations, representations, analysis, and synthesisapproaches exist for function, behavior, and component modeling;these are treated as follows. The intention is to preserve existingcategorizations; a way to achieve this is through conceptual index-ing 34 which allows the user to dene how to organize theentities based on a view of their information content. With this,existing categorizations can be stored as predened views that theuser can select according to its familiarity or needs. Mathematicalrepresentations are chosen as the primary representation becausethey can unambiguously represent entities in terms of their inputs,outputs, and relationships facilitating with this computational ma-nipulation; grammatical descriptions are included as aliases of theentity. The models for function, behavior, and component are de-ned subsequently.

4.1.1 Function Entity-Relationship Model. Various authorshave proposed different categorizations for functions1,19,22,35,36 ; each typically consists of ve to eight categories

that group functions with common characteristics. These catego-ries are based on the authors particular point of view e.g. indus-trial processes, automated machines, etc. thus creating different

categories for the universe of functions. The common contentamong the various function representations consists of input andoutput ows and transformations as action verbs acting on theows, or as i/o relations ; this is shown in Fig. 1 with an Entity-Relationship model 37 . All authors coincide in dening threetypes of ows: energy, material and signal. Our focus is on theow of energy for mechanical linear and rotational , uid hy-draulic and pneumatic , and electrical AC and DC domains. Al-though the power magnitudes of the ows are not represented, thepower relation same, greater than, etc. and the domain relationi.e. same or different dene the function transformations.

The model in Fig. 1 is used in 2nd-CAD to represent functions.A user of 2nd-CAD can dene a category of functions by speci-

fying the domain and power transformations i.e. relations . Forexample, by dening the input domain different to the output do-main and the input power equal to the output power, the model forPahl and Beitz Change Type category is dened. Other userscan select previously dened function categories from the catalogand instantiate by assigning values to the attributes.

4.1.2 Behavior Entity-Relationship Model. Bond graphs areused instead of domain-specic behavior representations. Bondgraphs represent energy and signal exchanges between compo-nents of technical systems; the representation uses a set of ele-ments connected by energy ows through identiable ports 38 .Bond graph models are more abstract than typical models andprovide a common behavior representation for numerous branches

of engineering such as hydraulics/pneumatics, mechanics, electric/ electronics, and thermodynamics. For example, the Resistanceelement can represent a mechanical load or a hydraulic valve anda Source element can represent an electromechanical motor ora hydrostatic pump. Figure 2 shows an example of a Bond graphrepresentation for an electro mechanical system. The motor is rep-resented by a source S element, the transmission by a trans-former TF element, and the pump as a resistance R element.

The energy ow power P among elements is the product of two variables: effort e and ow f ; this is similar to the energyexchange seen in atomic chemical bonds, hence the term Bondgraphs. In mechanical domain, effort and ow refer to force andvelocity or torque and frequency for displacement or rotationrespectively . In uids, effort and ow refer to pressure and vol-ume ow. In electric domain, effort and ow refer to voltage andcurrent respectively. Besides the advantage of integrating do-mains, Bond graph introduces the concepts of causality i.e. howeach element contributes to the systems cause and effect andpower direction, useful when analyzing technical i.e. energytransforming systems. Although Bond graphs are idealized ab-stractions of real systems, energy losses, such as gear friction, andefciencies can be also represented with resistance R elementsor sources S driven in reverse 38 . Table 1 presents these vari-ables, and transformations for each Bond graph element catego-rized by number of ports; m and are modulating parameters forthe effort and ow relationships.

Standard Bond graph elements are categorized according to thenumber of ports. Each port or bond represents two wires or elec-trical connections or their mechanical or uid equivalents . Bondgraph elements are dened by a set of port variables power, ef-fort, and ow and a set of relations involving these variables.Therefore, a behavior can be represented by its inputs, outputs,and transformations as shown in Fig. 3.

Fig. 1 Function entity-relationship model with attributes

Fig. 2 Example bond graph representation of an electrome-chanical system

30 Vol. 4, MARCH 2004 Transactions of the ASME


4/9

The model in Fig. 3 is used in 2nd-CAD to represent behaviors.A user of 2nd-CAD can dene a category of behaviors by speci-fying the transformations i.e. domain, power, effort, and owrelations . For example, the Gyrator category is modeled withthe following relations: different input and output domains, sameinput and output power, input effort proportional by a factor of m to uid output, and effort output proportional by a factor of

m to ow input. Every attribute has a type e.g. numerical, text,categorical, etc. and units e.g. Watts or Horsepower associatedwith it. An instance of a behavior is obtained when values areassigned to the input and output attributes. Other users can selectpreviously dened behavior categories from the catalog and in-stantiate by assigning values to the attributes. For example, anelectric, 10 W, 5V, 2A input and a mechanical, 10W, 265N m, and360rpm output follows the Gyrator category. In case the at-tributes values are modied, and the transformation relations donot hold, 2nd-CAD will require the user to either modify thevalues or create a new behavior category. 2nd-CAD uses the samebehavior model to represent behavior categories and behavior in-stances; both are needed to populate the catalogs. Since Power

effort ow, the user needs to dene only two of them while thethird one will be a derived attribute. Finally, by comparing Figs. 1and 3 it can be seen that embedded inside the behavior modelresides the model of its own function.

4.1.3 Component Entity-Relationship Model. Various cat-egorizations exist for components also known as artifacts, parts,or devices ; these range from extensive alphabetical lists, to cat-egorizations based on energy roles. Three types of categorizationsources were found: Component Design Textbooks, Element De-sign Textbooks , and Industrial Supply Catalogs . The organizationin Component Design textbooks , such as Thorpe 39 , is clearlydened by the energy role of components in a system e.g. Prime

Mover, Power Converter/Dynamo, and Power Transmitter/ Transmission . Element Design texts , such as Shigley and Mis-chke 40 and Spotts 41 , explain in detail the design of elements,independent of any system that may use it. Elements with similarfunctions are grouped, but there is no strict categorization e.g.belts, clutches, brakes and chains . Industrial Supply Catalogs ,such as McMaster 13 , Grainger 14 , and Thomas Register 15

are comprehensive compendiums of components typically used inindustry and organized in a way that facilitates the search of arti-facts. Some suppliers use alphabetical order, engineering domains,functions, etc., to categorize components e.g. Motors/PowerTransmission, Electrical, Hydraulics/Pneumatics, and Pumps/ Plumbing . Components are dened by a list of characteristicsi.e. a specication that can be grouped into input, output and

transformations; additionally, other specications e.g. dimen-sions, use, etc. are also needed to fully dene a component asshown in Fig. 4.

The model in Fig. 4 will be used in 2nd-CAD to representcomponents. A user of 2nd-CAD can dene a category of compo-nents by specifying the transformations i.e. domain, power, ef-fort, and ow relations and the specication characteristics i.e.variables . For example, Fig. 5 shows the model for an Electro-

mechanical Motor component category.Other users of 2nd-CAD may select previously dened catego-ries of components to create instances. An instance of a compo-nent is obtained when values are assigned to the input and outputattributes. Every attribute in the model has a type e.g. numerical,text, categorical, etc. , a value, and units e.g. Watts or Horse-power . If the attributes values are changed and the transforma-tion relations are not fullled, 2nd-CAD requires the user to eithermodify the values entered or create a new component category.The same component model is used to represent component cat-

Table 1 Information content for bond graph behaviors

Ports Category

Input I /Output O Relationships

Port Quantity DomainType

Power PMagnitude

Effort e Flow f

0-Port Conduct #(I) #(O) SAME P(I) P(O) e(I) e(O) f(I) f(O)1-Port Source #(I) 0, #(O) 0 SAME P(I) 0, P(O) 0 e(I) 0, e(O) 0 f(I) 0, f(O) 0

Capacity #(I) 0, #(O) 0 SAME P(I) 0, P(O) 0 e(I) 0, e(O) 0 f(I) 0, f(O) 0Resistance #(I) 0, #(O) 0 SAME P(I) 0, P(O) 0 e(I) 0, e(O) 0 f(I) 0, f(O) 0Inertia #(I) 0, #(O) 0 SAME P(I) P(O) e (I) 0, e(O) 0 f(I) 0, f(O) 0

2-Port Impedance TFe-control

#(I) #(O) SAME P(I) P(O) e(I) e(O) f(I) f(O),f(O) x

Impedance TFf-control #(I) #(O) SAME P(I) P(O) e(I) e(O),e(O) x f(I) f(O)Class TF #(I) #(O) CHANGE P(I) P(O) e(I) e(O) f(I) f(O)Gyrator #(I) #(O) CHANGE P(I) P(O) e(I) mf(O) e(O) mf(I)

N-Port S Junction #(I) #(O) SAME P(I) P(O) e(I) e(O) f(I) f(O)P Junction #(I) (O) SAME P(I) P(O) e(I) e(O) f(I) f(O)

Fig. 3 Behavior entity-relationship model with attributes



5/9

egories and component instances in 2nd-CAD; both are needed topopulate the catalogs. By comparing Figs. 1, 3, and 4, it can beseen that embedded in a component entity model resides themodel of its behavior and hence of its function. A component maybe a candidate for parametric design if a parameterization alreadyexists for the given category and the amount of informationknown i.e. the parameterization input is sufcient i.e. the equa-tion system isnt under or over constrained to calculate a solution42 .

4.1.4 Integrating Function, Behavior, and Component ModelsThe information models for functions, behaviors, and componentsfrom Figs. 1, 3, and 4 are superimposed in Fig. 6 to show theinformation hierarchy. This hierarchy is not a coincidence sincecomponents exhibit behaviors, and behaviors achieve functions.The integration of the three models allows the user of 2nd-CAD toreuse information when synthesizing e.g. from function to com-ponent and validating e.g. from component to function concep-tual designs i.e. structures .

Figure 7 shows a high level correspondence between Pahl andBeitz 1 function categories, Bond graph 38 basic behavior el-ements and Thorpes 39 component classication; functions andbehavior are grouped according to the input/output or port con-guration. The user can create own categories, and store basic andcomposed i.e. a substructure entities instances in the catalog forlater use. Structures can also be stored in catalogs as composedelements for later use.

4.2 Catalog Transactions.The functional requirements de-scribed in section 3 for 2nd-CAD catalogs are reformulated into

transactions i.e. data transformations or queries . Edit i.e. copy,paste, cut, add, modify, and create processes involve queries thattransform elements as a whole in a catalog while modify involvesa query that modies the elements information content. View in-volves a query that transforms i.e. sorts the contents for presen-tation purposes, leaving the original list intact. The user denesthe query since the catalog doesnt follow a xed categorization.Query traverses the list searching for elements that match certain

Fig. 4 Component entity-relationship model with attributes

Fig. 5 Component category model for motor

Fig. 6 Information hierarchy in function, behavior, and component entity models



6/9

information criteria. All these data transactions are achievablewith most Database Management Systems DBMS .

4.3 Relationship Modeling. Two types of relationships arenecessary to create a function, behavior, or component structure:ow and composition. Flow relationships relate the output of energy, material or signal of an element to the input of anothere.g. function A to function B while composition relationships

relate parent elements to child elements, dening in the process asubsystem hierarchy e.g. ancestors and descendants . A third typeof relation, mapping, connects elements from different structurese.g. function to behavior . These three types of relationships, pic-

tured in Fig. 8, are used in 2nd-CAD to represent structures; the

user uses these relationships to connect entities in a structure. Toavoid the creation of invalid structures, every relationship type hasa set of constraints that must be fullled when connecting twoentities; with this, the user has the freedom to choose the analysisi.e. system decomposition approach while the relationships con-

straints enforce the validity of the structure. Synthesis of the struc-ture is not forced e.g. by using arbitrary relationships or ad-hoccases ; instead, the user can take advantage of the hierarchicalinformation content of the entities to search 2nd-CAD catalogs formatches. This is possible since the entities representation modelsare integrated and information can be hierarchically reused fromfunction to behavior to component.

4.3.1 Flow Relationship Model. Flow relationships connectthe outputs and inputs of two elements; the following constraintsmust be observed in order to have valid structures: First, elementsmust be of the same type i.e. two functions, two behaviors, ortwo components . Second, the connecting input and output mustbelong to different entities. Third, the connecting output and inputmust not be already connected. And fourth, the connecting outputand input attributes must match. The attributes compared dependon the element level, for functions, only the domain and powertype are compared, for behaviors, also the effort and ow arecompared, and for components, also the input/output specica-

tions are compared. The user selects the ows to connect, but2nd-CAD enforces the constraints. The creation or deletion of ow relationships in a structure involves the propagation of changes; this is discussed later in structure transactions.

4.3.2 Composition Relationship Model. Composition rela-tionships connect parent and child elements in a structure. In orderto have only technically feasible decomposition relationships, thefollowing constraints must be followed: First, elements must be of the same type i.e. two functions, two behaviors, or two compo-nents . Second, the selected child entity must be orphan. Third,the composition connection must not create a paradox i.e. anelement cant be its own parent or child, grandparent or grand-child, etc. . While the user selects the entities to connect, 2nd-CAD enforces these constraints. The creation or deletion of com-position relationships in a structure involves the propagation of changes.

4.3.3 Mapping Relationship Model. Mapping relationshipsconnect elements from different structure levels e.g. function andbehavior to obtain interconnected structures. In order to have atechnically feasible mapping relationship, the following con-straints must be followed. First, the elements must be unmapped,or mapped to a third unrelated structure. Second, the elements inthe lineage i.e. ancestors and descendants must be unmapped, ormapped to a third unrelated structure. And third, the informationhierarchy of the connecting elements must match, for example, if a function is related to a behavior, all the function attribute valuesmust match the ones in the behavior. Similarly when relating abehavior and a component, all the behavior attribute values mustmatch the ones in a component. In the same manner, a function

and a component can be related. Multiple mapping is possible, forexample, when mapping two elements, their descendants and an-cestors are indirectly mapped. While the user selects the entities toconnect, 2nd-CAD enforces these constraints. The creation or de-letion of mapping relationships in a structure involves the propa-gation of changes.

4.4 Structure Transactions. The functional requirementsdescribed in section 3 for 2nd-CAD structures are reformulatedinto transactions i.e. data transformations or queries . View fol-lows a sequence of concatenated queries to organize and presentthe elements in a structure. Edit cut, copy, and paste requires

Fig. 7 Comparison of component, function, and behavior tax-onomies

Fig. 8 2nd-CAD structure entity-relationship model



7/9

queries that search in the structure and operate on whole elementswhile Modify requires a query that searches and transforms ele-ments contents. Query requires a straightforward search based onattribute values. Check-in requires a combination of Edit copyand Catalogs File-save. Check-out requires a combination of Catalogs Query and Edit to search, copy, and paste entities into astructure. Connect involves queries that nds two elements, com-pares their attributes, and creates a relationship between elementsto make a structure. Since the structure is a constrained network i.e. n to n relationships of entities, some transactions may have a

repercussion in neighboring entities making necessary the propa-

gation of changes. The concept of satisfaction is introduced inorder to explain the change propagation mechanism for eachtransaction case. An entity is declared as satised when it meetsthe following criteria: First, all children have technically feasibleow relations, second, the overall inputs and outputs of the childsubsystem are same as the parent, and third, the composition re-lationships are technically feasible. The criteria applies to rst-generation children, this means that the children give parent sat-isfaction one generation at a time; propagation at furthergeneration depths is discussed as future work. Leave i.e. termi-nal entities are never satised since they dont have offspring andit is expected that these are simple enough to be solved. Edit -Cutrequires posterior maintenance on the structure to heal looserelationships; delete all input and output ow relationships of thedeleted entity, delete all parent and child composition relation-ships of the deleted entity, delete all mapping relationships of thedeleted entity, and mark parent as unsatised if it was satised . Edit -Modify also requires posterior maintenance on the structure;reevaluate technical feasibility of affected input and output owrelationships of the modied entity, reevaluate technical feasibilityof all affected parent and child composition relationships of themodied entity, reevaluate technical feasibility of all mapping re-lationships of the modied entity, and reevaluate parent satisfac-tion. Connect may make a parent satised or unsatised; for anyow, composition, and mapping connection or disconnection, re-evaluate parent satisfaction. While the user selects the elements orows on which to perform a transaction, 2nd-CAD propagates thenecessary changes and checks for structure satisfaction . The rstversion of 2nd-CAD incorporates these constraints and the propa-gation of changes in structures. The following structure mappingprocedure is an example of how new functionality could be addedto the rst version of 2nd-CAD. Until now, mapping refers to theuser connecting two elements from two existing structures, butthis task can be automated. For example, if a functional structureis in place, a behavior structure can be interactively distilled. 2nd-CAD will traverse the functional tree structure depth-rst stoppingat the level in which it nds a matching known behavior in thecatalog; this is shown in Fig. 9. The numbers show the order of the search; shaded and white squares represent matched and un-matched functions respectively. In case the search yields nomatches, a black box behavior is suggested. This black boxadopts the connecting outputs and inputs to dene its own inputsand outputs respectively, but it does not contain transformationinformation. A black box can be considered a temporary solu-tion that can be later addressed; it may require a substructure of entities, or the creation of a new category. In the example of Fig.

9, functions 6 and 10 were matched to a behavior there is no needto map their children while functions 4, 5, 8, and 9 were eithermatched to a behavior or a black box since these are terminalnodes . After mapping, the result is a horizontal i.e. ow relationsonly behavior structure that can be composed and/or decomposedby the designer. This approach ensures that at least one element ineach lineage is mapped between function and behavior structures.

5 Physical Implementation of 2nd-CADSections 3 Functional Requirements and 4 Logical Design

respectively dene the implementation specication of 2nd-CADin user i.e. information and processes and logical i.e. data mod-

els and transactions terms. In summary, the 2nd-CAD implemen-tation allows the use of function, behavior, and component entitiescontained in catalogs for the creation of structures. The implemen-tation includes the specied component and structure transactions,enforcing technical feasibility, change propagation, and entity sat-isfaction checking. At this point, the program and database sizesare not expected to cause hard disk space or computation timeproblems.

5.1 System Architecture and Module Design of 2nd-CAD.The system architecture for 2nd-CAD was implemented in fourlayers, as shown in Fig. 10. The user interacts with 2nd-CADthrough a Graphical User Interface GUI that receives input andprovides output as described in the functional requirements sec-tion 3 . The second layer Application receives input in form of commands that are then transformed into queries; all the logicaltransactions and constraints are managed in this module. The que-ries are sent to the third level Database Management System-DBMS that interacts with the catalogs and structures databasesDB in the fourth level. The queries results are sent back to the

DBMS, then to the application and nally as a redisplay to theGUI for the user to receive as output.

5.1.1 Database Module. Flow, composition, and mappingrelationships can be represented by network, hierarchical, and re-lational data structures; in general, the overall structure can berepresented by a multidimensional data structure; instead, the data

was stored in XML Extensible Markup Language format. Thereare various reasons for choosing XML format for data manage-ment; the most important being the way it handles multidimen-sional relations. Additionally, it is a widely accepted standard, it ishuman readable, provides for the integration of any data regard-less of storage environment or document type since data is self-describing i.e. accompanied by its structure , enables data inter-change and is platform and application independent, supports datamining and data analysis, affords precision search and retrievalincluding vertical and horizontal information navigation paths,among others 43 .

5.1.2 Database Management System. Xerces-C andXalan-C 44 were used as the DBMS. Xerces is a validatingXML parser for reading and writing XML data while Xalan is anXSLT Extensible Stylesheet Language Transformation processorfor transforming XML documents. XSLT is a language for trans-forming XML documents into other XML documents. All queriesgenerated for the logical transactions were written in XSLT. Threeles dene a query: an XSLT query le, an XML input le i.e.the structures or catalogs , and an XML output le for the results.

5.1.3 Application Module. Microsoft Foundation ClassesMFC was used as the platform for 2nd-CADs implementation.

The tree and diagram visualization tools read from the catalogsand structures XML les and display them in the GUI. Func-tions were created in C for each transaction; some of thesefunctions include the necessary constraint satisfaction 45,46 inorder to maintain structure validity. Each function sends a query

Fig. 9 Example of an automated function to behavior mappingprocedure



8/9

to the DBMS and receives a result in the form of an XML le.This result is shaped into a user output either in a dialog box or asa modication in the diagrams or trees .

5.1.4 Graphical User Interface. The designer interacts with2nd-CAD through the Graphical User Interface GUI , which in-cludes the Catalog and the Structure interfaces. These are a prod-uct of the applications visualization tools. The output to the useris presented as catalog trees, structure diagrams, and dialog boxes.The input is collected by means of the trees, structures, and dialogboxes.

5.2 Evaluation of 2nd-CAD. The rst version of 2nd-CADhas been implemented and is currently being evaluated. Theevaluation is conducted by comparing against the functional re-

quirements dened in section 3 quality evaluation and by com-paring against other conceptual design tools and methods bench-marking . For quality evaluation the criteria can be categorizedinto explicit and implicit 47 . The explicit criteria is dened inthe functional requirements while the implicit criteria, althoughnot stated, is still expected. The explicit criterion includes con-straints for technical feasibility and change propagation in struc-tures, design intent capture, information reuse, design history re-cording, and an easy to use Graphical User Interface. The implicitcriteria can be grouped into software operation i.e. operationalcharacteristics: correctness, reliability, efciency, integrity, usabil-ity , software revision i.e. ability to undergo change: maintain-ability, exibility, testability , and software transition i.e. adapt-ability to new environments: software transition, portability,reusability, interoperability . In benchmarking, the data of refer-ence comes from similar tools or equivalent methods. A set of benchmark test cases is being used for comparison. Each test caseaddresses a different question: scalability, extensibility, design re-use, change propagation, design validation, design history capture,and exchange of data. Three metrics are used for these cases: timeand effort needed to complete the design, and quality of the re-sulting design.

6 Conclusions and Future WorkFuture versions of 2nd-CAD can be improved to extend its

functionality. For example, signal and material ows, and corre-sponding function, behavior, and components for these ows canbe included. The behavior model could be extended to include

dynamic time dependant analysis. The concepts of main andauxiliary entities can be introduced. Parsers can be written to sendand receive data to and from other tools for functional analysis,behavior simulation, component synthesis, and other down-stream applications. In general, any typical task performed onthe concept structure is a candidate for automation, for example,the propagation of changes to further levels. 2nd-CAD can pro-vide a technically feasible seed design as a starting point for Ge-netic Programming GP while the resulting evolved structurescould be parsed back to 2nd-CAD. Design optimization ap-proaches could be implemented to improve the conceptual designstructures. Designers reasoning knowledge can be captured inknowledge bases i.e. as if-then rules , to provide interactive ad-vice, or in case bases i.e. as indexed cases , for the designer to

browse. Change notication, content sharing, and design version-ing are issues that need to be addressed for collaborative designwith 2nd-CAD; program agents can be used to handle conictresolution.

The development of 2nd-CAD was presented from the identi-cation of the need to its implementation. Based on the state of theart survey, the need was clearly identied. The functional require-ments were rst dened and used to derive a logical model in-cluding entities, relationships, transactions and constraints . Thislogical model was then used as the core for implementation. Themajor contribution of 2nd-CAD is its robust logical model, whichcan act as a common platform for creating valid structures withdifferent taxonomies, and can be extended with added functional-ity in future versions. Disregarding time and effort, it is theoreti-cally possible that a concept created in 2nd-CAD be replicatedusing any other CACD tool or method, still, the structure createdwith 2nd-CAD has various advantages e.g. change propagation,data exchange, information reuse, etc. . These advantages are cur-rently being evaluated and are expected to increase as future work for 2nd-CAD is completed.

AcknowledgementsThe authors would like to acknowledge the support received

through NSF Grant DMI-0115447.

Fig. 10 Detailed system integration of 2nd-CAD



9/9

References1 Pahl, G., and Beitz, W., 1996, Engineering Design-A Systematic Approach ,

Springer Verlag, London.2 Shah, J., and Wilson, P., 1989, Analysis of Design Abstraction, Representa-

tion and Inferencing Requirements for Computer-Aided Design, Des. Stud.,10 3 , pp. 471488.

3 Hubka, V., and Eder, W. E., 1988, Theory of Technical Systems , SpringerVerlag, Berlin.

4 Dixon, J. R., Duffey, M. R., Irani, R. K., Meunier, K. L., and Orelup, M. F.,1998, A Proposed Taxonomy of Mechanical Design Problems, Proceedingsof 1988 ASME CIE, Santa Clara, California.

5 DOME, 2003, http://www.htc.honeywell.com/dome/ 6 MetaEdit, 2003, www.metacase.com7 Matlab, 2003, www.matlab.com8 Labview, 2003, www.labview.com9 Mathcad, 2003, www.mathcad.com

10 Working Model, 2003, www.workingmodel.com11 Symbols2000, 2003, www.symbols2000.com12 Dymola, 2003, www.dymola.com13 McMaster-Carr, 2003, www.mcmaster.com14 Grainger, 2003, www.grainger.com15 Thomas Register, 2003, www.thomasregister.com16 Szykman, S., Sriram, R., and Regli, W. C., 2001, The Role of Knowledge in

Next-Generation Product Development Systems,J. Comp. Inf. Sci. Eng. 1 2 ,pp. 311.

17 Kirschman, C. F., and Fadel, G. M., 1998, Classifying Functions for Me-chanical Design, J. Mech. Des., 120 3 , pp. 475482.

18 Lai, K., and Wilson, W. R. D., 1987, FDLA Language for Function andDescription and Rationalization in Mechanical Design, Computers in Engi-neering, Proceedings of the ASME International Conference and Exhibition ,New York, pp. 8794.

19 Stone, R. B., Wood, K. L., and Crawford, R. H., 2000, Using QuantitativeFunctional Models to Develop Product Architectures, Des. Stud., 21 3 , pp.239260.

20 Collins, J. A., Hagan, B. T., and Bratt, H. M., 1976, The Failure-ExperienceMatrixA Useful Design Tool, ASME J. Eng. Ind., 98, pp. 10741079.

21 Suh, N. P., 1990, The Principles of Design , Oxford Press, New York.22 Szykman S., Racz, J. W., and Sriram, R., 1999, The Representation of Func-

tion in Computer-Based Design, Proceedings of 1999 ASME DETC , Las Ve-gas, NV.

23 Kitamura, Y., and Mizoguchi, R., 2001, Ontology-based Description of Func-tional Design Knowledge and its Use in a Functional Way Server, Expert Sys.Applic., 24, pp. 153166.

24 Chakrabarti, A., and Bligh, T. P., 2001, A Scheme for Functional Reasoningin Conceptual Design, Des. Stud., 22 6 , pp. 493517.

25 Freeman, P., and Newell, A., 1971, A Model for Functional Reasoning inDesign, Proceedings of the 2nd International Joint Conference in Articial Intelligence , London, pp. 621633.

26 Yoshikawa, H., 1985, General Design Theory and a CAD System, IFIPMan-Machine Communication in CAD/CAM, Sata T., and Warman, E. eds.,pp. 3588.

27 Horvath, I., Vergeest, J. S. M., and Kuczogi, G., 1998, Development andApplication of Design Concept Ontologies for Contextual Conceptualization,Proceedings of 1998 ASME DETC , Atlanta GA.

28 Chakrabarti, A., and Tang, M. X., 1996, Generating Conceptual Solutions onFuncSION: Evolution of a Function Synthesizer, Articial Intelligence inDesign 96, Gero, J. S., and Sudweeks, F. eds., Stanford, California, pp. 603622.

29 Brady, D., and Juster, N. P., 1995, A Computerized Tool to Create ConceptVariants from Function Structures, AI System Support for Conceptual De-sign, Proceedings of the 1995 Lancaster International Workshop on Engineer-ing Design , John Sharpe ed., pp. 209226.

30 Zhang, W. Y., Tor, S. B., and Britton, G. A., A Prototype Knowledge-BasedSystem for Conceptual Synthesis of the Design Process, International Journalof Advanced Manufacturing Technology, 17 8 , pp. 549557.

31 Vargas-Hernandez, N., Shah, J. J., and Lacroix, Z., 2002, Knowledge Repre-sentation for Conceptual Engineering Design, Proceedings of 2002 AAAI SNPD , Madrid, Spain.

32 Vargas-Hernandez, N., Shah, J. J., and Lacroix, Z., 2003, Development of aComputer Aided Conceptual Design Tool for Complex Electromechanical Sys-tems, Proceedings of 2003 AAAI Spring Symposium on Computational Syn-thesis , Stanford, CA.

33 Summers, J. D., Vargas-Hernandez, N., Zhao, Z., Shah, J. J., and Lacroix, Z.,2001, Comparative Study of Representation Structures for Modeling Func-tion and Behavior of Mechanical Devices, in Proc. ASME DETC, Pittsburgh,PA.

34 Woods, W. A., 1997, Conceptual Indexing: A Better Way to Organize Knowl-edge , Sun Microsystems Inc.

35 Hundal, M., 1990, A Systematic Method for Developing Function Structures,Solutions and Concept Variants, Mech. Mach. Theory, 25 3 , pp. 243256.

36 Altshuller, G., 1984, Creativity as an Exact Science , Gordon and Branch Sci-ence Publishers, New York.

37 Chen, P. P., 1976, The Entity-Relationship Model-Toward a Unied View of Data, ACM Trans. Database. Sys., 1 1 , pp. 936.

38 Thoma, J. U., 1975, Introduction to Bond Graphs and their Applications , Ed.1, Pergamon Press, London.

39 Thorpe, J. F., 1989, Mechanical System Components , Ed. 1, Prentice Hall,New Jersey.

40 Shigley, J. E., and Mischke, C. R., 1989, Mechanical Engineering Design , Ed.5, McGraw-Hill, New York.

41 Spotts, M. F., 1985, Design of Machine Elements , Ed. 6, Prentice Hall, NewJersey.

42 Vaidya, A., and Shah, J., 2003, Design Shell for Parametric Design at Em-bodiment Stage, Proceedings of 2003 ASME DETC , Chicago, IL.

43 World Wide Web Consortium, 2003, www.w3c.org44 Apache, 2003, xml.apache.org45 Guesguen, H., and Hertzberg, J., 1992, A Perspective of Constraint-Based

Reasoning: An Introductory Tutorial , Springer Verlag, New York.46 Meyer, M., 1995, Finite Domain Constraints: Declarativity Meets Efciency

Theory Meets Application , Inx, Germany.47 Pressman, R. S., 1987, Software Engineering: A Practitioners Approach , 2nd

Ed., McGraw-Hill, New York.


2nd-cad a tool for conceptual systems design in electromechanical domain jcise-vargas-2004

Documents