Lessons from PACT and SHADE

			   Jay M. Tenenbaum
	   Enterprise Integration Technologies Corporation
		       and Stanford University

The Palo Alto Collaborative Testbed (PACT) is a joint experiment in
concurrent engineering being pursued by research groups at Stanford
University, Lockheed, Hewlett-Packard, and Enterprise Integration
Technologies.  PACT is exploring issues in designing and building a
framework of frameworks, i.e., integrating multi-tool systems that are
themselves frameworks, each independently developed with no
anticipation that they would subsequently be integrated.  This
situation is commonly encountered because individual engineering
groups prefer to maintain their own tool suites and integration
environments.  Accordingly, our primary emphasis has been on
agent-based architectures for inter-framework communication --
developing shared ontologies (concepts and terminology) for sharing
knowledge across disciplines, an interlingua for transferring
knowledge among different representations, and a communication and
control language that enables agents to request information and
services from each other. This technology allows tools to interact at
the "knowledge level". Tools associated with different aspects of a
design must share selected information about their internal models and
design decisions in order to cooperatively solve engineering problems.
PACT is thus serving as a testbed for knowledge sharing research
emerging from the artificial intelligence community, as well as for
emerging product data exchange standards such as PDES.

The PACT experience has provided several key insights on the
difficulties of building large-scale integrated systems that may bear
on the knowledge sharing and standards process more generally. They
are:

1. service orientation: exchange services rather than trying to
tightly integrate heterogeneous representations.

Existing tools maintain their own local representations and are likely
to continue to do so for two good reasons: problem specificity and the
efficiency afforded by local caching.  In PACT, each tool is
encapsulated by an information agent which can communicate with others
using a common interlingua, command language and ontology.  The
agent's job is externally, to route and filter messages in this common
protocol as described above, and internally, to translate messages
from the common protocol into the internal object formats used by its
tool.

2. Federated Models: information Agents interact directly or through a
shared model.

A shared model is appropriate when several agents must interact,
because it is easier to define one common interface with the model
than n^2 pairwise interfaces. Note that only information common to a
set of agents need be included in their shared model. A shared model
can be defined for each community of agents with common interests, and
an agent can exist in multiple communities. This approach leads to a
federation of local models, rather than a global, unified meta-model.
There may indeed be a single model encompassing the shared interests
of all agents in an organization, but the amount of information it
contained would likely be very limited.

3. Bottom-up Modeling: shared ontologies evolve bottom-up within a
top-down framework, in response to concrete examples. We do not
believe that any single ontology (i.e., standard) is universally
applicable across subsystems, applications, and lifecycle interests.

In PACT, we spent the first six months attempting to design a top-down
ontology of engineering. We accomplished very little until we selected
a concrete system and example applications as contexts for our work.
Specifically, the initial PACT experiments explored knowledge sharing
in two related contexts -- the distributed simulation and incremental
redesign of a simple electro-mechanical robot manipulator. Each system
in PACT was used to model different aspects of the device (e.g., the
controller, circuitry, sensors, and power system), and to reason about
them from a different discipline (dynamics, digitial electronics, and
software).


SHADE is a shared, semi-formal representation for engineering
knowledge, that is being developed to support collaborative product
development teams.  Such a representation must enable many individuals
from all stages of product development to interact with each other.
It must encompass a much wider variety of knowledge than is
traditionally covered by standards (i.e., geometry), much of which is
not machine interpretable.

The critical technical problems to be solved are the unification of
many types of knowledge involved in design, the integration of
machine-interpretable formalisms and informal multimedia materials for
humans, and the active maintenance of the information in a distributed
world where the effects of changes are propagated to the appropriate
people and their software agents. To address these problems, SHADE
will have a novel combination of features:

{\bf (1) Comprehensive.} the representation will be sufficiently
expressive to describe and interrelate a very broad scope of product
knowledge, including kinds of knowledge not currently available in
machine-readable form.  The representation will be more than a union
of existing idiosyncratic representations; it will be based on a
declarative language with a well-founded semantics that allows one to
explicitly specify the meaning of and relationships among a variety of
knowledge types.  The representation will not only support direct
statements about product knowledge, but also statements that relate
existing languages (e.g., for algebraic constraints, or decision
support) into a coherent theory.  In particular, the representation
will be capable of directly specifying, or incorporating existing
representations of, the following types of information:

