![[MY HOME PAGE]](../gif/home.gif){kind=small}
![[TOP]](../gif/top.gif){kind=small}
![[UP]](../gif/up.gif){kind=small}
Philip J. Koopman, Jr
Formerly of: United Technologies Research Center
Daniel P. Siewiorek
Carnegie Mellon University
Draft, revised August 16, 1994
Note: this pre-publication draft was written as input to an NSF proposal from the Carnegie Mellon University Engineering Design Research Center (CMU/EDRC). The ideas were primarily contributed by Phil Koopman (UTRC), Dan Siewiorek (CMU), and Tilt Thompkins (UTRC). This is an essay rather than a scholarly paper; no references are provided.
Two vital issues in design are not addressed by current engineering design methodologies: efficient handling of changes, and explicit representation of both behaviors and structures in the same framework. We propose an augmented model of design that couples behavior and structure in a way that supports a variety of strategies for making the design process efficiently responsive to change. This model is based on hierarchically layered pairs of behavior and structure that represent successively higher levels of design abstraction.
Previous work at EDRC has focussed largely on the design synthesis cycle. In this cycle high-level artifact descriptions, sometimes called architectures, are refined into implementations and then evaluated against design criteria. Because the precise meanings of "architecture" and "implementation" vary by engineering discipline, we shall simply use the word "structure" to refer to the physical or logical arrangement of entities within a system. This cycle of iterated synthesis and evaluation of structures is well documented and widely practiced.
As a result of our previous work, we have come to recognize that two vital issues in design are not addressed by current methodologies: efficient handling of changes, and explicit representation of both behaviors and structures in the same framework. Taking a broad view, changes to designs are related not only to product evolution, but also to support for product families, customized installation, changes to in manufacturing process, and changes in available components. While tools to deal with either behaviors or structures exist for many disciplines, there seem to be no good ways to deal with tradeoffs between behaviors and structures, especially in cross-discipline applications.
Figure 1. Engineering design requires dealing with the life cycle,
process, technology, and abstraction.
We believe that a solution lies within the context of four major aspects to design: process, life cycle, technology, and abstraction (Figure 1). Process deals with people, organizations, and methodologies to accomplish designs. Life cycle aspects deal with cradle-to-grave considerations that should be dealt with up-front in the design process. Technology includes not only materials and processes available to manufacture artifacts, but also infrastructure available to service artifacts, and design process support tools. Finally, abstraction involves using simplified, high-level representations of designs as a way to master complexity. While all four aspects are essential for successful engineering design, we shall single out abstraction as a vehicle for dealing with change.
We propose an augmented model of design that couples behavior and structure in a way that supports a variety of strategies for making the design process efficiently responsive to change. This model is based on hierarchically layered pairs of behavior and structure that represent successively higher levels of design abstraction.
Dealing with complexity by layering design representations is prevalent throughout engineering. This layering appears in various disciplines in such concepts as: subsystem decomposition, functional decomposition, control hierarchy, and component subassemblies. In addition, most disciplines use simplifying assumptions in order to make analysis tractable. We shall refer to any such use of layering or simplification by the term "abstraction", and exploit it to support design for change.
Figure 2. Engineering design abstraction uses layers to move between
Design Goal setting and Customer Evaluation.
Figure 2 shows a simplified model of abstraction in the design process that, for the moment, defers the issue of representing structure and behavior. We shall describe it in a top-down fashion, although in general the process can be executed in any sequence.
At the top of Figure 2 is Design Goal Setting. This an activity that determines the envisioned utility of the artifact being designed. At the bottom of the figure is Customer Evaluation, in which the customer evaluates the usefulness of the artifact. It is worthy of note that sometimes the ultimate success of an artifact hinges on the customer finding utility that was not originally envisioned by the designer. Nonetheless, the design process is typically meant to accomplish transformations between Design Goal Setting and Customer Evaluation.
Between Design Goal Setting and Customer Evaluation is the design process. In Figure 2 we show the process as having refinement stages (the process in this figure has one refinement stage; real processes will often have multiple such refinement stages). The Initial Design stage is a high-level design formulation that takes into account design goals and is evaluated in terms of correctness, completeness, and various figures of merit (e.g., cost, weight, size, human factors, speed). The Refined Design stage is a more detailed design that is in turn fed by Initial Design goals and evaluated according to refined criteria. Iterations among levels are likely in any real design process as goals are modified in an attempt to improve evaluation scores.
Even though a process of abstraction allows using simplified artifact descriptions, these descriptions must nonetheless be complete. For engineering design, this means that not only must a behavior be specified, but also a structure in which to embed that behavior. For example, if a design includes the structure of a switch (or, more generically, a sensor of indeterminate type), then it is typically desirable to somehow describe the behavior of that switch when actuated. Similarly, specifying the behavior of a switch actuation makes no sense without the context that there is, in fact, the structure of a switch.
Figure 3. Design layers must each deal with both Structure and Behavior.
Figure 3 shows that inside each design stage (both Initial Design and Refined Design) are two components: Structure and Behavior. At the level of Initial Design, Structure is a proposed artifact organization in terms of both physical and logical sub-entities (e.g., subsystems, functions, assemblies). The Behavior consist of operational scenarios and sequences for these sub-entities. For example, if the input Goal is transportation, and the initial Structure is a car having an engine and transmission, then initial Behavior might include sequences of operation such as engine start, transmission shift into gear, and engine acceleration. It is possible to have tradeoffs within both structure and behavior as well as between them. For example, a simpler behavior (eliminate overt gear shifting operations) might come at the expense of a more complicated structure (a continuously variable transmission). Conversely, one could see the tradeoff as the transmission structure being simplified (discrete gears instead of continuous variability) at the expense of complicating the behavior (adding the concept of shifting gears).
At the next design layer down, the Refined Design is similarly composed of a Structure and Behavior. The refined Structure is the detailed organization of the artifact (e.g., components, modules) necessary to implement specifics of initial Behaviors. The refined Behavior has a greater level of detail to address the greater complexity of the refined Structure. To further the example, the refined Structure for the transmission might be an automatic or manual transmission. The refined Behavior for the manual transmission would include details of clutch pedal operation irrelevant to a refined Behavior for a manual transmission.
The process of design is not static. We hypothesize that there are two primary design activity loops between every pair of layers in the design abstraction hierarchy. Figure 4 shows two layers of design that could be embedded in a multi-layered design abstraction framework. There are two loops that represent separate but complimentary processes: structure synthesis (Figure 4a) and behavior refinement (Figure 4b). Structure synthesis involves refining and evaluating structure by way of an intermediate behavior. Behavior refinement involves refining and evaluating behavior by way of an intermediate structure.
Figure 4a. The structure synthesis loop generate the refined Structure.
Figure 4b. The behavior refinement loop generates the refined Behavior.
We believe that the two loops of structure synthesis and behavior refinement must be executed together to successfully accomplish design tradeoffs. In both Figures 4a and 4b, goals from the Initial Design are used to suggest a trial design that is then evaluated. In behavior refinement, a trial Structure yields constraints on the refined Behavior. In structure synthesis, a trial Behavior yields constraints on the refined Structure. But, both loops must be executed together to achieve a bidirectional tradeoff within the Refined Design.
Until now, the EDRC has concentrated mainly on structural synthesis. However, unlike the loop in Figure 4a, the Behavior description was left implicit rather than explicit. Thus, this design framework points out the need to have explicit behavioral descriptions. Furthermore, the framework shows that our previous work has largely ignored the Behavior Refinement loop that is required for complete tradeoffs. This opens up near term opportunities in defining and implementing complete synthesis loops for both behaviors and structures, as well as a long-term opportunity to integrate the execution of both loops to allow complete tradeoffs among behavioral as well as structural aspects of design.
Given an abstraction-based view of design, it is possible to consider different ways to address the problem of design for change. A simple approach is to execute the design process so as to isolate likely effects of changes into single subsystems or components. For example, in the automobile example the postulation of a transmission structure permits change between automatic and manual transmissions (different product families), incremental introduction of new transmission technology without disrupting the rest of the system design (e.g., smoother shifting), and response to changing market requirements and government constraints (e.g., adaptive shifting points depending on terrain).
While manual redesign of single subsystems is a good start to dealing with change, it may be possible to accomplish even more. In some disciplines, synthesis tools are becoming available that do direct synthesis from a higher level description. The design abstraction framework suggests that design for change can be accomplished by having designers work at a higher level of abstraction than the actual system components, then let synthesis tools create the bottom layer or two of refined designs. Clearly this will result in a design cost and speed vs. efficiency of implementation tradeoff that must be evaluated on a case-by-case basis.
These example approaches require correctly predicting the types of changes that are likely to occur in order that they might be encapsulated. Thus, it will be important to understand the forces of change from factors including: external constraints (governmental and cultural forces), markets, competition, innovation, and technology. Once the forces of change are understood, the design abstraction model provides a framework in which to understand and deal with those changes.
We believe that over time better understanding and improvement of this design framework will reveal additional opportunities for design for change as we gain experience. While it is likely that the framework will evolve as new approaches to dealing with change are discovered, we feel that the use of the framework presented here provides a solid foundation for getting started.
Phil Koopman -- koopman@cmu.edu