Modeling and Control of a Multi Agent Engineering ... - Semantic Scholar

Modeling and Control of a Multi-Agent Engineering Process: an Al Approach to Concurrent Engineering Alexander Kott Carnegie Group, Inc. Five PPG Place Pittsburgh, PA 15222

Alf Cederquist Engine Division Ford Motor Company 21500 Oakwood Blvd. EEE Building Mail Drop 15 POB 2053 Dearborn, MI 48121-2053

Charles KolIar Carnegie Group, Inc. Five PPG Place Pittsburgh, PA 15222

Abstract We describe some of the concepts behind the Function Advisor, a prototype knowledgebased system that supports Concurrent Engineering. The primary objective of the Function Advisor is to support, direct, and manage consistency and completeness of design-related and other engineering activities in a large, complex, and distributed engineering organization. Among the issues addressed by the system are those of developing a model of the product being engineered and of using the resulting model to control the multi-agent engineering process. We start by discussing the notion of the Concurrent Engineering and related research efforts. Then we outline the needs of a large engineering organization and the functionality of a software tool that could address those needs. We suggest that the software tool needs a model of the product being engineered, and present a hierarchical model that includes representation of parts, interactions, and constraints. We then describe how the Function Advisor uses this model to assure consistency of the engineering decisions by propagating constraints through a network of human agents, and conveying engineering information to its users by identifying a relevant environment for their tasks. This paper appeared in the Proceedings of 1990 ASME DESIGN AUTOMATION CONFERENCE, CHICAGO, ILL (SEPTEMBER 16-19, 1990). WARNING: the text has been produced by OCR from a hardcopy, and contains a number of errors. Contact the authors for a copy.

1. Introduction Concurrent Engineering is a relatively new concept, or set of concepts, applied to the field of Design Engineering as well as Engineering in general. There are many other terms that are either synonymous with Concurrent Engineering or closely related: Simultaneous Engineering, Integrated Design Environment, Distributed Design, Unified Life-Cycle Engineering, Technical Information Management, Engineering Databases, Design for Producibility, Design for Assembly, Design for Life-Cycle, Concurrent Product and Process Design, etc. Concurrent Engineering refers to an engineering (particularly, design) methodology where a number of distinct aspects of a product are engineered simultaneously or concurrently. This contrasts with a common practice where the distinct aspects of a product (e.g., the functional design of the product and the process

to manufacture the product) are engineered separately and at different times. As pointed Out in (Talukdar, 1988), the problems of engineering complex artifacts like, for example, a complete printed circuit board are usually too difficult to be solved by a single human or a single computer program. Therefore, the problem is usually decomposed into sub-problems, and each subproblem (task) is assigned to a task agent (design engineer, manufacturing engineer, test engineer, computer program,

or other resource). However, the sub-problems are not completely independent, but are coupled. If this coupling is neglected, the resulting inconsistencies can be very costly and difficult to rectify. Thus, there is a need to integrate and coordinate the different sub-problems. This is what Concurrent Engineering Methodology is intended to accomplish. Consider a common situation where a product must be engineered concurrently by several specialists who view the same product from different perspectives. Each specialist tends to manipulate the design, or process, in a way that optimizes the result from his/her specific perspective. Here, usual practice is to conduct design iterations combined with both formal and informal communications between the different specialists. This iterative process leads to a design that is a compromise in the views of the specialists involved. A somewhat similar situation arises when a number of distinct specialists are responsible for the design of different objects that interact via some constraints. Even though the interfaces (interactions) between the individual modules can be specified, this specification usually can not be completed a prior~ before the design starts. Therefore, the process of specifying and re-specifying the interactions between the modules proceeds along with the design of individual modules. It is highly desirable to have a methodology (particularly a software-based methodology) that assists the human designers in keeping track of the constantly changing specifications. In this connection, one also faces the issue of Engineering Databases, where the information, such as the state of design and the state of interfaces, is stored and shared. Ford Motor Company and Carnegie Group, Inc. have been working on a prototype system, called Function Advisor, which addresses a number of the key issues of Concurrent Engineering. This system, currently at the proof-of-concept demonstration stage, is based on the view that the ability to share information between multiple knowledge workers is the key to Concurrent Engineering. The Function Advisor exploits the idea that, because in an engineering organization the shareable information evolves around the product being engineered, a model of the product is an important foundation for a computer system that strives to support the process of Concurrent Engineering. In the next chapter, we discuss the notion of the Concurrent Engineering and related research efforts. Then we briefly outline the needs of a large engineering organization and the functionality of a software tool that could address those needs. We suggest that the software tool needs a model of the product being engineered, and present a hierarchical model that includes representation of parts, interactions, and constraints. We then describe how Function Advisor uses this model.

2. Current Research and Issues Many of the issues addressed by the current research on Concurrent Engineering are concerned with a means of allowing a computer-based advisory system to support the cooperation between multiple en-