\begin{itemize}
\item  design requirements (formal and informal)
\item  descriptions of the artifact (structure, function and behavior)
\item  engineering information sources (on-line handbooks, design and process
	libraries, parts catalogs, textbooks etc.)
\item  explicit design decisions (issues raised, alternatives considered, 
        evaluation criteria, justifications)
\item  models of manufacturing processes
\item  models of the engineering process, throughout the product lifecycle
\end{itemize}

A design will be represented as a sequence of moves in the design
space defined by the design descriptions listed above.  Each design
move may involve several kinds of design descriptions.  For instance,
a decision might involve a choice among alternative parts retrieved
from a library, in response to a changed design requirement.  Each of
these parts would be evaluated in light of several criteria such as
the results of simulation of the behavior of the parts and an analysis
of its manufacturability against a given process model.  The
representation for decisions will allow the explicit recording of
relationships among {\em all} these sources of information, which is
not possible using today's isolated formalisms.

As a product evolves or is modified over time by many people in many
contexts, its representation will grow into a vast web of dependencies
that today are tracked manually, if at all. This representation will
support distributed development teams by providing a basis for tracing
the design process, determining how decisions were made and assessing
their sensitivity to changes. This is necessary for ensuring that
appropriate analyses were performed, experts consulted, parts ordered,
etc. It is essential also for redesign --- for understanding what must
be changed in response to changes in each aspect of the specifications
and for retrieving previous designs that can be adapted to fit current
goals.

{\bf (2) Semiformal.} The representation must include both structured
information that is interpretable by computers and unstructured
information that may only be meaningful to people.  Examples of the
latter include E-mail, pages from a handbook containing text and
diagrams, or animated displays produced by a simulation program.
Formalizing such engineering knowledge is a long-term research agenda,
so capturing it in raw form is the only practical way for the
foreseeable future.  Even in such a form, it can still be annotated
and organized using a declarative formalism, making it much
more accessible to members of the product team, as suggested above.
When combined with fragments of knowledge that {\em are} formalized
--- such as behavior equations, CAD models, and netlist descriptions
of circuits --- the semiformal representation is a powerful tool for
integrating information for human communication and automated
processing.

Objects representing both formal and informal elements of the design
record are seamlessly woven through the dependency links into a single
``hypernet''. Slots of formal objects can point at other formal objects
or at objects that encapsulate text, graphics, or video.  Conversely,
designated active areas of unstructured information can be linked
either to other unstructured information or to formal objects.  Like
the objects they connect, the dependencies themselves are first class
objects that can range from formal to informal. The weakest but most
general is simply the existence of a relationship between two
entities: ``X has something to do with Y''. More specific relationships
range from causality (``X causes Y'') to precise analytic constraints
(Y=2x+3). Clearly, the more detailed and semantically meaningful a
relationship, the more sophisticated the computer collaboration aids
it can support.  However, as shown below, even primitive dependency
links can be exploited by computers in clever ways.

{\bf (3) Change propagation and notification.} The representation is
{\em active}
in the sense that computer programs actively manage the shared
knowledge bases.  When something in a knowledge base changes, its
dependency relationships with other facts can be determined, either by
following explicit links or by inference.  The effects of
the change can then be propagated to dependent facts.  For example, the
change in a parameter might trigger a spreadsheet-like recalculation of
dependent parameter values in an equation model, or even invoke a
rule-based constraint checker to verify that the value is within the
allowable range.  Where the weakness of dependencies precludes
automatic propagation, the representation can still actively notify
agents (human and their computer programs) whose decisions might be
affected by a change.  For example, changes to requirements can result
in flagging all components that depend on those requirements.
Similarly, modifying a component can trigger an agent to rerun an
analysis or simulation, or to retrieve the handbook and catalog pages
originally used in component selection, so that they can manually be
reviewed.  Such triggers can result directly because of an expression
of interest by the agent involved, or indirectly through a link to an
engineering process step that specifically calls for a given analysis
or sign-off procedure when a particular change is made.  To provide a
basis for managing the propagation of dependencies, we are working to
formalize what each decision depends on, so that agents can better
determine when to reconsider it.