Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


2. BACKGROUND

Configuration design problems are generally exponentially complex, that is, they suffer from a combinatorial explosion of parts and their possible interactions. Parts have ports that limit the ways they can be connected or interact, which reduces the problem combinatorics. In addition, functional decompositions are used to identify one-to-one mappings from parts to the functions they perform in the design. Functional decompositions reduce the combinatorics by limiting candidate parts to those that implement low-level functions, thus reducing the allowable combinations of parts. The sum total of the individual low-level functions implemented by the parts in the configuration is the functionality desired of the complete designed artifact by the user.

A variety of techniques have been developed to manage the complexity of configuration design. In early work, the problem was viewed as the selection of given parts from parts libraries that would be properly combined to obtain the functionality specified by their use, satisfy constraints, and achieve optimality goals (Mittal and Frayman, 1989).

Early design applications include: paper-handling system design (Mittal, Dym, et al., 1986), elevator design (Marcus, Stout, et al., 1988), and computer design (Birmingham, Gupta, et al., 1992). The most common technique utilized in these early systems was a centralized system that maps functions into parts that perform those functions. Configurations are then formed by selecting parts to implement functions, and the design is then extended by eliminating the remaining choices according to: (1) the functions that have already been implemented, (2) the allowed connectivity of the configuration, (3) design constraints, and (4) optimality criteria.

Now, when parts implement more than one function, termed the multifunction part problem, configuration design is further complicated. Similarly, when parts require additional functions for their correct operation -- the support-function problem -- additional complications ensue. In both cases, the increased complexity results from the need to consider the topology of the selected parts in solving the problem. In multifunction part problems, parts can implement more than one function (Mittal and Frayman, 1989; Haworth, Birmingham et al., 1993), so a designer must take into account two major issues when selecting a set of parts to achieve the functionality desired by the user: minimizing the number of extraneous or redundant functions implemented by the selected parts, and minimizing the number of selected parts. Minimizing the number of extraneous or redundant functions eliminates waste, since all the functions implemented by a part are used. Minimizing the number of selected parts tends to minimize performance attributes of the final solution (e.g., cost, power consumption, area, weight) because multifunction parts tend to behave better than a set of single-function parts that implement the same functions (e.g., cost less, consume less power, etc.). The GOPS algorithm solves the multifunction part problem optimally in a centralized, nondistributed way (Haworth, Birmingham, et al., 1993).

Support functions are functions that are required for the correct operation of a part (Mittal and Frayman, 1989; Gupta, Birmingham, et al., 1993; Haworth, Birmingham, et al., 1993). These functions are needed in addition to the original functions specified by the designer. With support functions, a designer must keep track of which functions are needed at any point in the design process, based on the current set of selected parts.


TABLE 1
Multifunction Part/Support Parts
 
Name of part Cost ($) Power (W) Function(s)
 
80186 20.0 3.0 CPU, timer, address-decoder,
interrupt-controller
8086 10.0 2.5 CPU
8259A   3.0     0.425 Interrupt-controller
PAL18P8L   3.0   0.05 Address-decoder
PAL18P8B 3.12   0.05 Address-decoder
PAL18P8A 3.02   0.05 Address-decoder
8254A5 4.95 1.0 Timer


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.