gineering agents, including: • planning and management of the activities of multiple agents • representing and modeling the product • managing multiple representations and versions of the product • developing Engineering Databases capable of supporting Concurrent Engineering • managing and propagating constraints and avoiding inconsistencies in the current state of the product description • sharing the information between the multiple agents without creating an “information blizzard” One of the more ambitious efforts in Concurrent Engineering is the DICE DARPA Initiative in Concurrent Engineering. The initiative addresses two concerns: (1) lack of optimization of product lifecycle constraints (e.g., cost, maintenance); and (2) the length of the product development cycle (from concept to part). It is suggested that these concerns result, to a great extent, from problems with today’s design methodology. The initiative pursues a goal of creating a computer-assisted, integrated design environment that (1) synchronizes, schedules, and refines information flow between the disciplines in the product development cycle, and (2) fuses all constraints, including life-cycle requirements, into the design generation. The theory of DICE includes several propositions. First, it asserts that information management architectures, information buses, dataflow machines, etc., can achieve concurrence. Second, all required product information and knowledge sources are representible in a unified scheme (a feature) that supports different user perspectives and a design library. Third, problem-specific, computer-based tools, such as material models, process models, and design advisors, within a generic information management architecture, enable a balanced synthesis of life-cycle constraints. -

The CASE (Computer-Aided Simultaneous Engineering System) (Talukdar, 1988) is an experimental testbed developed at Carnegie Mellon University to study a number of issues in computer-aided design, simultaneous engineering, and distributed problem-solving. It integrates humans and computer programs into a team of problem-solving agents. The problem-solving agents are divided into two groups: “design agents” that initialize or modify some aspects of the design, and “design critics” that generate criticisms and suggestions from the point of view of other design tasks. CASE uses multiple representations of the design simultaneously (e.g., functional model, geometric model, etc). Another system developed at Carnegie Mellon University, Design Fusion (Finger, 1988), uses a blackboard architecture. The design of a product is represented as a collection of features and multiple problem-solving agents that view the representation from different perspectives. Each perspective represents a different life-cycle concern (e.g., manufacture, maintenance, cost). Each perspective deals with its own set of features. That is, the materials perspective is interested in things like microstructure, while assembly perspective is concerned with weight and tolerances. The system relies on constraint propagation to guide the design process. Sathi, Morton, and Roth (Sathi et al., 1986) discussed how the Callisto system addresses three areas: activity management, product configuration management, and resource management. They point out that large engineering projects involve a large number of activities and require cooperation across a number of

departments, and that, due to technological and market uncertainties, these projects involve a large number of changes. Their approach to product configuration management addresses the representation of configuration and change knowledge. They argue that the classical approaches to project management do not provide sufficient functionality. Another relevant effort on product configuration management has been reported in (Marshall and Downes-Martin, 1987), where the configuration tracking system was predicated on use of a distributed product-structure knowledge base. An approach to planning activities of multiple design agents has been addressed in a planning module of ADAM (Advanced Design Automation) (Knapp and Parker, 1986) a system that manages the digital design process using a planning paradigm. All the agents in this case are artificial, they are various design automation programs. ADAM unifies a number of the design automation programs into a single

framework. Its planning module uses Al planning techniques to decide on the steps that need to be performed, and which of the design agents should be invoked, and in what order. If a plan fails during execution, a new plan is constructed to rectify the failure. Knowledge representation in Engineering Databases has been evaluated in (Hartzband and Maryanski, 1985). These authors suggest that commercial data management products are not sufficient to meet the needs of engineering information users. They review several important areas of current data model development, including data abstraction, property inheritance, object representation, non-traditional data (e.g., graphic information), and knowledge-base management. Nguyen and Rieu (Nguyen and Rieu, 1987) describe an expert database capable of supporting engineering design. It permits creation of a product model that implements object-oriented concepts and controls the correctness of the designer’s operations using first-order logic. It also allows for the integration of expert knowledge using specific optimization heuristics for the automatic computation of sideeffects during the modifications performed on the product description. The issue of constraint propagation is crucial for keeping consistency between the decisions made by the individual agents in the process of Concurrent Engineering. Constraint propagation has been actively used in Electronic Design Automation. For example, VEXED (Steinberg, 1987) (a design aid for NMOS digital circuits) views electronic design as a combination of top-down refinement and constraint propagation. Ohsuga (Ohsuga, 1985) outlines a model for design that is based on a heavy usage of engineering databases and consists of: a hierarchical parts structure, attributes of the design elements, relations between the elements on the same level of hierarchy, and predicates that connect elements when relations do not fit. Problems arising in the sharing of information among multiple agents has been studied by Malone et. al. (malone et al., 1986) and Greif (Greif, 1983). The major issues in this area are: (1) how to represent the knowledge about what information should be shared with whom; (2) how to assure that information sharing does not create an “information blizzard” in which a computerized information sharing system overwhelms the user with thousands of messages of marginal relevance. These authors discuss approaches to intelligent filtering of the shareable information, particularly filters that utilize the knowledge

