A web-based system for design artifact modeling

Design of complex engineering systems is increasingly becominga collaborative task among designers or design teams that arephysically, geographically, and temporally distributed. The com-

plexity of modern products means that a single designer or design team canno longer manage the complete product development effort. Developingproducts without sufficient expertise in a broad set of disciplines can resultin extended product development cycles, higher development costs, andquality problems. On the other hand, ensuring comprehensive technicalproficiency in a world where trends are toward more multidisciplinarydesign can become a costly undertaking for a company.

Driven by such issues, companies are increasingly staffing only their corecompetencies in-house and depending on other firms to provide the comp-

www.elsevier.com/locate/destud0142-694X/00 $ - see front matterDesign Studies21 (2000) 145–165PII: S0142-694X(99)00044-7 145Published by Elsevier Science Ltd Printed in Great Britain

A web-based system for designartifact modeling

Simon Szykman, Janusz Racz, Christophe Bochenek and Ram D.Sriram, Manufacturing Systems Integration Division, National Instituteof Standards and Technology, Building 304, Room 6, Gaithersburg, MD20899, USA

Engineering product development in today’s industry is becomingincreasingly knowledge intensive. The NIST Design Repository Project,at the National Institute of Standards and Technology, is working todevelop infrastructural technologies to support the use of designrepositories in industry. In contrast to traditional design databases,design repositories more actively support knowledge-based design,serving not only as archives, but as repositories of heterogeneousinformation that are designed to enable representation, capture, sharing,and reuse of corporate design knowledge. This paper presents alanguage that has been developed for the modeling of engineeringdesign artifacts. The implementation of a prototype tool suite, whichincludes intelligent web-based interfaces that allow distributed users tocreate, edit and browse design repositories, is also described. Publishedby Elsevier Science Ltd.

Keywords: design models, design knowledge, engineering design, designrepository

lementary design knowledge and design effort needed for a complete pro-duct. Designers are no longer merely exchanging geometric data, but moregeneral knowledge about design and design process, including specifi-cations, design rules, constraints, rationale, etc. As design becomes increas-ingly knowledge-intensive and collaborative, the need for computationaldesign frameworks to support the representation and use of knowledgeamong distributed designers becomes more critical. Due to the explosivegrowth of the Internet and associated information infrastructure, as well asthe ubiquity of World Wide Web browsers, the use of the Internet and theWorld Wide Web as methods for communication and information transferis increasing.

In addition to sharing and exchanging information, pressure to reduce pro-duct development times has resulted in an increased focus on methodsfor representing and storing engineering artifact knowledge in a way thatfacilitates its retrieval and subsequent reuse. Merely providing access toschematics, computer-aided design (CAD) models of artifacts, and writtendocumentation is inadequate for this purpose. The emerging research areaof design repositories is aimed at addressing these industry needs.

1 Design repositoriesA design repository is an intelligent knowledge-based design modelingsystem used to facilitate the representation, capture, sharing, and reuse(search and retrieval) of corporate design knowledge. It should be notedthat although the term design repositories has not yet found its way intodaily usage in industry, many companies are migrating from traditionaldesign databases to design repositories (see note 1). Design repositoriesare distinguished from traditional design databases in a number of signifi-cant ways:

I Traditional design databases are typically more data-centric thanknowledge-centric, while design repositories attempt to capture a morecomplete design representation that may include characterization offunction, behavior, design rules, simulation models, and so on.

I Design databases are generally more homogeneous in the kinds ofinformation they contain (e.g. images, CAD models, and unstructuredtext/documentation). Design repositories may include, in addition tothese, formal data/information models, structured text (specialized lan-guages for representing function, design rules, logical expressions),mathematical simulation models and more.

I Design databases tend to be static sources of information (though theircontents may grow with time). Design repositories are designed notonly for storage of information, but to support retrieval and reuse of

146 Design Studies Vol 21 No 2 March 2000

1 Szykman, S, Sriram, R Dand Smith, S J (eds) Proceed-ings of the NIST Design Reposi-tory Workshop, NISTIR 6159,National Institute of Standardsand Technology, Gaithersburg,MD, November, 1996 (1998)2 Szykman, S, Sriram, R D,Bochenek, C and Racz, J W‘The NIST Design RepositoryProject’ in Roy R, Furuhashi, Tand Chawdhry, P K (eds)Advances in soft computing—engineering design and manu-facturing Springer-Verlag, Lon-don (1999) pp 5–193 Bliznakov, P I, Shah, J J andUrban, S D ‘Integration infra-structure to support concurrenceand collaboration in engineeringdesign’ Proceedings of the 1996ASME Design EngineeringTechnical Conferences andComputers in Engineering Con-ference Paper No. 96-DETC/EIM-1420, Irvine, CA,August (1996)4 Hardwick, M and Loffredo,D ‘Using EXPRESS toimplement concurrent engineer-ing databases’ Proceedings ofthe 1995 ASME Computers inEngineering Conference andEngineering Database Sym-posium Boston, MA, September(1995) pp 1069–10835 Kim, T S, Han, S -H andShin, Y J ‘Product data manage-ment using AP203 of STEP stan-dard’ Proceedings of the 1996ASME Design EngineeringTechnical Conferences andComputers in Engineering Con-ference Paper No. 96-DETC/DAC-1069, Irvine, CA,August (1996)6 Shah, J J, Jeon, D K, Urban,S D, Bliznakov, P and Rogers,M ‘Database infrastructure forsupporting engineering designhistories’ Computer-AidedDesign Vol 28 No 5 (1996)pp 347–3607 Wood III, W H and Agogino,A M ‘Case-based conceptualdesign information server forconcurrent engineering’ Com-puter-Aided Design Vol 28 No 5(1996) pp 361–3708 Bilgic, T and Rock, D ‘Pro-duct data management systems:state-of-the-art and the future’Proceedings of the 1997 ASMEDesign Engineering TechnicalConferences Paper No. DETC97/EIM-3720, Sacramento, CA,September (1997)

