Challenges and Opportunities for Innovation in the Public Works ...

Arthur Baskin and Stephen C-Y Lu
constraint relationships between known and unknown attributes eliminates the need to pre-specify
input and output parameters in IDEEA-based models (R-a-2). This makes IDEEA suitable for
multi-participant problem solving, where each participant may provide different inputs and seek
different outputs. The interval value specifications provided by IDEEA's composite values
remove the need for users to select a single value in order to use the model. This enables
IDEEA to be used during both early and later stages of decisions where interval and atomic
values are desirable (R-c-1). The explanation facility in IDEEA provides the ability to examine
the constraint networks in either a graphic or text-based manner with multiple levels of
abstraction (R-b-4). This makes the knowledge in the model more understandable by other human
or machine-based knowledge sources (KSs) which may have different perspectives.
6.5 Processing Know-Why Knowledge for Concurrent Engineering
To support concurrent engineering, it is necessary to include several know-how KSs which can
contribute their different expertise to the product being developed. There will be many instances
where these know-how KSs suggest competing ideas during a product development process which
evolves over a period of time. It is necessary to manage those competing suggestions
systematically to maximize the values of differences. A critical issue here is the ability to keep
track of why a particular decision was made by a particular know-how KS at a particular time.
In other words, it is necessary to explicitly model engineers' product development know-why
knowledge on computers. Here, know-why knowledge represents the rationale of decisions made
by know-how KSs, and the history of a decision-making process involving one or several knowhow
KSs over a period of time. Processing decision rationale supports better coordination of
competing perspectives provided by multiple participants, while tracing the decision history
facilities explicit management of multiple decision stages.
A design evolution management (DEM) methodology (26) was developed which supports the
acquisition, representation, and utilization of decision rationale and processes (R-b-l). This
methodology was implemented in a prototype system, called AIDEMS (An Interactive Design
Evolution Management System) (see Figure 5). Know-why knowledge is represented and utilized
in AIDEMS at both strategic and tactical levels. Decision strategies are explicitly modeled in
the form of plans whose structures consist of a refinement hierarchy, parallel view-paths for each
refinement, and sequential views within a view-path. View-paths represent the different life-cycle
perspectives considered and views record the incremental, increasingly detailed stages of product
development activity. This representation enables the establishment of a strategic context based
on different perspectives, which is critical to the proper management of later design tactics.
Design tactics are captured as decision procedures whose execution results are represented as
connections. Connections record the interdependent relationships which exist among decisions
made in a product description (R-b-2). These explicitly recorded connections can be used to
explain attributes of a product description and automatically (R-b-4) modify them when changes
in design strategies or tactics occur at the later stages (R-b-3). This is an important feature for
supporting decision making at multiple stages during product development (R-c-4).
6.6 Processing Know-What Knowledge for Concurrent Engineering
When solving complex system problems, such as the concurrent engineering task, engineers are
68