about the functional “roles” played by the users. The problem of representing product knowledge (product modeling) closely relates to work on qualitative modeling of physical systems (pan, 1984, Kuipers, 1986, Ishida and Eshelman, 1987, Joskowicz, 1987, De Kleer and Brown, 1986, Forbus, 1986, Davis, 1986). This research field attempts to model behavior of physical systems (such as an internal combustion engine, or an electronic circuit) by using qualitative (sometimes in conjunction with quantitative) knowledge about dependencies between various attributes of the system’s elements. Even though there are quantitative methods (e.g., numerical modeling) that are successfully applied to this type of problem, these methods fail in systems of extreme complexity, when only qualitative information is available, or when the system is known to be malfunctioning. De Kleer and Brown (De Kleer and Brown, 1986) model physical device with three basic primitives: materials, components, conduits. Behavior is achieved by transporting materials between components. Components change characteristics of materials. The state of a device is described by variables. Relations and constraints between the variables is described by “confluences”, qualitative analogs of quantitative algebraic or differential equations. Forbus (Forbus, 1984) emphasizes “processes” that occur between the states of a system. The relations between the qualitative parameters of a system occur in the “quantity space”. When relations between parameters change, some processes start or stop. Pan (pan, 1984) and Fink (Fink, 1985) use qualitative modeling for diagnostic purposes. Diagnostic applications in general seem to be the most active and successful area of model-based reasoning. Ishida and Eshelman (Ishida and Eshelman, 1987) report on their software that diagnoses process equipment using a model that combines approaches of Kuipers and De Kleer. They use “stateinteraction” models that is made of two primitive structures, variables and interactions between the variables. Another active area of application interests is qualitative simulation. Kuipers (Kuipers, 1986) discusses its status in details. Most of the simulation works deals with circuit simulation, but there are attempts to handle mechanical devices as well. Collins and Forbus (Collins and Forbus, 1987) discuss qualitative modeling fairly complex) of steam propulsion plant. Joskovitz (Joskowicz, 1987) applies De Kleer’s approach to modeling of kinematic mechanisms. In spite of the impressive array of the research results and in spite of the fact that qualitative modeling could be (in general) of great utility for engineering work, these authors felt that the state of the art in this field is not mature enough to warrant an attempt to include such a capability in the Function Advisor. It appears that the essential issue here is that of the granularity of the product representation and the extent of automation. Should the Function Advisor represent the product at the level of parts and systems, or down to a level of individual attributes (variables) that describe the parts and their behavior (as it is done in qualitative modeling)? Furthermore, should the system itself reason about what affect a change in a given variable has on another? Within the scope of Function Advisor, we choose to focus on a higher level of granularity, leaving it to the human engineers to address the deeper and more granular modeling

and reasoning.

3. Function Advisor Objectives The methodology described in this paper was born out of results of a study of the engineering process in one of the engineering organizations of the Ford Motor Company. This particular organization designs and supports production of internal combustion engines, complex products comprised of hundreds of parts. The engineering process for each new model of product takes several years. The engineering organization employs hundreds of engineers and engineering managers (herein referred to as the knowledge workers). In that study, support of information sharing among multiple knowledge workers was seen as crucial in: improving product and process quality, reducing errors, and improving accuracy in decision-making. The Function Advisor is intended to be an engineering domain specific, Artificial Intelligence based software tool for reasoning about products/systems and related engineering activities. This is particularly important for large, complex, distributed engineering organizations, where the distributed and concurrent nature of the engineering process makes the task of preserving correctness and consistency of the product design non-trivial. The primary objective of Function Advisor is to support, direct, and manage consistency and completeness of design-related and other engineering activities in such an organization. The Function Advisor acts as an environment that accepts information generated by multiple knowledge workers, monitors consistency and completeness of the information, and stores it in appropriate engineering databases. It also provides warnings and advice when a potential inconsistency arises, and helps to access multiple sources of knowledge and data. The Function Advisor was not intended to be a design tool. It remains for the engineers to do what they do best, that is, make specific design decisions. Instead, the Function Advisor is to assure that these decisions are not overlooked, are not in conflict, or done at the wrong time. The objective is to support and coordinate human activities, not to replace them. Thus, the Function Advisor may be viewed as an integrated decision support system in application to designintensive organizations. The functional objectives of Function Advisor can be subdivided (approximately) into four major groups: Advise

the human user regarding the tasks (user’s functions) to be performed, their status, content, and interrelations in organizational and product-wise dimensions (hence the name Function Advisor). -

Retrieve

organize and convey (particularly through graphic presentation) to the human user prestored information that is intelligently limited and relevant to the user’s needs and functions. -