design data in more sophisticated ways such as search forcomponents/assemblies that satisfy required functions, explicit rep-resentation of physical and functional decompositions and the map-pings between them, etc.

The NIST (National Institute of Standards and Technology) Design Reposi-tory Project involves research toward creating a technical foundation forthe development of design repositories, addressing a broad set of issuesfrom knowledge representation and information models, to taxonomies ofdesign function, to interfaces. The project was motivated by needs ident-ified at an industry workshop held at NIST in November 19961 and, assuch, focuses on needs determined by industry participants to be importantto future knowledge-based design systems.

This paper presents a summary of the knowledge representations usedwithin the NIST Design Repository Project artifact modeling system, fol-lowed by details about the implementation and intelligent web-based inter-faces for creating, editing and browsing design repositories. A more generalsummary of the project and associated research issues can be found in theliterature2. Research done in areas related to the work described in thispaper are summarized in section 2. Section 3 describes the knowledgerepresentation used for modeling design artifacts. The implementation, sys-tem architecture and interfaces are presented in section 4. Section 5 dis-cusses conclusions and future directions for this project.

2 Related workTraditional CAD systems are limited to representation of geometric dataand other types of information relating to geometry that may include con-straints, parametric information, features, and so on. The engineeringdesign community has been developing new classes of tools to supportknowledge-based design, product data management (PDM), and concurrentengineering. When contrasted with traditional CAD tools, these new sys-tems are making progress toward the next generation of engineering designsupport tools. However, these systems have been focusing primarily ondatabase-related issues and do not place a primary emphasis on informationmodels for artifact representation (e.g.3–7).

Furthermore, although these systems can represent some kinds of non-geometric knowledge (e.g. information about the design process, manufac-turing process, bills of materials, etc.), representation of the artifact itselfis still generally limited to geometry. This impacts the utility of a rangeof software tools used in engineering industry. As an example, the lack ofa formal product representation that includes function, behavior and struc-ture has been identified as a shortcoming of existing PDM systems8.

A web-based system for design artifact modeling 147

9 Wong, A and Sriram, R D‘SHARED: an information modelfor cooperative product develop-ment’ Research in EngineeringDesign Vol 5 No 1 (1993)pp 21–3910 Gorti, S R, Gupta, G J,Kim, G J, Sriram, R D andWong, A ‘An object-orientedrepresentation for product anddesign process’ Computer-AidedDesign Vol 30 No 7 (1998)pp 489–50111 de Kleer, J and Brown, J S‘Assumptions and ambiguities inmechanistic mental models’ inGentner, D and Stevens, A L(eds) Mental models LawrenceErlbaum Associates, New Jersey(1983) pp 155–19012 Iwasaki Y and Chandrase-karan, B ‘Design verificationthrough function and behavior-oriented representations: bring-ing the gap between functionand behavior’ in Gero, J S (ed)Artificial intelligence in design ’92Kluwer Academic Publishers,Boston, (1992) pp 597–61613 Chandrasekaran, B, Goel,A and Iwasaki, Y ‘Functionalrepresentation as design ration-ale’ IEEE Computer January(1993) pp 48–5614 Goel, A, Bhatta, S andStroulia, E ‘KRITIK: an earlycase-based design system’ inMaher, M and Pu, P (eds)Issues and applications of case-based reasoning to design Lawr-ence Erlbaum Associates, NewJersey (1996)15 Goel, A, Gomez, A, Grue,N, Murdock, J W, Recker, Mand Govindaraj T ‘Explanatoryinterface in interactive designenvironments’ in Gero, J S (ed)Artificial intelligence in design ’96Kluwer Academic Publishers,Boston (1996)16 Alberts, L K and Dikker, F‘Integrating standards and syn-thesis knowledge using theYMIR ontology’ in Gero, J S andSudweeks, F (eds) Artificialintelligence in design ’94 KluwerAcademic Publishers, Boston(1992) pp 517–53417 Henson, B, Juster, N andde Pennington, A ‘Towards anintegrated representation offunction, behavior and form’ inSharpe, J amd Oh, V (eds)Computer aided conceptualdesign, Proceedings of the 1994Lancaster International Work-shop on Engineering DesignLancaster University EDC, Lanc-aster (1994) pp 95–111

Because of industry’s increasing dependence on knowledge, rather thansimply geometric data, the design artifact modeling system developed inthe NIST Design Repository Project focuses on an artifact representationthat encompasses a broader engineering design context. This contextincludes representation not only of geometry, but also of function,behavior, physical and functional decompositions, relationships amongthese various entities, and so on.

