To appear in the journal of Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM)
Knowledge Rich Catalog Services for Engineering Design Jihie Kim, Peter Will, Ringo Ling, and Bob Neches USC Information Sciences Institute, 4676 Admiralty Way, Marina del Rey, CA 90292, USA; e-mail: {jihie, will, rneches}@isi.edu e-mail:
[email protected] phone: (310) 448-8769
number of pages:31 number of tables: 0 number of figures: 9
1
Knowledge Rich Catalog Services for Engineering Design 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 for personal items to engineers selecting electro-mechanical 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 electro-mechanical components and sub-systems. The services include mechanisms for: (1) creating queries for parts based on their intended use rather than merely parametric specifications; (2) refining those queries to take account of constraints imposed by domain knowledge; (3) providing multimodal information to help engineers assess and compare candidate parts; and (4) generating simulation models for candidate parts and integrating them to provide simulation models for candidate systems.
Key words: electronic catalogs, ontology-based search, multi-modal information, dynamic simulation
2
1. Introduction A catalog is a basic resource to a number of people and disciplines, ranging from shoppers for personal items to engineers selecting electro-mechanical parts for their design. For example, engineers often spend a large amount of time obtaining information about components from catalogs so as to evaluate tradeoffs 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 2003], 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. Also, existing catalog contents are designed to be consumed by a human reading a document or looking at an image. In fact, there exists a gap 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 SQL queries to retrieve the motors might look like “SELECT *
3
FROM Motor, Environment WHERE Motor.weight = 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 since there is no simple set of universally accepted names for the component as there is at least conceptually for motor, usually a part that rotates. There are also problems in using the information in the design environment. For example, to determine 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 [Coutinho et al. 98; Kim et al. 97; Ling et al. 97; Luo and Will 96] addresses the above problems by using a rich body of domain knowledge to describe the catalog components, adding to and annotating traditional catalogs with multi-modal technical information, and aiding the use of the retrieved information by providing 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.
4
Search Interface
ConstraintConstraint-Based Search SQL queries Component Database
Part Type, Instance
Result tables
Model Template DB
Part s Vi ewe r
VRML, Images, Application Notes
Simulation Model Template
Model Generator
Evaluation Interface
Instantiated Models
Test data Generator
Test Data
Active Models
Figure 1. The Active Catalog system as a design workspace
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. Also, 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 dynamic and behavioral aspects of a component in a system via interactive simulation built from or using down-loaded models, viewers or simulation code.
5
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, find candidates, and 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 animations1. 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 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 and Agogino 1996; Goel et al 1997] where the system uses a case library to map abstract description of the device into relevant designs, we use domain ontologies to help users formulate queries for finding 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.
6
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 design with data on motors, encoders, actuators, tachometers and bearings. The collaborators for building the catalogs included Lockheed Martin, Raytheon, and other participants in the DARPA RADEO program. The effort has successfully demonstrated the viability of our approach to helping designers evaluate the feasibility of a candidate part in the context of a new gimbal design. The sections following 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. The section following describes related work, including current approaches to providing catalog information. Finally, a summary and future work are presented.
2
A device for permitting a body to incline freely in all directions, or for suspending anything, as an aircraft's compass, barometer, etc., so that it will remain plumb, or 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.
7
2. Ontology-Based Component Search Capabilities
Objectives
Applications
Environment
In Environment
Object ives
Application
Pro duc t
Component
Nam F un e cti Ob on jec t Function
Functions
Objects
Ins tan ces
Gears
Input Sp ec
Amplifiers Sensors
Dimen
Products
y nc ue eq Fr
NSN n Selli
Transducers
g
Selling Info
Item
be Num
Non-Negative Number
Relation 1-1 Name
Price
Value Classes
BNF
String
g in
Adaptors
sions
h itc Sw
Name
r
Relation 1-m Inheritance Concept
Compa
ny
Find light Semotors for building an lling application in highCompanies level oxygen environment
User Reqmt. Retrieve ?x (and (Brushless_Motors ?x) (< (Weight ?x) (Average Weight of Motors)))
System Query
Figure 2. Helping Designers Find Candidate Parts Meeting Design Constraints
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 (inhouse experts and some collaborators in DARPA’s RADEO program) as well as engineering textbooks. This domain knowledge wraps the component database and enables the users to specify their requirements in a conceptual level.
8
There are at least three advantages of 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. Also, 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. Also, 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 sub-features. •
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 sub-ontologies for multiple aspects of components. Using these sub-ontologies, a user can create queries that combine different types of requirements.
9
Multiple requirements can be combined by first applying the first sub-feature - 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 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 will discuss each of these sub-features 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 and Szekely 98]. There is a two-step process that converts the ontologies into a requirements interface. First, the ontologies are converted into a 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
10
Catalog Search window in Figure 3 are generated from the domain knowledge3. The interface provides a friendly environment for engineers to express their requirements. For example, when the user needs motors that can be used for an application in high oxygen environment (such as in spacecraft and submarines) then the user can specify the requirement by filling the form shown in Figure 3.
In this case, the user selected “motor” for the component type and
“High_oxygen_level” for the environment. This is inspired by intelligent user interface research in generating intelligent/adaptive options for users to help them interact with computers [Yen et al 1991].
Figure 3. Interface for accepting user requirement
The domain ontology is represented in Loom, [MacGregor 1994; MacGregor 1990], a knowledge representation language and environment in the KL-one family. Loom provides powerful deductive services (i.e., classifier) that organize concepts and relations into a 3
Since the mapping between the product ontology and the BNF form is straightforward, we are developing a
11
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: (retrieve ?component-type (for-some (?application ?environment) (and (Motors ?component-type) (Any-Application ?application) (High_oxygen_level ?environment) (in_environment ?application ?environment) (safe_for_component ?application ?componenttype))))
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.
module that generates Adaptive Forms automatically from the knowledge base.
12
W eight ID Number Shaft Diameter Diameter
Motors
Power Source
Non-Negative Number
y Vo
Applications
d Suppl
Non Servo Motor
Sensors
Objects
Dimensions
Sw
NSN
ing que Fre ncy
Brush Motors
itch
Non-Negative Number
Transducers
Selling
AC Motors
Non-Negative Number
Con
Servo Control Types
tino T orqu us
Control
Elec trom
Arm eture
Servo
Resi
e
echa nica stanc
Value Classes
cons
of
Relation 1-1 Relation 1-m Inheritance
Item
Concept
Company
Selling
Servo Motor
a Inerti
Companies
ue
le Varian
Li nearity
Ripp
Torq ce k stan PeaResi
mal Ther
Price er Numb
Selling Info
AC Servo Motor
tant
ment Mom Non-Negative Number
Series Motors
Brush Servo Motor
torq
cons ue tant
l time
e
Seperately Excitted Motors
Shunt Motors
String
Name Adaptors
ion
Compound Motors
Input Spec
Amplifiers
Products
DC Motors
ding Win nect Con
Environment
Func Name Obje tion Function ct
Functions
ces
Gears
Brushless Motors
ct Instan
Rotor
ent Curr ush Br
Produ
mende Recom
Stator
In Environment
ltage
Component
Electric Motors
Objectives
Object ives
ance Resist RPMTorque
Hydraulic Motors
Stator Values
Name
Pneumatic Motors
Rotor Values
Current Values
Brushes
Windind Connection Types
Application
Power Sources
Value Classes
Applications
ce
Permanent Magnet Motors
DC Servo Motor
Number
i n _en vi ro n men t
P roducts
E nvironment
u n safe_ to _u s e
(1 )
is a
is a
M otors G en era te_ fi re is a
is a
Exp lo si ve_ En viro n men t
(2 )
is a
Bru sh _ mo to rs
(5 )
(3 )
No n _exp l o si v e_ En viro n men t
is a
Cau s e_ sp ar k
Bru sh l e ss_ mo to rs
is a
(4 )
Hig h _l evel _ O xyg en
(a) Example sub-ontology (1) If the motor does not generate a fire in the environment of the given application, then we assume it is safe to use (for-some ?env (and (Applications ?appl) (Environment ?env) (Motors ?prod) (and (in_environment ?appl ?env) (not (generate_fire ?prod ?env)))) ) ==> (safe_for_component ?appl ?prod) ;; closed-word assumption (2) When a motor has brushes, it can generate fires in an explosive environment (and (Motor ?prod) (Has-Brush ?prod)) (Environment ?env) (Explosive_environment ?env)) ==> (generate_fire ?prod ?env) (3) Brush motors have brushes Brush_Motors => Has-Brush (4) High oxygen-level is kind of an explosive environment High_oxygen_level ==> Explosive_environment (5) (not Brush_Motor) => Brushless
(b) Example axioms Figure 4. Finding motors for high oxygen-level environment
In the process of answering the query, the user requirement is mapped to component types, or attribute constraints that satisfy the conditions using a sub-network in the component
13
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 axiom (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 (3) and (4), the system infers that brush motors (motors with brushes) are not safe for high oxygen-level environment (a kind of explosive environment). Finally, by using (5), the mapping function returns brushless motors. Since Loom supports queries returning instances, in order 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 inch". These constraints are used together with other attribute constraints specified by the user. This approach has several potential benefits. Since 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/she wants to use brushless from the beginning then that simplifies the mapping, but may over-constrain the choices. Since we maintain more knowledge than an individual user, we can assist designers in finding potential results that they might have missed due to 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
14
multiple constraints. This section describes how the system allows users to describe multiple different requirements. The system defines multiple sub-ontologies 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 sub-ontologies together with component taxonomy and attribute taxonomy. We have built a taxonomy of electro-mechanical 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, 3,000 attributes for pumps [Luo and Will 1996], 72 classes of motors, and 66 attributes of motors [Coutinho et al. 1998]. 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.
15
Weight ID Number Shaft Diameter Diameter
Motors
Power Source
Hydraulic Motors
Stator
Rec
om
me
nded
Applications
Object ives ply Su p
Vo
e ltag
Rotor
Rotor Values
rre Cu h us Br
Current Values
nt Non Servo Motor
Gears
Functions
Nam e Function Objects
Input Sp ec Dimens ions
Products
Sensors
String
Adaptors
Brush Motors
Co
Servo Control Types
nt in o To u s t o rq ctr u e r que om Ar co ec m ha ns etu nic ta re nt al Re tim si s ec tan on ce sta nt
Brush Servo Motor
Servo Co ntrol
Ele
Seperately Excitted Motors
Value Classes
Selling Info
of
q or
Selling
Concept
Companies
ia nc
ty eari
e
Permanent Magnet Motors
◆ ◆ ◆ ◆
DC Servo Motor
Number
Pump ontology (released to Stanford KSL) Pump ontology (released to Stanford KSL) ➤ 300 classes and 3,000 attributes ➤ 300 classes and 3,000 attributes Motor ontology & instances Motor ontology & instances ➤ 72 classes and 66 attributes ➤ 72 classes and 66 attributes ➤ Currently being applied to classify 113 motor instances from Lockheed Martin ➤ Currently being applied to classify 113 motor instances from Lockheed Martin and Inland Motor Catalog and Inland Motor Catalog
Figure 5. Sub-parts of the Active Catalogs Ontology 16
Relation 1-m Inheritance
ue
e V ar
erm
Relation 1-1
rtia Ine
T e nc ak Pe esista R al
Th
Non-Negative Number
L in
Non-Negative Number
nt
R ippl
Shunt Motors
Series Motors
me
Price ber Num Item Compa ny
AC Servo Motor Servo Motor
m Mo
y enc qu Fre
NSN
Transducers
Selling
AC Motors
Non-Negative Number
g hin itc Sw
Name
DC Motors
g din on in cti W nne Co
Compound Motors
Fun cti Obje on ct
Amplifiers
Brushless Motors
Brushes
Environment
In Environment
Prod uct In stan ces
Electric Motors
Stator Values
Objectives
Component
Value Classes
Windind Connection Types
Non-Negative Number
ce stan Resi M ue RP T orq
Name
Pneumatic Motors
Application
Power Sources
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) , etc. 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), 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, etc. 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. implications.
Then it collects component types and attribute constraints from the
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. Currently we don’t provide a mechanism for handling conflicting requirements, and we leave it as a future extension.
17
2.3. Translation: Creating database queries and retrieving results The preceding sections showed how the Active Catalog system helps re-express highlevel 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 sub-function, we built a translation table (called a meta-description). This table has mappings between component types and database tables. Also, it has mappings between 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.
18
Figure 6. User Interface for Modifying Attribute Constraints and Retrieving Database Results
Figure 6 shows the interface for displaying translation results. The sub-window 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 “Search Results” frame. The table in the frame lists all the candidates that satisfy all the requirements. 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. Also, 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 which support such flexibility. Users can
19
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 “Export Selections” button.
3. Assessing Candidates The Active Catalog system supplements a regular database with an augmented database to store meta-data 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. Multi Modal Information The Active Catalog system provides part data in various modalities and data formats. For example, to determine the suitability of a servo control 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 a system such as speed, torque-rise time, and stability.
However, the mechanical and electrical
evaluations are not enough. Weight and volume are important: since a motor is mounted in a gimbal frame, the engineer must determine if 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. While 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
20
pictures of the parts. Engineers would like to see a cross sectional view or a two-dimensional drawing of the motor, showing the relationships of the rotor and stator within the motor as well as its inside and outside diameter. The relationships of the rotor and stator are not explicit in database tables. In drawings, engineers can find out the location of the mounting holes and the electrical terminal connections, which is 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 etc.
Figure 7. Display of Multi-Modal Component Information
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
21
Catalog system gathers and collates multi-modal 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 multi-modality capability, the Active Catalog system supplements a regular database of parameter data with a special database to store multi-modal information about parts. In addition, meta-data information is provided. The Active Catalog system uses the meta-data to identify the relevant data formats and to provide appropriate displays. To provide an integrated display of multi-modal 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 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. 3.2. Active Models, Retrieved or Generated While multi-modal 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 multi-modal 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
22
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 handcoded 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 EMF coefficient, a constant velocity output torque to input current, an inertia and friction, etc. This information, combined with the load torque and inertia, is enough to generate differential equations and Laplace transforms of a motor plus load.
Figure 8: Automated instantiations of a specific part model
23
We have built generic models that we can combine with parameters from a manufacturer to automatically produce Matlab models. Our approach to generating a motor simulation model is a two-step process: a) create a generic model for a class of parts and queries, and b) instantiate a model for a specific part from the generic model by substituting parameter values of the chosen part. In the domain of servo-control 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 manually built based on the domain theory and expressed as a Matlab/Simulink model. A model usually requires parameter values such as specific value of resistance, inductance etc. 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.
Figure 9. The Simulation Interface 24
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 servo control motor and a VRML animation model that breaks apart the sub-components of that same motor. 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 since 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. Besides 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 that address mechanical engineering aspect. 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: 1) 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, 2) There are a large 25
number of options so designers can easily overlook possible candidates, and 3) The components should be thoroughly evaluated before use. However, if the given task is very simple, with 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, heavily dependent on the kinds of knowledge acquired from domain experts. It was not trivial to translate what engineers had in mind to a formal representation and link it with other information sources, such as an existing catalog library. Also, a main bottleneck of building part models and supporting interoperability of models in multiple domains was 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 and Gil 2000a; Kim and Gil 2000b; Barker et al 2003]. Another problem is maintaining the component knowledge base after the initial prototypes are developed. It is very rare if the knowledge base does 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 pre-determining knowledge roles[Marcus and McDermott 1989], deriving or coding interdependency among different parts in the knowledge base[Swartout and Gil 1995;Eriksson et al. 1995], using a set of modification scripts [Tallis 2000], etc. In addition, we are finding ways to make sure that new additions, deletions or modifications do not break 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 [Kim and Gil 2001; Preece 1995; O’Keefe and O’Leary 1993].
26
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 online catalog data in three different forms: 1) General Web search services. Engineers go to general search engine web sites, such as Yahoo [Yahoo 2003], Google[Google 2003], and InfoSeek [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 websites for automobile instead of electro-mechanical part “motor”, and to make matters worse there are enormous amounts of redundancies and broken links in the results. 2) Dedicated parts catalog referral services. These are services dedicated to finding companies that can provide parts for engineers. The Thomas Register 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 Thomas Register 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.
27
3) 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 [PartNet 98]. The technical information of parts is more organized and uniformly presented than individual company manufacturers or distributors 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. Also, Saqqara’s [Saqqara 98] 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 [Centor Corp 98] 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] website 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 [Landrover 2003], BMW [BMW 2003] and several other websites 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 28
limited to combinations of static visual features in a two-dimensional picture of one particular vehicle type. This is not the same as exploring dynamic performance. There is also related research in developing tools which help designers use knowledgebased systems.
Stanford’s “How Things Work” project is developing a service to search for
components by supplying a description of the function users would like the component to achieve[Iwasaki and Fikes 96]. 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 multi-media 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. 93] 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. 95] 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. 29
Case-based approaches [Sycara 1992; Wood and 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 in finding 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 key-word 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 multi-modal 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.
30
While 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 to guide their top-down design. While the focus is 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 top-down design, we believe that our system can support “what-ifs” design. For example, whenever there are changes to any attribute in the design or to the environment and the design can be easily re-done. 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 email system to manufacturers or 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 crosscomponent constraints to filter out inconsistent combinations. The compatibility relation across different electro-mechanical 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. Also, for the simulation module, it would be desirable to extend it to perform compositions of models for hybrid simulation. One promising direction is to 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. 31
One of the key challenges in scaling up the system is to provide 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. \
Bibliography Y. Arens, C. Knoblock, and C. Hsu, Query processing in the SIMS information mediator, In Michael N. Huns and Munindar P. Singh, editors, Readings in Agents. Morgan Kaufmann, San Francisco, CA, 1998. K. Barker, J. Blythe, G. Borchardt, V. Chaudhri, P. Clark, P. Cohen, J. Fitzgerald, K. Forbus, Y. Gil, B. Katz, J. Kim, G. King, S. Mishra, K. Murray, C. Otstott, B. Porter, R. Schrag, T. Uribe, J. Usher, and P. Yeh, A Knowledge Acquisition Tool for Course of Action Analysis, Fifteenth Innovative Applications of Artificial Intelligence Conference (IAAI-2003), 2003. S. Bradley, A. M. Agogino, and W. H. Wood, Intelligent Engineering Component Catalogs, Artificial Intelligence in Design, (1994). P. Cohen, R. Schrag, E. Jones, A. Pease, A. Lin, B. Starr, D. Gunning, and M. Burke. The DARPA High Performance Knowledge Base Project, AI Magazine, 19, 4 (1998). M. Coutinho, R. Eliesh, J. Kim, V. Kumar, R. Ling, R. Neches, and P. Will. Active Catalogs: Integrated support for component engineering, Proceedings of the American Society of Mechanical Engineers, 18th Computers in Engineering Conference (1998). H. Eriksson, Y. Shahar, S.W. Tu, A.R. Puerta, and M. Musen. Task modeling with reusable problemsolving methods. Artificial Intelligence 79 (1995), 293-326. J. Fowler. STEP for data management, exchange and sharing. 214 pp., Technology Appraisals Ltd., UK (1995). (ISBN 1-871802-36-9). M. Frank and P. Szekely. Adaptive Forms: An interaction paradigm for entering structured data. Proceedings of the ACM International Conference on Intelligent User Interfaces, (1998),153-160. B. R. Gaines, D. H. Norrie, and A. Z. Lapsley. Mediator: an intelligent information system supporting the virtual manufacturing enterprise. Proceedings of 1995 IEEE International Conference on Systems, Man and Cybernetics (1995), 964--969. A. Goel, S. Bhatta, and E. Stroulia. Kritik: an Early Cas-Based Design System., Mary Lou Mher, Perl Pu (eds.) Issues and Applications of Case-Based Reasoning to Design. Lawrence Erlbaum associates, 1997. Y. Iwasaki, R. Fikes, A. Farquhar, and R. Engelmore. Function-based engineering part retrieval, Working notes AAAI workshop on Modeling and Reasoning with Function (1996).
32
J. Kim, S.R. Ling and P.Will, Ontology Engineering for Active Catalog, AAAI workshop on Using AI in Electronic Commerce, Virtual Organizations and Enterprise Knowledge Management to Reengineer the Corporation (1997). J. Kim and Y. Gil, User Studies of an Interdependency-Based Interface for Acquiring Problem-Solving Knowledge. Proceedings of the ACM International Conference on Intelligent User Interfaces, (2000), 165-168. J. Kim and Y. Gil, Acquiring Problem-Solving Knowledge from End Users: Putting Interdependency Models to the Test, Proceedings of the Seventeenth National Conference on Artificial Intelligence (2000). J. Kim and Y. Gil, Knowledge Analysis on Process Models, Proceedings of International Joint Conference on Artificial Intelligence (2001). S.R. Ling, J. Kim, P.Will, and P. Luo, Active Catalog: Searching and Using Catalog Information in Internet-Based Design. Proceedings of DETC '97 - 1997 ASME Design Engineering Technical Conferences, (1997). P.Luo and P. Will, Active Catalog: A Knowledge-Rich Design Library Facilitating Information Consumption, ISIP Workshop Series on Knowledge Intensive CAD-2 (1996). R. MacGregor, LOOM User Manual, USC/Information Sciences Institute. Working paper ISI/WP-22 (1990). R.M. MacGregor. A description classifier for the predicate calculus. Proceedings of the Twelfth National Conference on Artificial Intelligence (1994). S. Marcus, and J. McDermott. SALT: A knowledge acquisition language for propose-and-revise systems. Artificial Intelligence, 39, 1 (1989), 1-37. J. G. McGuire, D. R. Kuokka, J. C. Weber, J. M. Tenenbaum, T. T. Gruber, and G. R. Olsen. SHADE: Technology for knowledge-based collaboration engineering. Journal of Concurrent Engineering: Applications and Research (CERA), 1, 2 (1993). R.M. O'Keefe, and D.E. O'Leary. Expert system verification and validation: a survey and tutorial, Artificial Intelligence Review 7 (1993), 3-42. A.D. Preece. Validation of Knowledge Based Systems: Current Trends and Issues. Knowledge Engineering Review, 10,1 (1995), 69-71. B. Swartout and Y. Gil, EXPECT: Explicit representations for flexible acquisition. In Procueedings of the Sixth Banff Knowledge Acquisition for Knowledge-Based Systems Workshop (1995). K. Sycara, R. Guttal,, J. Koning, S. Narasimhan, D. Navinchandra, CADET: a case-based synthesis tool for engineering design, International Journal for Expert Systems, 4 (ii) (1992). M.Tallis. A script-based approach to modifying knowledge-based system. International Journal of Human Computer Studies (To appear). P. Will, Simulation and Modeling in Early Concept Design: An Industrial Perspective, Research in Engineering Design 3 (1991).
33
Wood, W. H. and Agogino, A. M.: 1996, Case-based conceptual design information server for concurrent engineering, Computer-Aided Design, 28(5), 361-369. J. Yen, R. Neches, M. Debellis, P. Szekely and P. Aberg. BACKBORD: An implementation of specification by reformulation, Architecture for Intelligent Interfaces: Elements and Prototypes, J. Sullivan and S. Typler (Eds),ACM Frontier Series, Addison-Wesley Publishing Company (1991). Working Model. Knowledge Revolution. 66 Bovet Road, Suite 200, San Mateo, CA 94402. BMW. http://www.bmwusa.com, 1/30/2003. Centor Corp. http://www.centor.com, 1/30/1998. FastXchange. http://www.fastxchange.com, 1/30/2003. Google http://www.google.com, 1/30/2003. Industry Net. http://www.industry.net 2/2/1998. Infoseek. http://www.infoseek.com 2/2/1998. Landrover. http://www.landrover.com, 1/30/2003. Matlab. http://www.mathworks.com/matlab.html, 1/30/2003. Micromo. http://www.micromo.com, 1/30/2003. PartNet. http://www.partnet.com, 1/30/1998. Saqqara. http://www.saqqara.com, 1/30/1998. Thomas Register http://www.thomasregister.com/ 2/2/2003. Yahoo. http://www.yahoo.com/ 2/2/2003.
Fertig. http://www.rsc.rockwell.com/designsheet/
34