Infer and pro vide to the user information that is not explicitly available in the prestored form, particularly information regarding interdependencies between the various elements of the product, activities, etc.. Monitor consistency, completeness, and correctness of the informational transactions and the information itself. Warn appropriate parties when a violation is detected. More specifically, the Function Advisor should possess the following set of functional capabilities:

• provide inference mechanism to reason about the representation of the engine products, the design activities, and the design organization itself in an integrated, product-centered way • alert a human knowledge worker when an abnormal or inconsistent situation arises in the overall world of the design activities: new constraints or goals are introduced; dependencies are violated (a design of a part is revised after it has been used in the design of another part); activities are delayed; etc. • suggest a plan of design activities to any of the human designers, based on the current status of the design • advise a human designer on dependencies between the parts of the product, and between the design activities • find parts, constraints, interactions, tests, activities, and people that are relevant to (affect or are dependent upon) the particular group of parts or activities for a particular human designer • prevent attempts to finalize a design when its affecting designs or constraints are not finalized yet • collects, store, distribute, and assure completion of product documentation • detect those parts whose design is particularly dependent on new design decisions (high risk parts) and advises the responsible knowledge workers • identifie and suggest suitable, in a given context, special-purpose design aids (both Al systems and conventional analytical), and provide intelligent interface between these aids and a human designer • guard against reoccurring design errors by representing and finding relevant constraints and past problem records, presenting them to a responsible designer, and documenting relevant engineering actions

4. Product Modeling in Function Advisor Central to the needs discussed above is an intelligent sharing of information between multiple knowledge workers. In an engineering organization, the majority of information that needs to be shared focuses on the product being engineered. Thus, the product model is a crucial foundation for Function Advisor. Our product model is comprised of the following major elements: PARTS arranged in an “and-or” hierarchy CONSTRAINTS imposed on the PARTS INTERACTIONS between the PARTS TASKS needed to engineer the PARTS EMPLOYEES assigned to the TASKS

5. Hierarchy of PARTS We predicate our approach on a hierarchical schema model of the product being engineered. A strong hierarchical structure is inherent in many industrial products and systems. An automotive engine is a good example: it can be decomposed into a number of major modules, such that connectivity between elements within each given module is much stronger than between the modules themselves. The major modules can be further decomposed into submodules, assemblies, subassemblies, parts, features, etc. Decision-making in designing or configuring such an object is also done hierarchically: first, some top level features are established, then a more detailed level is developed, etc. Decisions made at a higher level of the hierarchy have major impact on the lower level decisions. The knowledge about such an object is well suited for representation by the hierarchical schema approach, in favor with Al researchers since the 1960’s (Manheim, 1966), (Preiss, 1980). It is a specialization of a fundamental problem reduction

(decomposition) approach of Al. The problem reduction approach may be explained by observing that humans often solve problems by factoring them into smaller subproblems, then factoring these subproblems into even smaller elements, and so on, until resulting subproblems are small enough to be solved by some simple means, such as using known solutions. This approach has been used successfully for a number of engineering design and configuration problems, where it is often referred to as a “refinement” method (Stefik, 1981), (Maher and Fenves, 1985), (Mostow, 1984), (Mittal and Araya, 1986), (Steinberg, 1987). The task of engineering a piece of machinery is well suited for a problem reduction approach. The task of designing a piece of a machine can be subdivided into tasks of designing its major modules (or major features), which can be decomposed into tasks of designing its major assemblies, and so on, until we reduce our problem down to a task of choosing between standard assemblies or parts, or assigning values to known variable dimensions. Clearly, to enable a computerized advisor to use the problem reduction approach, it must be given at least two categories of knowledge: 1. how to decompose a given feature or a module into smaller sub-features or sub-modules 2. what alternative choices or implementation options are available for each feature or module The first type of design information is commonly found in various Product Structure and Bill of Materials systems of representation. However, those approaches do not allow one to represent the design alternatives within the product structure. They are limited in their ability to generalize the knowledge about the product. Thus, there is a need to represent explicitly the second form of product knowledge; knowledge of alternative approaches to design or implement a given functional part or system. This information can be conveniently stored in an “and-or” tree of hierarchical schemata. A schema is a description of a concept, or an object, that contains its attributes, associated procedures, and relations to other schemata. Each schema is a node in a network (in our case it will look more like a tree) of schemata. Relations between the schemata form the links in the tree. This tree of schemata holds all necessary knowledge of the products offered by a particular manufacturer. In our model, we store in each schema either the parts and features that comprise the object (in this case we call that schema an “and-node”), or the alternative implementation options available for this object (in such a case we call that schema an “ornode”). For example, to describe an engine we form an or-node schema engine and include in it a number of alternatives it can be a V6-ABC model, or V8-XYZ model, and so on. On the other hand, a particular engine model may include a number of components or features, like: engine block, cylinder head, camshaft, starting system, etc. Therefore the schema that represents the particular engine model is an andnode. These sub-items in turn have various optional implementation, or sub-elements. The combination of all these schemata forms an and-or tree that we call the Product Knowledge Tree (see Figure 5-1). When Function Advisor needs to reason about the product, it can refer to this hierarchical model and find what alternative choices are available, and also how to subdivide the task of designing the product into smaller tasks of designing the product’s sub-items. Note that schemata can hold information other than sub-parts or alternatives. It can also contain values of attributes, references to constraints and interactions vis-a-vis other parts, responsible employees, related tasks, dates, etc. -