The artifact modeling representation used in this research builds on earlierwork in developing an object-oriented representation format that providesa high level division into form, function, and behavior9,10. The division ofdesign artifact knowledge into these categories has its roots in earlier workin intelligent design system development. Examples of such work in arti-ficial intelligence community include the qualitative simulation work11,behavioral and functional representation12, functional representation13 andsuccessive representation from projects such as KRITIK14 and INTER-ACTIVE KRITIK 15, the YMIR project16, and others. Work done in thedesign and engineering community includes CONGEN10, the MOSES pro-ject17, the GNOSIS IMS (Intelligent Manufacturing System) project18,Function–Behavior–State Modeler19, and a function–behavior–structureframework20. A significant distinction between the research presented inthis paper and previous research is the implementation of web-based inter-faces as part of this work to support distributed access to knowledge.Another focus of the NIST Design Repository Project is the attempt toaddress terminological and taxonomic issues in artifact modeling. The needfor standardized terminology in design artifact modeling is often over-looked in the literature; however, it is an issue of critical importance. Thisparticular research issue is mentioned briefly at the end of section 3, butextends beyond the scope of this paper; a more detailed discussion of thisissue can be found in Szykman et al.21.

3 Knowledge representationDesign repositories are intended to support the storage, retrieval and reuseof engineering knowledge about artifacts that have been designed. Thisknowledge includes the description of geometry such as drawings and/orCAD models, as well as complementary knowledge concerning charac-terization of artifacts, function, behavior, relationships and interconnectionsbetween them. Information is represented using a formal knowledge rep-resentation that can be comprehended by humans, but which, unlike naturallanguage, can be interpreted by computers and used for (partially) auto-mated reasoning about designs.

In order to achieve this objective, an artifact modeling language has beendeveloped that consists of a data language (DL) and a design representation


18 Ranta, M, Mantyla , M,Umeda, Y and Tomiyama, T‘Integration of functional and fea-ture-based product modelling—the IMS/GNOSIS experience’Computer-Aided Design Vol 28No 5 (1996) pp 371–38119 Umeda, Y, Ishii, M,Yoshioka, M, Shimomura, Yand Tomiyama, T ‘Supportingconceptual design based on thefunction–behavior–state mode-ler’ Artificial Intelligence forEngineering Design Analysisand Manufacturing Vol 10 (1996)pp 275–28820 Qian, L and Gero, J S‘Function–behavior–structurepaths and their role in analogy-based design’ Artificial Intelli-gence for Engineering Analysisand Manufacturing Design Vol10 No 4 (1996) pp 289–31221 Szykman, S, Racz, J Wand Sriram, R D ‘The represen-tation of function in computer-based design’ Proceedings ofthe 1999 ASME Design Engin-eering Technical Conferences(11th International Conferenceon Design Theory andMethodology), Paper No.DETC99/DTM-8742, Las Vegas,NV, September (1999)22 Murdock, J W, Szykman, Sand Sriram, R D ‘An informationmodeling framework to supportdesign databases and reposi-tories’ Proceedings of the 1997ASME Design for ManufacturingConference Paper No.DETC97/DFM-4373, Sacra-mento, CA, September (1997)

language (DRL)22. The data language describes the syntax and data struc-tures for a highly generic object-oriented (object/class) paradigm that canbe applied to any of many different domains; the design representationlanguage combines the data language with an engineering context to pro-vide the means for modeling design artifacts. The artifact modeling langu-age is derived from the SHARED object model9, which has previouslybeen implemented within a conceptual design shell called CONGEN (anobject-oriented domain-independent design support framework)10.

3.1 The data languageThe data language (DL) consists of four basic types of entities: objects(see note 2), relationships, and (object) classes and relationship classesfrom which objects and relationships are instantiated. These entity typesare described in the following subsections.

3.1.1 ObjectsAn object o is defined aso(oid, cid, A, R), whereoid is a unique objectidentifier (i.e. a name),cid identifies the class to which the object belongs(i.e. the parent of the object),A is a set of attributes represented by namesof attributes and their values (which may be strings, numbers, references toother entities, etc.), andR is a set of relationships between sets of objects.

An example of an object data structure is shown in Figure 1 (see note3). The object shown defines the artifact (see note 4) nameddrill—

artifact—1 (its oid), as being an instance of theDrill—artifact

class. Its five attributes arefunction, form, behavior, full—name, anddescription. The values of the first three attributes are in brackets, meaningthat they are references to other entities having the names indicated; theother two attributes have strings as values. The list of relationships forthe drill—artifact—1 object consists of a single relationship, againindicated by an entity name in brackets.

3.1.2 RelationshipsRelationships among objects are represented explicitly in the data language.This aids in organizing groups of objects (in hierarchical or tree structures,


Figure 1 Example schema

for an object entity

for example), as well as in supporting human or automated navigationamong collections of objects, which in our case are design repositories.The generic relationshipr is defined similarly to the object:r (r id, r cid, RO,A), wherer id is a unique identifier (name) of the relationship,r cid identifiesthe relationship class to which the relationship belongs,RO is a set ofroles that describes the nature of the relationship between the associatedentities, andA is a set of attributes defined the same way as for an object.

An example of a relationship entity is shown in Figure 2. The entity is aninstance of theHas—part relationship class, and defines the decompo-sition of acompositeassembly (thedrill—artifact—1 object) into aset of componentswhich may be either subassemblies and/or individualcomponents. This relationship is bi-directional; the relationship referencesboth the composite and the components, and the relationship itself is refer-enced in the data structures for both the composite (as seen in Figure 1)and in the components (not shown). Such an approach enables the organi-zation of a collection of objects using relationships in either a bottom upor a top down fashion, or a mix of both. The example shown is taken fromthe artifact modeling domain, and thus thecompositeandcomponentsrolesapply to the representation of artifacts. These roles are associated with thedesign representation language, which has roles specific to artifact mode-ling; the generic data language itself does not restrict the roles associatedwith a relationship to a given domain.

