No CrossRef data available.
Knowledge-rich catalog services for engineering design
Published online by Cambridge University Press: 01 November 2003
Abstract
The exponential growth of the Internet and increasing communication and computational power have created many opportunities for advancing engineering, manufacturing, and business activities. Among them are electronic catalogs. These have become basic information resources to a number of people, ranging from shoppers looking for personal items to engineers selecting electromechanical parts to build a product. Although rich in content, current catalog systems are limited both in search quality and in realizing the full potential of the retrieved information. The active catalog system brings a conceptually new idea to electronic commerce by providing a new, computationally usable, catalog information environment about components and their use in applications. It utilizes a rich body of domain knowledge to facilitate access and retrieval of component information. The utility of retrieved information is enhanced by using it to rapidly construct simulation programs and test alternatives, supporting a “try before you buy” paradigm in which users evaluate candidate components within simulations of their design. We describe services provided in the active catalog system to support engineers in selecting and evaluating electromechanical components and subsystems. The services include mechanisms for creating queries for parts based on their intended use rather than merely parametric specifications, refining those queries to take account of constraints imposed by domain knowledge, providing multimodal information to help engineers assess and compare candidate parts, and generating simulation models for candidate parts and integrating them to provide simulation models for candidate systems.
Information
- Type
- Research Article
- Information
- Copyright
- 2003 Cambridge University Press
1. INTRODUCTION
A catalog is a basic resource for a number of types of people and disciplines, ranging from people shopping for personal items to engineers selecting electromechanical parts for their design. For example, engineers often spend a large amount of time obtaining information about components from catalogs so as to evaluate trade-offs with respect to design requirements. In fact, studies have shown that 80% of their time goes NOT into the design activities for which they were trained but rather into assorted information management tasks (Will, 1991), including scanning through catalogs.
Catalog information has traditionally been in paper form and is undergoing rapid revolution in content and presentation because of the existence of the Internet and the World Wide Web. For engineering parts, Thomas Register (Thomas Register, 2003), PartNet (PartNet, 1998), and Micromo (Micromo, 2003) are examples of catalog services available on the Web. Although it would be nice if the information in these catalogs was easily and conveniently accessible to the customer (i.e., data is reachable and usable), this assumption does not hold in general. Although rich in content, today's catalogs still do not provide adequate search capability (Kim et al., 1997). There have been approaches for providing more flexible database query capabilities (Arens et al., 1998), but they have not been fully exploited in engineering contexts. In addition, existing catalog contents are designed to be consumed by a human reading a document or looking at an image.
In fact, a gap exists between the high-level, conceptual mental model of a product needed by a customer and the low-level, physical database query that retrieves the needed information from a catalog. Too often, customers are required to mentally map their description of a desired component onto the set of searchable attributes recognized by the catalog system. That is, users essentially need to understand the “schema” and the searchable technical attributes of the catalog contents before they can translate a need expressed in their terms into a set of queries expressed in the system's terms. For example, to find a light motor for a high oxygen environment, one of the possible Structured Query Language (SQL) queries to retrieve the motors might look like “SELECT * FROM Motor, Environment WHERE Motor.weight [lE ]1.0 AND Motor.brushType = Environment.brushType AND Environment.OxygenLevel [gE ] 20.” Even for this simple example, the mapping is not trivial. It requires the mapping of the light and high oxygen requirements into the numerical attributes in the query. It requires a “join” SQL linking the attributes of two tables, Motor and Environment. This type of mapping imposes a major burden on users, deflecting them from focusing directly on meeting their requirements. In addition, searching for that type of motor may involve looking for all of the different names that different manufacturers use for a motor of that type. Searching for other mechanical parts such as hangers and brackets is even harder because there is no simple set of universally accepted names for the component, as there is at least conceptually for a motor, usually a part that rotates.
There are also problems in using the information in the design environment. For example, to determine the suitability of a component, designers must assess its electrical and mechanical performance and its use with other components. This is equally onerous, and often involves manually transcribing the catalog information into the local design tool environment.
Our catalog system, called the active catalog system (Luo & Will, 1996; Kim et al., 1997; Ling et al., 1997; Coutinho et al., 1998), addresses the above problems by using a rich body of domain knowledge to describe the catalog components, adding to and annotating traditional catalogs with multimodal technical information, and aiding the use of the retrieved information by providing a dynamic simulation environment. Although our work is illustrated in the engineering design domain, the approach is suitable for more general applications involving configuration activity (e.g., configuring cars, designing office environment, finding matching clothing, etc.).
Designers using the active catalog system can search catalog contents using the familiar terminology of the design domain. A search engine, based on the knowledge of the domain and the meaning of the queries specified in the domain vocabulary, accesses catalog components that satisfy the functionality meant by the queries, rather than by matching the keywords or synonyms in the queries. In addition, the active catalog system, as suggested by its name, adds to traditional catalog contents (such as textual and image information) a rich set of models of different types that, in turn, allow a designer to evaluate the dynamic and behavioral aspects of a component in a system via an interactive simulation built from or using downloaded models, viewers, or simulation code.
The active catalog system helps designers find and evaluate candidate parts for components of their system designs. This general approach is illustrated in Figure 1. The goal is to help designers state part-level or system-level constraints that candidate parts should meet, to find candidates, and to then return information that helps designers evaluate how the candidates will work together in the system design. The key concept is “try before you buy.” The information returned includes not just the static data found in catalogs today but also behavioral information, including simulations and other active objects such as graphical animations.1
Extensions are also envisioned to provide information bearing on design for affordability and design for rapid production, such as cost, suppliers, and other procurement data.
The active catalog system as a design workspace.
The basic concept is to provide, or augment, a workspace in which a designer lays out the abstract components of a design. The active catalog system augments the workspace by letting designers express constraints on, or between, component parts by using the search interface leveraged by underlying requirement ontology. On request, the collected constraints on a part can be folded into queries that retrieve candidates. For those candidates of interest to the designer, the active catalog system retrieves technical specifications and simulation models or, in a number of cases, actively generates the models. The models can cover electrical, mechanical, kinematic, dynamic, thermal, magnetic, and optical modalities.
Designers can use these models to evaluate candidates for individual parts or interactions between multiple candidates in the evaluation interface. As they get better insight into their requirements from these evaluations, they can iterate the process to refine the constraints and narrow the set of candidates. When they are satisfied, the result is a bill of materials (and potential substitutes) that is known to fit the requirements. The system can also automatically produce a recorded documentation of the design rationale, including the factors that went into selecting the parts. We plan to explore this option further in the future.
In this paper, we primarily focus on how we help users formulate queries and express constraints. In contrast to the case-based approach (Sycara et al., 1992; Wood & Agogino, 1996; Goel et al., 1997), in which the system uses a case library to map an abstract description of the device into relevant designs, we use domain ontologies to help users formulate queries for finding components as well as to help them map high-level requirement into explicit component information. For example, we help users understand what they can say by setting up forms and showing what fillings are possible based on constraints of the ontology.
The active catalog system has been used in supporting gimbal2
A gimbal is a device for permitting a body to incline freely in all directions, or for suspending anything, as an aircraft's compass, barometer, and so forth, so that it will remain plumb (level) when its support is tipped, as by the moving of an aircraft. It consists of a ring in which the body can turn on an axis through a diameter of the ring, while the ring itself is so pivoted to its support that it can turn about a diameter at right angles to the first.
The following sections present our approach and illustrate key technical capabilities in the context of gimbal design. We start with capabilities pertaining to constraint-based specification of parts requirements for retrieval purposes (Section 2) and then describe the tools for generating and presenting active objects such as animation models and simulations (Section 3). Section 4 describes our lessons learned from building the system. Then Section 5 describes related work, including current approaches to providing catalog information. Finally, as summary and future works are presented in Section 6.
2. ONTOLOGY-BASED COMPONENT SEARCH CAPABILITIES
Figure 2 illustrates how our search system works. Our work on retrieval is based on a domain theory (sometimes also called an ontology), which is used to map user requirements into database queries. We built a structure of terms useful for specifying the component requirements and also built rules/axioms to exploit constraints among the components during the query processing. The current domain knowledge has been built from interviews with engineers (in-house experts and some collaborators in the DARPA RADEO program) as well as engineering textbooks. This domain knowledge wraps the component database and enables the users to specify their requirements at a conceptual level.
The way in which the search system works in helping designers find candidate parts that meet the design constraints.
There are at least three advantages to utilizing a rich body of domain knowledge to facilitate access to the database content as in the active catalog system. First, the user request does not have to rely on part numbers and keywords. A high-level request is automatically expanded to a query to access the database. In addition, when there are potential interactions among different aspects of the high-level requirements, the constraints imposed by them can be used in generating the output results. Finally, users do not have to keep track of what is newly added or deleted in the underlying database. The system can maintain the valid results for the user requirement. For just simple addition or deletion of items in database tables, the query is reexecuted. If there is a change in the schema of a table, a new SQL query may be generated from the same high-level requirements.
Technical challenges addressed concern the form in which these constraints are expressed, mechanisms for inferring constraints, interfaces to help designers express constraints, and methods for translating the constraints into productive queries on sources of parts information.
The search function in the active catalog system maps a high-level, conceptual model of components that are needed by customers into physical database queries. That is, it performs an inference of what attributes in what tables in the database are relevant to an implicit requirement that is given by the user. Moreover, when a user provides multiple different types of requirements, the system combines the given requirements by finding consistent component requirements based on the inference results.
To perform these functions, our ontology system provides several subfeatures.
- Mapping: Each “requirement” concept in our ontology is defined in such a way that it can be mapped into a particular component type and/or a set of attribute constraints. For example, a requirement about a motor function may be translated into a particular type of motor that can achieve that function.
- Combining: There are multiple subontologies for multiple aspects of components. Using these subontologies, a user can create queries that combine different types of requirements. Multiple requirements can be combined by first applying the first subfeature (the mapping) to the requirements and then adding constraints from potential interaction among the requirements. For example, if a user's requirements consist of a component type, the application of the component and the environment in which the component should operate, these three different requirements are combined by a logical conjunction of inference results from their interactions and the three mappings. To give an example of such interactions among high-level requirements, suppose that an engineer is designing a system for a space mission. He or she needs to consider various factors including safety in the high oxygen environment such as the potential for explosions and temperature changes. These factors will constrain the type of components that can be used, such as brushless motors and motors with high thermal resistance.
- Translation: We provide a translation table that maps the intermediate results (specific part type and attribute constraints) into database tables and their attribute constraints.
The following sections discuss each of these subfeatures in turn.
2.1. Mapping a user requirement into part types and attribute constraints
This section describes how the active catalog system maps very high-level functional requirements into alternative sets of technical characteristics that might satisfy them. The system exploits underlying domain knowledge to provide a friendly form for accepting requirements and mapping them to appropriate part types and attribute constraints that satisfy the requirements.
Figure 3 shows the interface for accepting user requirements using an adaptive form (Frank & Szekely, 1998). There is a two-step process that converts the ontologies into a requirements interface. First, the ontologies are converted into a Backus–Naur Form (BNF) format that can be accepted by adaptive forms, and then the interface is automatically generated from a description of options in the BNF form. That is, the interface and the choices at the bottom of the active catalog search window in Figure 3 are generated from domain knowledge.3
Because the mapping between the product ontology and the BNF form is straightforward, we are developing a module that generates adaptive forms automatically from the knowledge base.
The interface for accepting user requirements.
The domain ontology is represented in LOOM (MacGregor, 1990, 1994), a knowledge representation language and environment in the Knowledge Language One (KL-one) family. LOOM provides powerful deductive services (i.e., classifier) that organize concepts and relations into a taxonomy/network by computing subsumption relations between concept descriptions (to determine when one definition implies another) and checks consistency. For example, descriptions of different motor types can be organized into a motor ontology. It also provides a query language and deductive query processing.
Given the input requirement as described above (e.g., motors that can be used for an application in high oxygen level environment), the active catalog system composes a LOOM query with a list of conditions to be satisfied based on the input. The query is used to find appropriate component types and attribute constraints. For example, the above input is translated into the following:
The active catalog system, assuming that the components should be safe to use in the given environment of an application, automatically adds the last two conditions.
The mapping relies on LOOM queries to the active catalog knowledge base. It is done in the context of finding a general component type, such as motors. If the given requirement is already about component type or attribute constraints, then there is no need for a translation, and the procedure passes it to the next step without change. Otherwise, the procedure applies a chain of rules to retrieve the implications of the requirement until it finds component types and/or attribute constraints implied by the requirement.
In the process of answering the query, the user requirement is mapped to component types or attribute constraints that satisfy the conditions using a subnetwork in the component ontology and the axioms associated with it, as shown in Figure 4. (The details of the ontology are given in Section 2.2.) First, from axioms 1 and 2 and the closed-world assumption, the system infers that brushes incur sparks in the explosive environment and a motor with brushes is not safe. Then, by applying axioms 3 and 4, the system infers that brush motors (motors with brushes) are not safe for a high oxygen level environment (a kind of explosive environment). Finally, by using axiom (5), the mapping function returns brushless motors.
Finding motors for a high oxygen level environment: (a) example subontology and (b) example axioms.
Because LOOM supports queries returning instances, to directly use the LOOM queries in searching for components, the active catalog system currently exploits prototype instances defined for component classes. That is, the system determines the component types (such as brushless motors) that satisfy the query condition based on these instances. If there are more than one component types satisfying the user requirement, they are combined by logical disjunctions.
Some of the user requirements can be mapped to attribute constraints. For example, if a user chooses “pancake motors” in the input form, then it can be translated into “width <1.5 in.” These constraints are used together with other attribute constraints specified by the user.
This approach has several potential benefits. Because the mapping is done with general rules and constraints, it is automatically applicable whenever the database is updated (e.g., by adding new parts information), without requiring explicit updates about what newly added parts are good for. If the engineer knows that he or she wants to use brushless from the beginning, then that simplifies the mapping but may overconstrain the choices. Because we maintain more knowledge than an individual user, we can assist designers in finding potential results that they might have missed as a result of not being aware of all possible mapping methods.
2.2. Combining multiple sources requirements
In addition to helping users formulate queries by mapping high-level requests into the catalogs' terminology, the active catalog system helps users when they need parts to satisfy multiple constraints. This section describes how the system allows users to describe multiple different requirements.
The system defines multiple subontologies for different aspects of user requirements, thus supporting multiple ways of describing components. They are connected to the component taxonomy and attribute taxonomy directly or indirectly. Figure 5 shows a part of these additional subontologies together with component taxonomy and attribute taxonomy. We have built a taxonomy of electromechanical components, including an extensive hierarchy of various motors and pumps. We have also built a taxonomy of attributes of the components. Those attributes are used for describing attribute constraints in the search. Currently, we have 300 classes of pumps, 3000 attributes for pumps (Luo & Will, 1996), 72 classes of motors, and 66 attributes of motors (Coutinho et al., 1998).
The subparts of the active catalogs ontology.
We provide a semantic network of applications, intertwined with component and attribute taxonomies. As described earlier, each application can be mapped to a set of component types in a search context. Manufacturers of components include “application notes” as part of their catalogs or perhaps as part of their customer support information. These notes show the use of the component in its most usual application as well as some examples of unusual uses that may in turn generate new business. Given a specific component, users may see the potential application of the component, following the link between component types and applications. If a past application is stored in the database, users can refer to the details. Our function ontology also classifies the components in terms of their generic functions. As shown in Figure 5, amplify power, amplify voltage, and amplify current are subclasses of class amplify, and these classes can be used for finding different kinds of amplifiers.
Using these ontologies, more complex high-level queries as well as simple database-type queries are supported:
- Queries on component types: Users can specify a particular type of component in their searches. For example, user can choose “DC motor,” “Servo motor,” and “DC servo motor.”
- Queries on properties of the component: Users can specify geometric properties (e.g., height, width, length, size), electrical properties (e.g., peak torque and peak current of a motor), and so forth of a particular component type.
- Queries on environments in which to use the component: For example, users can describe temperature, gravity, elevation, explosiveness (e.g., high oxygen level), and corrosiveness (e.g., corrosive fluid for pump) of the environment in which the component will be used.
- Queries on applications: For some cases, it is easier to describe the applications of components than the particular component type and its properties. For example, for servo control in a gimbal system, pancake motors are often used.
- Queries on functions: As in the applications, the functions of components can determine a particular component type. For example, there are certain pumps appropriate for accomplishing different functions, such as draining, circulating, spraying, distilling, and so forth.
These requirements can be expressed separately or in a combination.
The system first computes the implications of the given requirements separately based on requirement types. Then it collects component types and attribute constraints from the implications. Finally, they are combined through logical conjunctions to produce specific component types and their attribute constraints. For example, if there are two mapping results, brushless motor type and DC motor type, then they are combined into the intersection of the two types (DC brushless motor), which is also the common subclass of the two in this case. At present, we do not provide a mechanism for handling conflicting requirements; we leave it as a future extension.
2.3. Translation: creating database queries and retrieving results
The preceding sections showed how the active catalog system helps reexpress high-level requests and combine multiple requests. These reformulations of user requests are expressed in terms of component types and constraints on their attributes. The last step is the translation of component type and user attribute constraints into a database query that connects to component data in the actual catalogs.
To perform this subfunction, we built a translation table (called a metadescription). This table has mappings between component types and database tables. In addition, it has mappings between the general attribute names used by users and the attribute names in the database tables, which use the names used by the data providers. This addresses the issue that different manufacturers may use different names for what are actually conceptually equivalent devices or device attributes. This mechanism provides mappings between a representative name preferred by the user and the other names. (The current implementation translates the general terms commonly used by engineers to terms used by data providers, but we are planning to extend the translation table to support different terms used by different engineers.) Using this information a database query is created from component type and attribute constraints. The active catalog system uses an Oracle database, and this process creates SQL queries such as “select * from TableName where Constraints,” where TableName is the translated database table name and Constraints is the combination of the translated constraints through conjunctions. If there are multiple database tables that contain instances satisfying the user requirements, they can be retrieved together.
Figure 6 shows the interface for displaying translation results. The subwindow labeled “SQL command” shows the translated SQL query, and the “Search Criteria” window lists the attributes in the table and their constraints in the query. The database retrieval results are displayed in a “Search Results” frame. The table in the frame lists all the candidates that satisfy all the requirements.
The user interface for modifying the attribute constraints and retrieving database results.
Once designers have narrowed down the search space by introducing their high-level requirements (that are often incomplete) and the desired features become clearer to them, they may often want to present some more low-level requirements and explore candidates at a detailed level. For example, they may want to see what other components are available when they relax some constraints, or they may want to find more appropriate components by adding more constraints. This type of search is quite common in design activities, where a high-level top-down exploration is supplemented by bottom-up refinement of the search. In addition, during searches, the users sometimes want to focus on particular subset of features instead of all available attributes in the database. Our interface has features that support such flexibility. Users can add, delete, and modify the constraints to check the “neighbors” and they can compare the results for a subset of attributes.
The “View Detail” button invokes a display for details in different modality, including images, application notes, and dynamic models. The details of this feature are explained in Section 3.1.
Finally, when the user is satisfied with a set of candidates, he or she can send the results to other system modules by pressing the “Export Selections” button.
3. ASSESSING CANDIDATES
The active catalog system supplements a regular database with an augmented database to store metadata information. In this section, we illustrate what this would look like in a design context and how to make it useful to designers.
3.1. Multimodal information
The active catalog system provides part data in various modalities and data formats. For example, to determine the suitability of a servocontrol motor for a gimbal design, the engineer must assess its electrical requirements and mechanical performance, such as its power consumption and its peak torque. To determine whether a standard engineering part can actually meet the design requirements of a system, an engineer must evaluate the properties of the system, such as speed, torque-rise time, and stability. However, the mechanical and electrical evaluations are not enough. Weight and volume are important: because a motor is mounted in a gimbal frame, the engineer must determine whether the outside diameter of the inner gimbal motor can fit into the inside diameter of the outer gimbal motor. A motor also has its own weight; if it is to be mounted in an airplane or missile, the engineer must be sure that the weight of the motor does not violate its allocation in the total payload of the system.
Although many of these properties can be viewed as database parameters and displayed in attribute/value pairs, engineers need other information and displays to give them comprehensive pictures of the parts. Engineers would like to see a cross-sectional view or a 2-dimensional drawing of the motor, showing the relationships of the rotor and stator within the motor as well as its inside and outside diameters. The relationships of the rotor and stator are not explicit in database tables. In drawings, engineers can find the location of the mounting holes and the electrical terminal connections, which are missing and hard to present in a table. Other useful types of information include application notes describing how a part can be used, images showing various components of a part, and wiring diagrams showing the electrical connections and wiring, and so forth.
Most current on-line catalogs focus on providing technical parameters of parts in terms structured for databases and tables. Engineers have to rely on other sources such as talking to the part manufacturers directly in order to obtain other information that they need. The active catalog system gathers and collates multimodal information about parts so that engineers can access all the information in one place. This capability reduces the amount of time and effort spent by engineers in searching for and evaluating parts.
To provide this multimodality capability, the active catalog system supplements a regular database of parameter data with a special database to store multimodal information about parts. In addition, metadata information is provided. The active catalog system uses the metadata to identify the relevant data formats and to provide appropriate displays. To provide an integrated display of multimodal information, a window frame with separate folders for different information modes is used to display individual parts. For example, Figure 7 shows two windows, each representing a different candidate part under consideration for use as a servo motor. In one window, the user has asked to see the motor's properties displayed in a table format, including additional information about windings. In the other window, the user has asked to see the other motor displayed as a drawing. By clicking different buttons, engineers can switch between the different types of information available and can easily compare information about alternative parts. If they want to compare the degree of difficulty in the installation of two motors, they can look at their drawings and the application notes by putting the two windows for these motors side by side.
A display of multimodal component information.
3.2. Active models, retrieved or generated
Although multimodal technical information such as text, database data, images, and drawing files is useful, engineers need dynamic information to assess the performance of parts. In addition to providing multimodal static information, we also provide active and executable simulation models of various modalities. For example, an engineer might need to find out how fast a motor can rotate to a new equilibrium position when it is subjected to an input signal. One way of finding out is by applying a physical signal to the motor and observing the motor's behavior. However, physical testing of a motor is costly. In many cases, motors may not be available for testing. A practical alternative is to test the behavior of the motor in a simulation program, as is common in current engineering practice. However, developing such simulation programs requires programming expertise from engineers. It is a tedious and time-consuming process. Finally, engineers may not have enough knowledge about the parts to be able to develop accurate simulation models for parts.
Current catalogs, whether on-line or paper, do not provide simulation models. A key feature of the active catalog system is its ability to provide simulation models, either hand coded or automatically instantiated. The system generates simulation models “on the fly” from database parameters. Motors have a well-known theory of operation, and the parameters used in manufacturers' catalogs generally relate to that theory. The motor theory has rotor resistance and inductance, a back electromagnetic frequency coefficient, a constant velocity output torque to input current, an inertia and friction, and so forth. This information, combined with the load torque and inertia, is enough to generate differential equations and Laplace transforms of a motor plus load.
We have built generic models that we can combine with parameters from a manufacturer to automatically produce MATLAB (2003) models. Our approach to generating a motor simulation model is a two-step process: create a generic model for a class of parts and queries, and instantiate a model for a specific part from the generic model by substituting parameter values of the chosen part. In the domain of servocontrol motors, a common problem is to study the angular rotation of a motor in response to an input signal and there is a domain theory for solving this problem. A generic model for this problem is built manually based on the domain theory and is expressed as a MATLAB/Simulink model. A model usually requires parameter values such as specific value of resistance, inductance, and so forth. However, in this generic model, they are only symbols corresponding to the attributes in a motor database. When a particular motor is selected, the active catalog system retrieves the parameter values from the motor database, substitutes the symbols in the generic model with the specific parameter values from the database, and then produces a specific model for that motor. The process of automatically instantiating models for a specific part from a generic model is shown in Figure 8.
The automated instantiations of a specific part model.
After a model is selected, the system can launch that model with appropriate simulators and display its behavior. Figure 9 illustrates this point. It shows a MATLAB S-plane dynamic simulation model of a servocontrol motor and a VRML animation model that breaks apart the subcomponents of that same motor.
The simulation interface.
The approach of automatically generating a model for a motor assumes the existence of a generic model that can simulate the behavior of a class of motors. The accuracy and the scope of the generic model affect the accuracy of generated models and the utility of the approach. If the generic model is valid for a broad class of motors, the approach will be useful to engineers because it can generate a wide range of models for their design. We believe that for many engineering parts found in catalogs, this assumption is valid. However, in some engineering design cases, this approach needs to be applied more carefully. For example, the hydrodynamic simulation of a ship hull depends on its shape. A slight change in a shape can result in dramatic changes in simulation behavior, requiring a totally different simulation model.
The active catalog system provides models in multiple modalities. In addition to control simulation models, VRML animation models are provided showing the spatial and geometry aspects of a motor. These animation models help engineers understand spatial and configuration aspects of parts within a system. Other model types include kinematics and dynamic models in Working Model (2003) that address mechanical engineering aspects. By making a range of models available, the system provides the engineers with an environment to explore a part as if the part was physically in front of them.
4. LESSONS LEARNED
The active catalog system has demonstrated its strengths by letting users, including engineers at Lockheed Martin, access its library through a set of queries. From these exercises we have found that the active catalog system may help users more when designers have a set of high-level constraints to be considered in finding appropriate components and explicit description of low-level constraints are not available in the beginning, there are a large number of options so designers can easily overlook possible candidates, and the components should be thoroughly evaluated before use. However, if the given task is very simple and has a small number of candidates, then the active catalog system may not provide much help.
The weakness of the ontology-based search is that it is very knowledge intensive and heavily dependent on the kinds of knowledge acquired from domain experts. It was not trivial to translate what engineers had in mind into a formal representation and link it with other information sources, such as an existing catalog library. In addition, a main bottleneck of building part models and supporting interoperability of models in multiple domains was the acquisition of such knowledge from domain experts and books. However, recent evaluations in the DARPA High Performance Knowledge Base program (Cohen et al., 1998) and the Rapid Knowledge Formation program show promising results where appropriate knowledge acquisition tools and interfaces enable end users who do not have computer science background to add a sizeable amount of domain knowledge with about a week of training (Kim & Gil, 2000a, 2000b; Barker et al., 2003).
Another problem is maintaining the component knowledge base after the initial prototypes are developed. It is very rare for the knowledge base to not need any subsequent changes or extensions that naturally happen with real-world applications. Some modifications are very hard and can be equivalent to the effort of building a whole new knowledge base. We are looking at several techniques that address this problem. The approaches include predetermining knowledge roles (Marcus & McDermott, 1989), deriving or coding interdependency among different parts in the knowledge base (Eriksson et al., 1995; Swartout & Gil, 1995), using a set of modification scripts (Tallis, 1999), and so forth. In addition, we are finding ways to make sure that new additions, deletions, or modifications do not break the existing knowledge base or interfere with solving a set of known problems. We can draw from existing techniques for knowledge base verification and validation that detect and resolve problems in knowledge bases (O'Keefe & O'Leary, 1993; Preece, 1995; Kim & Gil, 2001).
5. RELATED WORK
The past couple of years have seen increasing interest in providing on-line catalogs to designers and engineers via the Internet and World Wide Web. Currently, engineers can find on-line catalog data in three different forms:
- General Web search services: Engineers go to general search engine Web sites, such as Yahoo (2003), Google (2003), and InfoSeek (1998) and try to find the parts that they need by using services of these Web sites specialized for locating companies. The users enter a list of keywords describing their search requirements. The Web site returns a list of part manufacturers' Web sites that might contain technical information on the parts. Our experience with these search engine Web sites is that they usually do not provide specific or comprehensive pointers that meet engineers' needs (Ling et al., 1997). The number of company Web pointers is usually less than the number available from dedicated part catalog services, and many company Web pages do not provide any technical part information. In some cases the services retrieve a large number of items, but many of the results are irrelevant to the user's goal. For example, in finding “DC motor,” many results point to Web sites for automobiles instead of the electromechanical part “motor.” Moreover, to make matters worse, there are enormous amounts of redundancies and broken links in the results.
- Dedicated parts catalog referral services: These are services dedicated to finding companies that can provide parts for engineers. The Thomas Register (2003) is one example of this service. Like general search engine Web sites, engineers enter a list of key words into the Thomas Register system (Thomas Register, 2003) and it returns a list of company contact information containing the technical “part” information. Compared to general Web search services, Thomas Register focuses on providing a comprehensive list of companies. The companies are also specific and relevant to the needs of engineers. However, they rely heavily on keyword-based string matches, and their component information is limited to pictures and text descriptions.
- Centralized part catalogs: Instead of providing referral service to part manufacturer Web pages, this service centralizes all the technical part information together at a single site. Users go directly to the site to acquire, select, and purchase parts, as in PartNet (1998). The technical information of parts is more organized and uniformly presented than individual company manufacturer or distributor Web pages. However, similar issues to those listed above arise in the current systems.
To improve their services, catalog companies have been adding new search features. For example, in PartNet, part information is indexed in categories/subcategories, and users can utilize the taxonomy to find a particular part type. Users can specify attribute constraints for the selected part type. In addition, Saqqara's (1998) step-search provides an interface that displays range of values for database attributes for user input, preventing invalid inputs. Users can select options one at a time using the interface. When a reasonable number of candidates remain, users can invoke a comparison table for comparing the candidates. Centor Corp's (1998) parametric search also provides valid inputs for attributes and lets users choose several attributes among commonly used attributes for search. However, in these catalogs, users cannot get help with their implicit requirements; they can only use terms that are explicit in the database. For example, it is not easy to describe requirements such as the component applications, the functions of the component, and the environment the components should be in.
Some catalog providers offer a greater range of on-line information. In addition to text, images, and diagrams, they also provide information that helps users evaluate candidates. Micromo's (Micromo, 2003) Web site provides supplementary descriptions including application notes, tutorials, and related links. However, the information is static in the sense that users must read the given attribute values and the drawings and then evaluate whether they satisfy their requirements. Landrover (2003), BMW (2003), and several other Web sites illustrate a better way of evaluating components. They provide a dynamic environment for selecting vehicle models, colors, and desired features. Users can visually explore different combinations of options before selecting a particular combination. However, exploration is limited to combinations of static visual features in a 2-dimensional picture of one particular vehicle type. This is not the same as exploring dynamic performance.
There is also related research in developing tools that help designers use knowledge-based systems. Stanford University's “How Things Work” project is developing a service to search for components by supplying a description of the functions users would like the component to achieve (Iwasaki et al., 1996). Our approach generalizes the function-based search in that we support various ways of capturing user requirements, including the functional description. By analyzing the user goals and mapping the semantics of the queries into the information in the catalog, and by employing powerful reasoning based on domain knowledge, we extract most of the useful component information available.
A number of other researchers are exploring knowledge-based design environments. For example, there has been an approach to use expert systems and multimedia information in selecting engineering components (Bradley et al., 1994). Although their framework is very similar to ours and provides efficient design environment, our models are designed to be more readily usable with models of other components in order to support total system simulation. For example, the active catalog system can automatically generate specialized models of a particular component from its model templates as needed instead of using general models of given component types. We believe that this is a critical advantage in business environments because we can more flexibly meet customer needs.
The SHADE system (McGuire et al., 1993) used an ontology-based approach to facilitate collaboration between component development and integrated manufacturing. The active catalog system provides more powerful mechanisms for information search and evaluation by providing various information access processes and simulations of many modalities, in addition to viewing texts and drawings.
Mediator (Gaines et al., 1995) is a knowledge support system for managing activities in a manufacturing process. Although it provides KL-one-like inference services and powerful graphical capabilities, Mediator focuses on accessing remote files and applications rather than on helping users to access and evaluate components.
Case-based approaches (Sycara et al., 1992; Wood & Agogino, 1996; Goel et al., 1997) use case libraries to translate the user's description of components into the actual parts and designs. As noted in the introduction, we use domain ontologies instead of case libraries in order to map abstract descriptions into potential candidates. In addition, domain knowledge in the system helps users formulate queries to find components and their use in design so that selections of components are validated through simulations. However, exploiting past design cases will be an interesting extension to the active catalog system.
STEP (the standard for exchange of product model data; Fowler, 1995) builds an environment for engineering collaboration for engineering data exchange. It can be used for Internet simulations of mechanical systems design. By building active catalogs on STEP, we may be able to accomplish industrial enterprise integration: concurrent engineering and virtual enterprises.
6. SUMMARY AND FUTURE WORK
We have described ways of utilizing a rich body of domain knowledge to facilitate access to catalog information. The domain knowledge base provides a vocabulary that is at a higher level of conceptualization than those used by traditional database query or the keyword match technique widely employed by Web applications. Based on domain knowledge and understanding of the meaning of the queries specified in its vocabulary, the active catalog system accesses components that satisfy the “semantics” defined by the queries.
The retrieved information includes not only standard catalog data but also multimodal information, such as CAD and geometry files, and dynamic behavior information such as animations and simulations. The active catalog system provides mechanisms for instantiating dynamic simulation models and ways for combining multiple models to support system-level evaluation (e.g., wrapping multiple component simulations to make it possible to compose them together to simulate a system), supporting a new try before you buy paradigm.
Although some designers may prefer to drill down a design unassisted, we believe that the active catalog system is useful to many designers who want assistance in guiding their top-down design. Despite the focus being on engineering part selection, the active catalog system can be modified to support design based on other criteria, such as design for manufacturability. In addition to supporting a top-down design, we believe that our system can support a “what-ifs” design. For example, whenever there are changes to any attribute in the design or to the environment, the design can be easily redone.
The active catalog system currently assumes that all the catalog components required for a design exist. In many cases the catalog is incomplete and a part may be built on demand. In those cases, designers may need to talk to manufacturers' application engineers for custom designs. The active catalog system can be improved by linking it to an automated e-mail system connected to manufacturers or to an automated purchasing system (FastXchange, 2003).
The query capability can be improved by expanding the range of queries users can pose. For example, to be able to check constraints across multiple part types instead of one part type, we are planning to build a cross-constraint ontology. This will allow users to check compatibility when they build a system from multiple components. When users select a particular type of part and try to select another that should be linked to the selected part, the system will check cross-component constraints to filter out inconsistent combinations. The compatibility relation across different electromechanical component types is a sequence of constraint rules. Given two selected components (or component types), the system can check the compatibility between them by examining the sequence of constraint rules. If all of them are satisfied, they are compatible. In addition, for the simulation module, it would be desirable to extend it to perform compositions of models for hybrid simulation.
One promising direction is toward developing a general architecture and models of operation that are adaptable to a wide range of applications, so that manufacturers can easily construct new catalogs using the framework provided by the architecture. General catalog “shell” services may support development of databases that store up to date vendor information in the Internet, “wrapping” them according to the system requirements.
One of the key challenges in scaling up the system is providing a framework that enables distributed participation by users, component information suppliers, and providers of modeling services. The framework must also support distributed participation within an organization, recognizing that, many times, design evaluations are performed by multiple engineers with specialized expertise. Furthermore, the framework needs to be designed with an eye to simplifying system maintenance and upgrade functions.
References
REFERENCES
Arens, Y.,
Knoblock, C., &
Hsu, C.
(1998).
Query processing in the SIMS information mediator. In
Readings in Agents
(Huns, M.N. &
Singh, M.P., Eds.),
San Francisco, CA:
Morgan Kaufmann.
Barker, K.,
Blythe, J.,
Borchardt, G.,
Chaudhri, V.,
Clark, P.,
Cohen, P.,
Fitzgerald, J.,
Forbus, K.,
Gil, Y.,
Katz, B.,
Kim, J.,
King, G.,
Mishra, S.,
Murray, K.,
Otstott, C.,
Porter, B.,
Schrag, R.,
Uribe, T.,
Usher, & J.,
Yeh P.
(2003).
A knowledge acquisition tool for course of action analysis.
Proc. Fifteenth Innovative Applications Artificial Intelligence
Conf. (IAAI-2003).
BMW.
(2003).
Available on-line at http://www.bmwusa.com.
Bradley, S.,
Agogino, A.M., &
Wood, W.H.
(1994).
Intelligent engineering component catalogs. In
Artificial Intelligence in Design
(Gero, J.S. &
Sudweeks, F., Eds.), pp.
641–658.
New York:
Kluwer Academic.CrossRef
Centor Corp.
(1998).
Available on-line at http://www.centor.com.
Cohen, P.,
Schrag, R.,
Jones, E.,
Pease, A.,
Lin, A.,
Starr, B.,
Gunning, D., &
Burke, M.
(1998).
The DARPA High Performance Knowledge Base Project.
AI Magazine,
19,
4.Google Scholar
Coutinho, M.,
Eliesh, R.,
Kim, J.,
Kumar, V.,
Ling, R.,
Neches, R., &
Will, P.
(1998).
Active catalogs: integrated support for component engineering.
Proc. American Society of Mechanical Engineers, 18th Computers
Engineering Conf.
Eriksson, H.,
Shahar, Y.,
Tu, S.W.,
Puerta, A.R., &
Musen, M.
(1995).
Task modeling with reusable problem-solving methods.
Artificial Intelligence,
79,
293–326.CrossRefGoogle Scholar
FastXchange.
(2003).
Available on-line at http://www.fastxchange.com.
Fowler, J.
(1995).
STEP for Data Management, Exchange and Sharing.
London:
Technology Appraisals.
Frank, M. &
Szekely, P.
(1998).
Adaptive forms: an interaction paradigm for entering structured
data.
Proc. ACM Int. Conf. Intelligent User Interfaces, pp.
153–160.CrossRef
Gaines, B.R.,
Norrie, D.H., &
Lapsley, A.Z.
(1995).
Mediator: an intelligent information system supporting the virtual
manufacturing enterprise.
Proc. 1995 IEEE Int. Conf. Systems, Man and Cybernetics,
pp.
964–969.CrossRef
Goel, A.,
Bhatta, S., &
Stroulia, E.
(1997).
Kritik: an early case-based design system. In
Issues and Applications of Case-Based Reasoning to Design
(Mher, M.L. &
Pu, P., Eds.).
Mahwah, NJ:
Erlbaum.
Google.
(2003).
Available on-line at http://www.google.com.
InfoSeek.
(1998).
Available on-line at http://www.infoseek.com.
Iwasaki, Y.,
Fikes, R.,
Farquhar, A., &
Engelmore, R.
(1996).
Function-based engineering part retrieval, working notes.
AAAI Workshop on Modeling and Reasoning with Function.
Kim, J. &
Gil, Y.
(2000a).
User studies of an interdependency-based interface for acquiring
problem-solving knowledge.
Proc. ACM Int. Conf. Intelligent User Interfaces, pp.
165–168.
Kim, J. &
Gil, Y.
(2000b).
Acquiring problem-solving knowledge from end users: putting
interdependency models to the test.
Proc. Seventeenth National Conf. Artificial Intelligence.
Kim, J. &
Gil, Y.
(2001).
Knowledge analysis on process models.
Proc. Int. Joint Conf. Artificial Intelligence.
Kim, J.,
Ling, & S.R.,
Will. P.
(1997).
Ontology engineering for active catalog.
AAAI Workshop on Using AI in Electronic Commerce, Virtual
Organizations and Enterprise Knowledge Management to Reengineer the
Corporation.
Landrover.
(2003).
Available online at http://www.landrover.com.
Ling, S.R.,
Kim, J.,
Will, P., &
Luo, P.
(1997).
Active catalog: searching and using catalog information in
internet-based design.
Proc. DETC ‘97—1997 ASME Design
Engineering Technical Conf.
Luo, P. &
Will, P.
(1996).
Active catalog: a knowledge-rich design library facilitating
information consumption.
ISIP Workshop Series on Knowledge Intensive CAD-2.
MacGregor, R.
(1990).
LOOM User Manual.
Working Paper ISI/WP-22.
Marina del Ray, CA:
USC/Information Sciences Institute.
MacGregor, R.M.
(1994).
A description classifier for the predicate calculus.
Proc. Twelfth National Conf. Artificial Intelligence.
Marcus, S. &
McDermott, J.
(1989).
SALT: a knowledge acquisition language for propose-and-revise
systems.
Artificial Intelligence,
39(1),
1–37.CrossRefGoogle Scholar
MATLAB.
(2003).
Available on-line at
http://www.mathworks.com/matlab.html.
McGuire, J.G.,
Kuokka, D.R.,
Weber, J.C.,
Tenenbaum, J.M.,
Gruber, T.T., &
Olsen, G.R.
(1993).
SHADE: technology for knowledge-based collaboration engineering.
Journal of Concurrent Engineering: Applications and Research,
1(3),
137–146.CrossRefGoogle Scholar
Micromo.
(2003).
Available on-line at http://www.micromo.com.
O'Keefe, R.M.O'Leary, D.E.
(1993).
Expert system verification and validation: a survey and tutorial.
Artificial Intelligence Review,
7,
3–42.CrossRefGoogle Scholar
PartNet.
(1998).
Available on-line at http://www.partnet.com.
Preece, A.D.
(1995).
Validation of knowledge based systems: current trends and issues.
Knowledge Engineering Review,
10(1),
69–71.CrossRefGoogle Scholar
Saqqara.
(1998).
Available on-line at http://www.saqqara.com.
Swartout, B. &
Gil, Y.
(1995).
EXPECT: explicit representations for flexible acquisition.
Proc. Sixth Banff Knowledge Acquisition for Knowledge-Based Systems
Workshop.
Sycara, K.,
Guttal, R.,
Koning, J.,
Narasimhan, S., &
Navinchandra, D.
(1992).
CADET: a case-based synthesis tool for engineering design.
International Journal of Expert Systems,
4(2),
167–188.Google Scholar
Tallis, M.
(1999).
A script-based approach to modifying knowledge-based systems.
PhD Thesis.
University of Southern California, Computer Science Department,
Los Angeles.
Thomas Register.
(2003).
Available on-line at http://www.thomasregister.com.
Will, P.
(1991).
Simulation and modeling in early concept design: an industrial
perspective.
Research in Engineering Design,
3(1),
1–14.CrossRefGoogle Scholar
Wood, W.H. &
Agogino, A.M.
(1996).
Case-based conceptual design information server for concurrent
engineering.
Computer-Aided Design,
28(5),
361–369.CrossRefGoogle Scholar
Working Model.
(2003). San Mateo, CA: Knowledge Revolution.
Yahoo.
(2003).
Available on-line at http://www.yahoo.com.
Yen, J.,
Neches, R.,
Debellis, M.,
Szekely, P., &
Aberg, P.
(1991).
BACKBORD: an implementation of specification by reformulation. In
Architecture for Intelligent Interfaces: Elements and Prototypes,
ACM Frontier Series
(Sullivan, J. &
Typler, S., Eds.),
New York:
Addison–Wesley.
The active catalog system as a design workspace.
The way in which the search system works in helping designers find candidate parts that meet the design constraints.
The interface for accepting user requirements.
Finding motors for a high oxygen level environment: (a) example subontology and (b) example axioms.
The subparts of the active catalogs ontology.
The user interface for modifying the attribute constraints and retrieving database results.
A display of multimodal component information.
The automated instantiations of a specific part model.
The simulation interface.
You have
Access
- 9
- Cited by