This approach is predicated on model-based reasoning. The knowledge base in our approach has a high content of declarative knowledge, is highly structured, organized into a network of locally self-sufficient chunks, and connected with explicitly defined relations. Such a knowledge base is most appropriate when ease of maintenance is of major importance. In addition, this organization of knowledge is very natural for a hierarchically structured product; it has a promise of making the most from the existing systems and information bases. The Product Knowledge Tree appears to be easier to maintain than, for example, a more conventional rule-oriented knowledge base. The schemata of the Knowledge Tree are independent

chunks of data, that can be entered, modified, and updated without interferences with other chunks. The information contained in the Product Knowledge Tree is very similar in nature to the information usually contained in part indexes, specifications, sales books, etc.; it is therefore more intuitive for industrial specialists. Also, there exist editing tools for schema networks (Kahn et al., 1987), (Carnegie Group, Inc., 1988), that allow one to display information in a graphic form, to browse the information, and to edit it via interactive schema filler.

6. PART PART is a basic element of the product model. It may represent a physical part, an assembly, a system, or a material that is present in the product. A functional system of parts is also a part, even if it is not an assembly. Furthermore, any aggregation of parts that a user may find useful for some purpose is a part. The parts within the aggregation do not have to be physically connected. An abstraction of several parts also can be a part. A part is described by its date (attributes) and by the procedures (methods) associated with the part. Parts can be modified by the design agents, either human designers or computer programs, by changing their attributes. Parts are related to each other via a number of relations, including IS-A, PART-OF, IMPLEMENTATION-OF, and others. Relation IS-A is used to describe a relation between a more specific sub-class of parts with a more general class of parts. Relation PART-OF is used to describe a link between a part and a larger aggregation to which the part belongs. This is a link between a child of an and-node and the and-node. Relation IMPLEMENATION-OF is used to describe the relationship between a part and an abstraction; of which the part is one of many possible implementations. This is a link between a child of an or-node and the or-node. In addition to being linked via relations, parts can be connected via interactions and constraints as described below. Depending of the relation chosen, one can form a number of different networks or trees, each of which may be thought of as a “perspective.” The same set of parts may be viewed in a number of different perspectives, particularly hierarchical perspectives, depending on the relation chosen. For example, the IS-A relation between parts can be used to view them from the perspective of IS-A hierarchy. Another possible perspective is the Product Knowledge Tree obtained via relations PART-OF and IMPLEMENTATION-OF. One of the main objectives of modeling the product is to be able to determine when an action of one engineering agent presents a possible concern to another engineering agent. To this end, the product model includes representation of TASKS and EMPLOYEES. Tasks are attached to parts to indicate that completion of certain engineering activities are necessary to fully define a part. Tasks can be inherited from a more general class of parts to a more specific sub-class via the IS-A relation. Tasks can be also inherited by an and-node from its children (sub-parts) and by an or-node from its specific implementation. An employee is assigned to a particular task or, alternatively, directly to a part, thereby assuming complete responsibility for all the tasks associated with the part.

7. INTERACTION INTERACTION represents an influence that exists between two parts. The presence of an interaction between two parts means that there exists a connection between the states that these two parts can assume.

Part A is said to experience interaction from part B if there exists a way to change a state of part B such that part A will also change its state. In other words, an interaction is an influence that comes from part A, and affects the state of part B. Unlike a constraint (described below), an interaction can be defined between two and only two parts. Also unlike a constraint, an interaction represents a physical phenomenon that exists independent of human opinion (e.g., force of gravity is an interaction, while requirement “piston XYZ must weigh less than 4 lb” is a constraint). Both constraints and interactions describe dependencies between parts. They have some common attributes and procedures that may be abstracted into a concept of dependency. However, interactions, unlike constraints, exist, and are enforced independently of human desires and opinions; they are not man-made. Interactions, as we define them here, provide for a useful representational mechanism that covers both structural and functional aspects of a product model. It subsumes those aspects of model that are usually thought of as: structural modeling relative spatial location of the components (next-to, above, etc.), types of physical connections (welded, bolted, etc.); physical pathways of material flows through a series of parts; etc. functional modeling inputs and outputs of components (fluids, sparks, forces, etc.); primary and secondary functions of parts (what they do to other parts); modes of malfunctioning (failures). All these are described by interactions in a uniform manner.