3.1.3 Object classesThe structures of individual objects and their syntax are described by objectclasses (hereafter referred to simply as ‘classes’). A classc is defined asc(cid, scid, Ad, Rc), wherecid is a unique class identifier (name),scid is asuperclass (i.e. a parent class) of whichc is a subclass,Ad is a set ofattribute definitions, andRc is a set of relationship classes. An objectobelonging to a classc contains the attributes and relationships of that class.This allows a generic class to define the schema for instantiated objectsbelonging to that class. An object belonging to a class generally has theslots defined by the class, but may also differ somewhat, either by havingadditional slots not specified in the class definition, or by allowing



for a relationship entity

unnecessary slots defined in the class definition to remain unused (theunused slots would have no values). This method of relating objects toclasses differs from most object-oriented programming formulations, butis consistent with the intended use of the data language. Specifically, theclasses are intended to define useful schemata while building in represen-tational flexibility that is not required in more traditional object-orientedprogramming environments.

Figure 3 depicts the class namedTool—artifact . This class is a sub-class of the classArtifact and thus inherits attribute and relationshipslots defined in its parent’s definition. The drill artifact shown in Figure1 is an instance ofDrill—artifact , which is a subclass ofTool—

artifact . The attributesfunction, form, andbehaviorthat appear in Fig-ure 1 are inherited from theArtifact class, and therefore do not appearexplicitly in theTool—artifact class definition (Figure 3). TheTool—

artifact class definition adds a new attribute in addition to the inheritedcalled full—name, which does not appear in theArtifact class defi-nition.

3.1.4 Relationship classesRelationship classes refer to relationships and play the same role as classesdo for objects. A relationship classr c is defined asr c(r cid, srcid, ROd, Ad),where r cid is a relationship class identifier (name),srcid is a relationshipsuperclass (or parent class),ROd is a set of role definitions, andAd is aset of attribute definitions.

The relationship class shown in Figure 4 illustrates the schema of theHas—

part relationship. Note that the curly braces that appear to the left of thecomponents role indicate a list of entities, not a single entity. Thus, aHas—



for a class entity


for a relationship class

entity

23 ISO 10303-1:1994 Industrialautomation systems and inte-gration—product data represen-tation and exchange—part 1:overview and fundamental prin-ciples (1994)24 ISO 10303-203:1994 Indus-trial automation systems andintegration—product data rep-resentation and exchange—part203: application protocol: con-figuration controlled design(1994)25 ISO/IEC 14772:1998 Infor-mation technology—computergraphics and imageprocessing—the virtual realitymodeling language (1998)

part relationship defines the decomposition of a single composite, whichmust belong to theArtifact class, into a set of components which mustalso belong to theArtifact class. No attributes are defined for this class.Both the (object) class and relationship class hierarchies contain top levelentities, which have no parents. TheHas—part is an example of such arelationship class and thus the value of its parent slot is NULL.

3.2 The design representation languageThe previous subsection defined the basic schemata and data structures ofthe data language in isolation from any engineering context (though theexamples did include such context). The engineering context is definedthrough the design representation language (DRL) and includes the seman-tics and class hierarchies of artifacts, taxonomies of functions and flows,the concept of physical, functional and behavioral decomposition of anartifact, and many engineering-specific attributes.

In the DRL an artifacta is defined (via its class definition) as an objectwhose subset of attributesAa contains references to objects belonging tothree other fundamental classes:form—the geometry or physical properties(material, color, surface finish, etc.) of the artifact,function—an indicationof the purpose of an artifact, andbehavior—a causal account of the oper-ation of the artifact.

Artifacts are used to represent physical assemblies, subassemblies andcomponents; these are linked to each other by the bi-directionalHas—

part relationship to define the physical decomposition of an artifact. Simi-larly, a Has—function relationship is used to define an artifact’s func-tional decomposition. In addition to any attributes mentioned above, arti-facts may contain additional attributes specific to individual objects. Theset of classes that are descendants (viaparent slots) of theArtifact

class create a generic hierarchy that describes a conceptual classificationof products that is independent of their assembly structures. Using theDRL, any artifact is an instance of some type ofArtifact class.

Since more and more CAD systems have the ability to import and exportSTEP (Standard for the Exchange of Product Model Data)23 data, this for-mat is used as the basis for representation of geometry in this project. Thusin the DRL, objects instantiated from theform class have as attributespointers to data files in STEP format, specifically STEP AP (ApplicationProtocol) 20324. In addition, to facilitate remote visualization of artifactsover the World Wide Web, geometry is also accessible in the VirtualReality Modeling Language (VRML)25 format.


Artifact behavior specifies the response of an artifact to input conditionsor behavioral states. TheBehavior class contains attributes that refer toa set of input and output objects, as well as relationships to decomposebehavior into subbehaviors (usingHas—subbehavior andAccomplished—by relationships) to encode the link between thebehavior of one artifact and that of another artifact. The representationscheme for behavioral information within this work is not yet mature andwill be developed further as subsequent research.