8. CONSTRAINT A CONSTRAINT may refer to one or several parts of the product. It represents a certain condition on the attributes of the part(s) that must be observed in order for the product to be satisfactory (e.g., to be functional, reliable, producible, etc). The constraints are established by human knowledge workers and may be analytical (derived from some relatively deep mathematical model of the parts and their interactions) or purely empirical (derived from less formal interpretations of the available experience). A Constraint describes a dependency that is required to exist between the attributes of the constrained parts. It is a man-made dependency imposed by the human designer in order to satisfy certain goals or requirements of the design (e.g., functionality, reliability, etc). Both constraints and interactions represent dependencies and have some common attributes and procedures. The constraints serve as means of guarding against an erroneous design. They are commonly based either on the problems that have been actually observed on some previous designs, or on existing compilations of engineering analyses and experience, such as design guides. The role of constraints can be significantly expanded by the utilization of interactions. In order to do so, constraints should be connected by the interactions which serve as information links between the constraints. Interactions enable a propagation of a design change effect to the next significant constraint. Constraints provide a means to control the (potentially explosive) propagation of information: a constraint may contain a method that serves to determine whether further propagation through the nearby interaction(s) is warranted. Thus, the two forms of the connections in the product representation perform

mutual “check and balance”. Consider the following example. Power is transferred from a shaft to an alternator via a belt-and-pulley mechanism. An automatic tensioner mechanism (ATM) also interacts with the belt. The network of interactions is as follows: • the shaft has fixed connection to the driving pulley • the driving pulley has dynamic contact with the belt • the belt has dynamic contacts with ATM and the driven pulley • the driven pulley has fixed connection to the alternator • there is a constraint reflecting engineering relations that must hold in a belt-and-pulley mechanism, attached to four parts: both pulleys, ATM, and the belt. Note that if the alternator design is changed, is is hardly desirable to propagate this information to the shaft designer, because, in this type of product, an alternator is normally designed to comply with the restrictions imposed by the shaft design, and not the other way. However, if the shaft is changed (e.g., its maximum speed), this information should be made available to the designers of the ATM and the alternator. Such control of the information propagation can be handled by the constraint mentioned above. It is done by discriminating between AFFECTED-PARTS (parts that are affected by other parts participating in the constraint), and AFFECTING-PARTS (parts that are causing the effect captured by the constraint). The design change effects are propagated only in one direction, from the affecting parts to the affected parts. In this example, the constraint specifies that the driving pulley of the affecting part, while the ATM, the belt and the driven pulley are the affected parts. This assures that the propagation of the changes between the shaft and the driven parts occurs in one direction as described above. Alternatively, or additionally, this control can be handled by the PARTS themselves (e.g., driving pulley will let the warning to pass from the shaft to the belt and further, but not from the belt to the shaft). The cooperation between the constraints and the interactions provides a certain generalization of the particular problems that is addressed by the constraints. Consider some examples: • A certain part P must be guarded against chemical interaction with some substance X. This can be formulated in a following constraint: there must be no substance X in all parts that contact P, and in all parts that are connected to P via the combined paths of “mechanical-contact”, “mass-transfer”, or “chemical- interaction”. Note that the constraint is generalized by using interactions. Now when constraint is checked, the designer will be given an exhaustive list of potential sources of X. Also, the designer will be alerted if someone changes material of any of those parts. • A certain part P must be guarded against vibratory excitation. The constraint states that a vibration of some frequency F must not come from all parts that are related to P via chains of “mechanical-contact” interactions. These parts are checked both at constraint checking moment, and at the moment of alterations. Thus, the original specific constraint (part X connected to part P must not vibrate with frequency F) has been generalized and extended to all parts that might be sources of harmful vibrations.

9. Use of the Model in Function Advisor Use of the model in Function Advisor is based on two major concepts:

• monitor and guard consistency and completeness of the engineering information generation by propagating constraints through a network of human agents. The relations between the agents are derived from the model described earlier. • support and control engineering information retrieval by identifying a relevant environment (the “information blizzard’ problem). The relevance of various information items is determined from the same model.

10.

Constraint Propagation in a Network of Human Agents

The first concept, that of propagating constraints through a network of human agents, stems from a view that a central component of many engineering design problems can be represented as a constraint satisfaction problem (CSP). A constraint satisfaction problem can be formulated in the following way: given a set of variables that together define the design artifact, find some assignment of values to these variables that satisfies all the applicable constraints. The constraints are the restrictions and requirements of structural, functional, and performance nature. In our case the variables are the various characteristics, attributes, and features of the engine components, e.g., dimensions and materials. The constraints are the various physical laws, engineering relations, design, performance, cost, and safety restrictions and requirements (e.g., geometric relations, strength requirements, fuel economy goals, dimensional standards, material requirements, etc). The problem is to assign every variable a value, such that all the constraints are satisfied as fully as possible. One approach to solving the constraint satisfaction problem is the constraint propagation method. It works (approximately) as follows. Assume that a problem solver has assigned values to several variables (say, A, B, and C). Now the problem solver finds the constraints that involve these variables A, B, C, as well as some other variables E and F. From these constraints, the problem solver infers a range of values that can be used for E and F, given the values assigned to A, B, C. In this way, the decision made about A, B, C has propagated to E and F. Now that the problem solver knows more about E and F, this information can be further propagated toward variables G and H that are related to E and F via some constraints. Now, who is that “problem solver”? Who is assigning values and interpreting the constraints? There are some knowledge-based design systems where the assignment of the values and the propagation of the constraints is done by the computer. However, at this time, the task of designing (and often innovating and inventing) a complex, multi-component product seems to be well beyond the boundaries where such an automation is possible. We suggest that the task of actually identifying and assigning the design variables should be left to those who do it the best, the human designers and managers. The computer system, on the other hand, can be effectively used to support the storage, control, and propagation of the constraints. This cooperation between the human agents (designers, managers, test engineers, etc.) and the Function Advisor is reminiscent of the constraint propagation paradigm. Consider the following example. A designer, Mr. X, has just competed the design (or part of the design) of part A. The Function Advisor finds that these design decisions affect parts B and C via some constraints. Function Advisor advises designers Ms. Y and Mr. Z who are responsible for the parts B and C, that new information is available about part A, and it affects their parts via such-and-such constraints. As more decisions are made, this propagation continues through the whole network of human knowledge workers. Figure 10-1 illustrates a network of knowledge workers connected via the parts and constraints.

11.

Relevant Environment Identification

A second concept, identifying the relevant environment, is motivated by the need to put some intelligent bounds on the amount of information that is imposed on the user at any given time. The amount of information in an engineering database is too vast for a human to deal with. The problem could be magnified many times if an automated information sharing system (such as the Function Advisor) is introduced. Such a system could easily overwhelm the user with hundreds of messages and warnings. It is important to find a middle ground between giving the user too little information (like in the conventional database usage, where the user must either interrogate the system using some query language or use specialized application screens), and giving the user too much information. We suggest resolving this dilemma by introducing the concept of a relevant environment. An environment is a set of conceptual objects (schemata) linked by relations. The set is formed by the Function Advisor by obtaining data from a conventional database and organizing it into objects using prototypical schemata as templates. The system is given instructions that define which objects and which relations should be included in the set (i.e., which ones are relevant). The selection of the set (definition of the relevance) is dependent on the responsibilities of the user, the type of the task she/he is performing, and the focal object of her/his interest. Once the relevant environment has been identified, retrieved from the database, and stored in memory, the system displays this environment in a graphic format. Consider the following example. An engineer is interested in finding records about the past product failures that might be relevant to the design she/he is working on. Here, a failure record might include any information which impacts the part with respect to marketing, recall, and service analyses. Given the task “find relevant failures” and a part that the engineer is concerned about, the system first looks for those past failures that are linked to this particular part. It is possible that there are no failures registered for this specific part, especially if it is still in the design process. The system then knows to look for the functionally similar parts and their related failures. If the number of failures found is not excessive yet, the system continues by looking for the failures registered for those parts that interact with this part (via “constraints” or “interactions’s). It then may continue to look for failures related to the material of the parts, to the manufacturing process, etc. Then the system displays all the objects found (parts, interactions, constraints, failures, materials, processes, etc.). They form an environment where every object and relation is, in some respect, relevant to the task of the user. The number of the objects within the environment is reasonably large to give the user all the right pointers, but not so large as to overwhelm the user. Granted, the above process may not put into the environment all of the objects that the user needs. However, it provides the user with a good starting point for expanding the environment by graphic manipulation of the objects already present within the environment.

12. Conclusions The ability to share information between multiple knowledge workers in an intelligent way is a key to Concurrent Engineering in a large engineering organization. We find two major themes in this information sharing: 1. a knowledge worker needs help in retrieving information that is relevant to his/her task from multiple and heterogeneous datastores 2. a knowledge worker needs help in obtaining information about the actions and decisions of other knowledge workers that affect his/her task

We argue that, in an engineering organization, the shareable information evolves around the product being engineered. Therefore, a model of the product is an important foundation for any system that strives to support the process of Concurrent Engineering. We describe a product model comprised of an and-or hierarchy of parts, constraints, interactions, tasks, and employees. This model is utilized by a prototype computer system, the Function Advisor, in two ways: 1. to propagate constraints through a network of knowledge workers 2. to identify information that is relevant to a given knowledge worker and his/her task

References Carnegie Group, Inc. Knowledge Craft 3.2 Documentation. Carnegie Group, Inc., Pittsburgh, PA. Collins, J., and Forbus, K. D. Reasoning about Fluids via Molecular Collections. In Proceedings of Sixth National Conference on Artificial Intelligence, AAAI-87. Seattle, WA: 1987. ,