In the DRL, functionsdescribe changes that take place amongflows (seenote 5), which are treated as inputs and outputs to functions. Like artifacts,functions are represented using objects that have a schema which identifiesthe function inputs and outputs through references to other entities (objects)representing flows, which in turn have their own schemata. Objects rep-resenting functions are instantiated from classes that are descended fromthe Function class.

Functions are decomposed using two types of relationships:Has—

subfunction , which decomposes a complex function into simpler ones,and Satisfied—by , which plays the same role for function asAccomplished—by does for behavior. The first type of relationshipenables the definition of a functional decomposition of a design, while thelatter is used to avoid multiple identical objects, thereby reducing the over-all number of entities required to describe a product. Because artifacts referto functions, functions refer to flows associated with those functions, andflows refer to artifacts associated with those flows, the DRL provides amapping between the representations of the physical decomposition andthe functional decomposition of a product.

The use of functional decomposition in design simplifies the design processand facilitates comprehension of the fundamental description of a product.Eventually, the process of subdivision reaches the level of ‘primitive’ func-tions beyond which further decomposition is not beneficial. A critical issuein defining the set of basic functions on which to draw for artifact modelingis the need for a terminology that is domain-independent and genericenough to model a broad variety of engineering artifacts, and yet smallenough to provide a manageable standardized vocabulary (in order to facili-tate indexing and retrieval for design reuse).

To accomplish these conflicting requirements the development of compre-hensive taxonomies of functions and associated flows has been one focusof this project. For illustrative purposes, Figure 5 shows an abridged por-tion of the (a)Function and (b)Flow taxonomies (i.e. class hierarchies)


26 Pahl, G. and Beitz, WEngineering design: a system-atic approach Springer Verlag,New York (1988)

used in this work. The indentation of terms identifies functions or flowsthat are subtypes of a more generic type; the bracketed ellipsis ‘[...]’ indi-cate that each of the types listed actually has additional terms as subtypesthat are not listed in the abbreviated taxonomies shown in the figure. Theextended taxonomies of function and flow appear in Szykman et al21. Thesetaxonomies contain over 130 functions and over 100 flows. As seen inFigure 5(b), the taxonomy of flows follows the Pahl and Beitz26 modelwith the root classFlow being decomposed into three basic subclasses:Matter, Energy , andSignal .

4 ImplementationA primary objective of the NIST Design Repository Project is to developa computational framework for the creation of design repositories, and aproof-of concept prototype to demonstrate their benefits. This research hasresulted in the implementation of a suite of tools for distributed develop-ment of, and access to, design repositories. The system that has beenimplemented includes web-based interfaces that enable a designer to create,edit, and browse design repositories, accessed via the Internet by multipledistributed clients using common web browsers.

Two types of interfaces have been implemented. The first is a DesignRepository Editor used to create and update design repositories. This editorinteracts with an ASCII text file containing the information to be storedin a repository. The format of this file follows the schemata defined by thedata language and the design representation language; the contents of theformatted text file for a power drill design repository include the data struc-tures used as examples in the previous section. The second interface is the


Figure 5 Top-level subdivisions for the function and flow taxonomies. (a) Function taxonomy, (b) flow taxonomy

Design Repository Browser (see note 6) that retrieves design repositoryinformation from the database management system (DBMS), in which itis stored. The use of this database provides capabilities such as transactionmanagement, consistency maintenance, distributed databases, synchroniz-ation of mirrored databases, information caching, etc. The schemata forthe database representation of a design repository are unchanged, butwithin the DBMS information is stored in a compiled form rather than ina formatted text file.

The Design Repository tool suite includes several components in additionto the web-based interfaces:

I ObjectStore (see note 7) a commercial object-oriented database man-agement system, developed by Object Design, Inc.

I A Design Repository Compiler which takes a formatted text file createdby the Design Repository Editor and transfers the contents to anObjectStore database.

I An information extractor or ‘decompiler’ which takes the contents of adatabase and replicates them in a formatted text file for further editing.

I STEP/Works, a STEP AP 203 viewer developed by International Tech-neGroup, Inc. for local (non web-based) visualization of STEP-basedgeometry, desirable in some cases since VRML provides a less compre-hensive representation of geometry.

4.1 ArchitectureSince the interfaces are web-based, no special client software is requiredother than a web browser. The architecture of the Design RepositoryBrowser is illustrated in Figure 6. As the designer uses the point-and-clickinterface, the browser sends Hypertext Transfer Protocol (HTTP) requeststo an HTTP server. Common Gateway Interface (CGI) scripts running onthe HTTP server parse and process those requests into database queriesthat are sent to a database server running on a different machine. Thedatabase server queries a design repository stored in an ObjectStore data-base. The database queries retrieve information from the repository andreturn the data as text to the CGI scripts, which then format the data inHTML for viewing through a web browser. The formatted data is thensent from the HTTP server back to the user. In addition to data aboutthe artifacts themselves, the repositories also include Universal ResourceLocators (URLs) for VRML models of the various assemblies and compo-nents. When the user follows one of these links, the model is retrieveddirectly using its URL without requiring calls to the database server, andis displayed for the user using a VRML plug-in or viewer.


Interactions involving the Design Repository Editor interface are quitesimilar. The main difference is the introduction of a batch processing modedesigned as a time-saving feature. When creating or editing a design reposi-tory, the contents of a repository are also stored in a specially formattedtext file as described above. As a repository is changed or modified, the textfile is updated accordingly without updating the database files themselves.Artifacts modeled in design repositories can consist of many entities; fora point of reference, a power drill repository that has been developed con-tains over 250 entities. Not updating the database files each time an entityis created or modified eliminates many time-consuming calls to the datab-ase server, thereby saving a considerable amount of time. Once an editingsession is complete, the user compiles the text file into the database usingthe Design Repository Compiler that transfers the entire contents of thisformatted text file into a database in a batch operation.