Davis, R. Diagnostic Reasoning Based on Structure and Behavior. In Bobrow, D. G. (Ed.), Qualitative Reasoning About Physical Systems. Cambridge, MA: The MIT Press, 1986. De Kleer, J., Brown, J. S. A Qualitative Physics Based on Confluences. In Bobrow, D. G. (Ed.), Qualitative Reasoning About Physical Systems. Cambridge, MA: The MIT Press, 1986. Finger, S., Fox, M. S., Navinchandra, D., Prinz, F. B. and Rinderle, J. R. Design Fusion: A Product LifeCycle View for Engineering Designs. In Second IF/P WG 5.2 Workshop on Intelligent CAD. Cambridge, UK: IFIP, 1988. Fink, P. K. A General Expert System Deisgn for Diagnostic Problem Solving. IEEE Transactions on Pattern Analysis and Machine Intelligence, September 1985, Vol. pami-7(5). Forbus, K. Qualitative Process Theory (Technical Report 789). Cambridge, MA: MIT, 1984. Forbus, K. D. Qualitative Process Theory. In Bobrow, D. C. (Ed.), Qualitative Reasoning About Physical Systems. Cambridge, MA: The MIT Press, 1986. Greif, I. Software for the ‘Roles’ People Play (Tech. Rep. MIT/LCS/TM-210). Cambridge, MA: Massachusetts Institute of Technology, 1983. Hartzband, D. J., and Maryanski, F. J. Enhancing Knowledge Representation in Engineering Databases. Computer, September 1985. lshida, B., Eshelman, L. Integrating Model-Based and Syndrome-Based Diagnosis (report CMUCS-87-1 11). Carnegie-Mellon University, 1987. Joskowicz, L. Shape and Function in Mechanical Devices. In Proceedings of Sixth National Conference on Artificial Intelligence, AAAI-87. Seattle, WA: ,1987. Kahn, G. S., Breaux, E. H., DeKlerk P., and Joseph, R. L. A Mixed-Initiative Workbench for Knowledge

Acquisition. International Journal of Man-Machine Studies, 1987, 27,167-179. Knapp, D. W., and Parker A. C. A Design Utility Manager: the ADAM Planning Engine. In Proceedings of 23rd Design Automation Conference. ,1 986. Kuipers, B. J. Qualitative Simulation. Artificial Intelligence, 1986, 29, 289-338. Maher, M. L., and Fenves, S. J. HI-RISE: A Knowledge-Based Expert System for the Preliminary Structural Design of high Rise Buildins (Report R-85-146). Pittsburgh, PA: Department of Civil Engineering, Carnegie-Mellon University, 1985. Malone, T. W., Grant, K. R., Turbank, F. A. The Information Lens: An Intelligent System for Information Sharing in Organization (Working Paper CISR WP No. 133). Cambridge, MA: Massachusetts Institute of Technology, 1986. Manheim, M. L. Hierarchical Structure: A Model of Design and Planning Processes. Cambridge, MA: MIT Press, 1966. Marshall, C., and Downes-Martin, N. Configuration Tracking System: A Distributed Product-Structure Knowledge-Base. In Intelligent and Intergrated Manufacturing Analysis and Synthesis, ASME publication PED-voL25. ASME, 1987. Mittal, S., and Araya, A. A Knowledge-Based Framework for Design. In Proceedings of the Fifth National Conference on Artificial Intelligence. Philadelphia, PA: ,1986.

Mostow, J. Rutgers Workshop on Knowledge-Based Design. S/CART Newsletter, October 1984(90), pp. 19-32. Nguyen, C. T., and Rieu, D. Expert Database Concepts for Engineering Design. (Al EDAM), 1987, 1(2), 89-1 01. Ohsuga, S. Conceptual Design of CAD Systems Involving Databases. In Gero, J. S. (Ed.), Knowledge Engineering in Computer-Aideed Design. North-Holland, 1985. Pan, J. Y. Qualitative Reasoning with Deep-Level Mechanism Models for Diagnosis of Mechanism Failures. In The First IEEE Conference on Artificial Intelligence Applications. ,1984. Preiss, K. Data Frame Model for Engineering Design Process. Design Studies, 1980, 1(4), 231 -243. Sathi, A., Morton, T.E., Roth, S.F. Callisto: An Intelligent Project Management System. Al Magazine, winter 1986, 7(5), 34-51. Stefik, M. Planning with Constraints (MOLGEN: Part 1). Artificial Intelligence, 1981(16), pp. 111-141. Steinberg, L. I. Design as Refinement Plus Constraint Propagation: The VEXED Experience. In Proceedings of AAAI Six National Conference on Artificial Intelligence. Seattle, WA: ,1987. Talukdar, S., Elfes, A., Papanikolopoulos, N. Concurrent Design, Simultaneous Engineering and Distributed Problem Solving (Technical Report). Engineering Design Research Center, Carnegie Mellon, 1988.