The development of a new version of the system architecture has recentlybegun. The motivation and a more detailed description of the new architec-ture are discussed later in the paper.

4.2 Web-based design repository editorA formatted text file that follows the schemata for the data structuresdefined by the DL and DRL, can be created using any text editor. But thisis a very complicated and time-consuming task, which requires a designer


Figure 6 Architecture of the Design Repository Browser

to be familiar with the specific syntax of the design repository entities, tohave detailed knowledge about the artifact class hierarchies, the functionand flow taxonomies, and to expend considerable effort in maintainingconsistency within the data structures. To simplify the design repositorydevelopment process an intelligent web-based Design Repository Editorhas been implemented, which can be used via most common web browsers(e.g. Netscape Navigator or Microsoft Internet Explorer). This interfaceallows the user to define new classes, to create an artifact model by creatingobjects and relationships from existing classes, and to describe physical,functional and behavioral decompositions as well as the mappings betweenthem. Figure 7 shows the Design Repository Editor being used for twodifferent actions: the editing of the artifact class hierarchy [Figure 7(a)]and the creation of a new function object [Figure 7(b)].

All web pages created by the Design Repository Editor provide a point-and-click interface that allows the user to navigate across the stored dataand access the editor functionality. According to the DRL, the key entitiesof a design repository are objects (used to represent artifacts, functions,flows, behaviors, etc.) and relationships. The creation of a new function is


Figure 7 Web-based design

repository editor. (a) Editing

the artifact class hierarchy,

(b) creation of a new func-

tion object

easily accomplished by (1) selecting a class from which the function shouldbe instantiated by clicking on the appropriate item in the function classhierarchy, shown in the right-hand portion of the window in Figure 7(b),(2) naming the object, and (3) filling in the slots for the attributes andrelationships as required. The latter step includes inputting names of otherobjects and relationships to which the function should be linked.

The Design Repository Editor is an intelligent interface that removes muchof the burden from the designer. Its capabilities include:

I Automatic schema generation. When an object is instantiated from aclass, a form is automatically generated with the appropriate slots basedon the schema defined by the class description without requiring thedesigner to know a priori all the slots needed for the class.

I Automatic entity linking. When a link to an existing entity is specifiedby the designer, the data structures are automatically updated to reflectthose links. Thus, when the designer submits the form shown in Figure7(b), the current repository will be searched for each of the entitiesthat appear in the form and will create links to those entities if they


Figure 7 Continued

exist (note that the entity names in the figure are cut off, and appearto be the same although they are not).

I Automatic entity creation and to-do list. When a link to an entity isspecified and that entity does not exist, a ‘dummy’ entity is createdand named with the appropriate name. The editor maintains a to-dolist, which is a list of all items that were automatically generatedbecause they did not exist when links to them were specified. Theseare entities with empty slots that the designer still has to complete. Atany point, the designer can click on an entity name on the to-do list,resulting in a form being automatically generated with the appropriateslots based on the schema defined by the entity’s class.

I Partial entity creation. As can be seen at the bottom of Figure 7(b),the designer can check a box indicating that an entity that has beencreated is not yet complete. This will result in that entity being addedto the to-do list so that the designer does not forget to return and finishfilling out the required information.

I Automatic relationship entity creation, naming and linking. When, forexample, an artifact calledDrill—artifact—1 is created and thedesigner specifies that it has aHas—part relationship, all the designermust do is indicate the components into which that artifact is decom-posed. The entity for thatHas—part relationship is automatically cre-ated, namedDrill—artifact—1—has—part , and linked to theDrill—artifact—1 object (see Figure 2 for reference). Asbefore, if objects corresponding to those components already exist, theytoo are automatically linked to the relationship entity. If not, ‘dummy’objects are again created and added to the to-do list. Because the cre-ation of relationship entities is handled invisibly by the editor, thedesigner can specify physical, functional and behavioral hierarchieswithout ever having to explicitly deal with the data structures for therelationships.

The intelligent Design Repository Editor provides the designer with severalsignificant advantages. First, it encompasses a great deal of knowledgeabout the engineering context, which often translates into constraints onhow an artifact can be modeled, so that the designer is not required toremember all these constraints. Second, by maintaining a list of dummyobjects, the designer is not restricted to modeling an artifact in a specificsequence, but can create a model using a top down approach, a bottom upapproach, or a combination of the two moving back and forth betweenlevels of detail. Finally, not only does the automatic entity creation, namingand linking save time for the designer, it aids tremendously in consistencymaintenance by eliminating a significant portion of the errors that wouldoccur when manually creating a design repository using a text editor (e.g.


misspelling an entity name causing a broken link, or specifying a link toan object but forgetting to create it).

4.3 Web-based design repository browserThe other interface developed within the framework of this research is theDesign Repository Browser, which is the user interface to a design reposi-tory that allows the designer to navigate through an artifact representation.The Design Repository Browser extracts information about entities from adesign repository database where they are stored in object-oriented datastructures, and provides this information to the user.

Figure 8 shows a screenshot of the Design Repository Browser. The multi-frame window created by the Design Repository Browser enables the userto navigate across an existing design repository. Such a window can beaccessed via most web browsers and consists of four frames, one static (theupper frame which links to information about the NIST Design RepositoryProject) and three dynamic ones below that one.

In the three dynamic frames, each of the underlined names is a hyperlinkto a CGI script which retrieves information from a design repository datab-


Figure 8 Web-based Design

Repository Browser inter-

face

ase and updates the browser. The bottom left frame presents informationabout an entity in the design repository (this is the same kind of informationthat is shown in the text-based data structure shown in Figure 1). The usercan browse a repository by clicking any of the links in that entity. Thebrowser will then retrieve the information for that new entity and willupdate the browser view with the new entity. The middle right frame con-tains the history of the user’s browsing session, allowing the user to returnto any previously-viewed entity by clicking on an entity name. The bottomright frame includes a view of the appropriate hierarchy allowing the userto locate the selected object within the design structure. In this instance,the user is viewing an artifact object, so theHas—part artifact hierarchy(i.e. the physical decomposition) is shown. In this frame, too, the designercan jump to a different part of the artifact representation by clicking onan entity name. Within all three of the dynamic frames, hyperlinks to dif-ferent types of entities are color-coded, making it easier to distinguish themfrom one another.

4.4 Implementation exampleThe prototype design repository that has been used in the examples in thispaper represents the Black & Decker VP840 cordless power drill. Thisrepository was created using the Design Repository Editor and contains 28artifact objects (assemblies, subassemblies and components) and over 250additional entities (objects and relationships) belonging to 64 classes andsix relationship classes. Most of the objects were not created explicitly bythe designer, but were initially generated automatically as ‘dummy’ objectsand then completed with detailed descriptions by the user. Similarly allrelationships were created automatically by the editor as described pre-viously. The generic artifact class hierarchy is shown in Figure 7(a). Thehierarchies corresponding to the physical and functional decomposition ofthe power drill are shown in Figures 7(b) and 8 respectively. Figure 9shows the visualization of the geometry of the modeled product, stored inVRML format. This three-dimensional model can be manipulated, rotated,translated, rescaled, etc.

5 Summary and future researchThe practical use of design repositories in industry requires an informationmodeling framework (including a modeling language to formalize engin-eering knowledge and model engineering artifacts), and a computationalplatform to create, store, and access this knowledge. In the framework ofthe NIST Design Repository Project, the data language and the designrepresentation language have been developed to define data structures thatdescribe the engineering context and model artifacts in a design domain.This allows the representation of artifacts, functions, flows, relationships


and other entities described in previous sections in the formatted text.

Initial work has been done in developing a comprehensive taxonomy of

functions and associated flows. The existing taxonomies can be extended

with new terms or new domains using the data structures that have been

established. Finally web-based interfaces were implemented to facilitate

the creation and navigation of design information by distributed users via

the Internet. To illustrate the functionality of the modeling framework an

example repository was described.

The basic research in the area of design repositories that has been conduc-

ted in the framework of the NIST Design Repository Project focuses on

development of knowledge representations and a computational platform

for data handling via the World Wide Web. The motivation for developing

design repositories (rather than traditional design databases), was discussed

in the introduction of this paper. However, the current implementation

described in section 4 still makes use of traditional database technology

for information storage. Currently, this limits the locations of design

repositories to single sources where database servers are available. Future


Figure 9 VRML-based vis-

ualization of the power

drill geometry

27 World Wide Web Consor-tium Extensible markup langu-age (XML) 1.0 World Wide WebConsortium (W3C) Recommen-dation, February (1998)

emphasis will be placed on taking greater advantage of the distributednature of the World Wide Web by distributing design repositories to agreater extent.

The new system architecture will differ from the current one in two sig-nificant ways. Both of these changes are strongly motivated by the needsof engineering industry. The first is a migration from the current repositorytext file format to an Extensible Markup Language27 (XML)-based fileformat. The motivation for this is that the schemata used to represent infor-mation in the current format are not readily used other than by applicationsdeveloped as part of this project by people with knowledge about the for-mat. In contrast, XML has the advantage of widespread adoption in theinformation technology world and appears to be on its way to becominga World Wide Web Consortium (W3C) standard. Third-party XML parsers,compilers, and authoring tools exist and/or are under development, andbuilt-in XML support is expected in upcoming versions of several commer-cial web browsers and word processing applications. This change willresult in a more broad-based solution for the engineering industry, in whichcompanies are increasingly looking towards purchase of off-the-shelfsoftware over in-house development when possible.

The second change is the decoupling of the Design Repository Projectediting and browsing tools from the database system. The XML-based arti-fact text file will be able to act as a self-contained database, allowingbrowsing and editing of artifact repositories without requiring a commer-cial database management system (DBMS). One advantage is that forsmall-scale applications, a company will not have to invest in a DBMS toimplement design repositories.

For large-scale applications, DBMSs are quite useful for management oflarge amounts of data, providing capabilities such as transaction manage-ment, consistency maintenance, distributed databases, synchronization ofmirrored databases, information caching, and more. In these cases, data-bases can be used as back-end applications even with an XML-based rep-resentation. The planned decoupling is still desirable because the use ofthe Design Repository Project tools will not tie a company to a singlespecific commercial database vendor. Rather, the XML file would act asa generic format, while interfaces could be developed to exchange infor-mation between an XML file and various other commercial DBMS sys-tems. At present, some commercial database vendors are developing XMLinterfaces to their databases, freeing the industry user from this implemen-tational burden.


28 Iwasaki, Y, Farquhar, A,Fikes, R and Rice, J ‘A web-based compositional modelingsystem for sharing of physicalknowledge’ Proceedings of the15th International Joint Confer-ence on Artificial IntelligenceAAAI Press (1997) pp 494–50029 Chouiery, B Y, McIlraith,S, Iwasaki, Y et al ‘Thoughts ona practical theory of reformul-ation for reasoning about physi-cal systems’ Proceedings of theSymposium on Abstraction,Reformulation, and Approxi-mation (SARA ’98) (1998) pp25–3630 Ling, S R, Kim, J, Will, Pand Luo, P ‘Active catalog:searching and using cataloginformation in internet-baseddesign’ Proceedings of the 1997ASME Design EngineeringTechnical Conferences PaperNo. DETC97/CIE-4292, Sacra-mento, California, September(1997)31 Coutinhi, M, Eleish, R,Kim, J, Kumar, V, Ling, S R,Neches, R and Will, P ‘Activecatalogs: integrated support forcomponent engineering’ Pro-ceedings of the 1998 ASMEDesign Engineering TechnicalConferences Paper No.DETC98/CIE-5521, Sacra-mento, CA, September (1998)

Another important possibility falls out from this new architecture: theability for companies that are using design repository technologies to shareand exchange artifact data even if they use different database systems in-house, by using the XML-based artifact representation as a neutral fileformat for information transfer. As industry relies more and more on part-nerships and outsourcing with other companies, interoperability across cor-porate boundaries and the ability to exchange design knowledge (not justgeometry) becomes increasingly important. This solution will help provideinteroperability without requiring partners to adopt the same DBMSs in-house.

A new software/communications architecture is being developed for theXML-based implementation of the Design Repository Project. This systemwill consist of a kernel that acts as a server of XML data. The implemen-tation will be done in Java, and will consist of a combination of Javaapplets and a servlet (the server-side equivalent of a Java applet). Unlikethe CGI scripts that create processes of short duration for each data access,the servlet will act as a server that runs continuously, allowing server-sidecaching of data to speed up access. The browser and editor interfaces forthe new implementation are undergoing a redesign to provide the user withinformation in a more effective manner.

As part of the re-implementation effort, the schemata that have beendeveloped for representation of design artifact knowledge are being revisedin order to simplify the task of artifact modeling knowledge capture andto improve the way in which knowledge is organized. Longer-term researchobjectives include the expansion of the schemata to include informationthat is not currently captured. Although the current system includes a physi-cal decomposition of an artifact into subassemblies and components, thisdecomposition does not comprise a detailed assembly model. Informationabout the kinds of part matings, kinematic joints, and constraints is notcurrently captured. Other desirable knowledge includes tolerance infor-mation, and a more formal representation of behavior that will allow com-posable simulations.

Work in the latter area has been done as part of two projects funded bythe Defense Advanced Research Projects Agency (DARPA) Rapid DesignExploration and Optimization (RaDEO) program, for which NIST is afunding agent: the Model-Based Support of Distributed CollaborativeDesign (previously How Things Work) project at the Stanford UniversityKnowledge Systems Laboratory28,29, and the Active Catalog project at theUniversity of Southern California Information Sciences Institute30,31. Thebehavior representation languages developed in these projects are among


the options being considered for representing behavior within the NISTDesign Repository Project.

Once the second generation of the design repository system has beenimplemented, a priority will be to obtain an initial validation of the work,(both the representations and the interfaces that have been developed). Thiswill be done by finding external users such as industry partners to testthe system by modeling real-world engineering artifacts. Discussions withfaculty in academia have also taken place to explore the possibility of usingthe design repository tools to capture design artifact knowledge as part ofa project in a design course. In addition to identifying any weaknesses inthe system, these validation exercises would have the added benefit ofproviding additional example repositories.

Notes1 Just as the word ‘database’ can refer to either a database management system or an individual informationstore and its content, in this paper the term ‘design repository’ will be used to describe both the modelingsystem (underlying representation, interfaces and mechanisms) as well as a specific design artifact modeland its content. The intended meaning in a particular instance should be clear from the surrounding context.2 In general usage, the word ‘object’ is usually used to describe any of a number of types of entities in anobject-oriented system. In this work, however, the term refers to a specific kind of data item, and thusrelationships are not referred to as ‘objects’ though they might be considered objects in the generic sense.Because of this distinction, the term ‘entity’ is used to refer to the four types of data items.3 Recall that as described previously, the data language is generic and can be applied to any of manydomains. Although the example shown in the figure has attributes and values that associate the object withan engineering artifact, there is nothing within the generic object schema that restricts it to this domain. Thebasic object schema could just as easily be used to represent an employee in a corporate personnel databa-se.4 Artifacts are a type of object and will be described later in detail in the section on the design represen-tation language.5 The term ‘flow’ in this work is used in a sense similar to that proposed by Pahl and Beitz26, referring tothe flow of materials, energy and information.6 Not to be confused with a web browser, the Design Repository Browser is the user interface to a designrepository that allows the designer to navigate through an artifact representation. The Design RepositoryBrowser is a web-based interface that runs within a web browser.7 Use of any commercial product or company names in this paper is intended to provide readers withinformation regarding the implementation of the research described, and does not imply recommendationor endorsement by the National Institute of Standards and Technology.


Documents

A web-based system for design artifact modeling