CA2215294A1 - Flash configuration cache - Google Patents

Abstract

The present invention provides a constraint-based configuration (10) system using structural hierarchy. The structural aspects of the model provide the ability to define a model element as being contained in, or by, another model element. To configure a system, the present invention accepts input in the form of requests (202), such as an expression of a need for a desktop computer system to be used in a CAD
environment. Using this information, the present invention configures a system by identifying the resource (210) and component needs, constraints imposed on or by the resources or components identified, and structural aspects of the system. In one embodiment, a flash configuration cache (10) is utilized, and in another embodiment a bundling cache is used to speed up the process of configuring an end product, such as a user computer.

Description

CA 0221~294 1997-07-12 W 096/28784 1 PCTrUS96/03406 FLA~I CONFIGURA~ION CACHE
BACKGROUND OF THE INVENTION

This is a continuation in part of United States patent application ~ntitle(l "Method and Apparatus for Configuring Systems," Serial number 5 08/039,949, filed March 29,1993, and A~signe~l to the assignee of the present application.

1. FIELD OF THE INVENTION

This invention relates to the field of computer-based ~ysLellL
configuration.

2. BACKGROUND ART

Configuring a ~ysl~ refers to the process of s~lecting and connecting components to satisfy a particular need or request. If a ~ysL~lll is based on a limitefl number of components, the process of configuring the :iy~L~lll can be relatively straightforward. For example, the purchase of an automobile requires a salesperson to configure a ~y~l~lll (automobile and assorted 20 options~ to satisfy a customer's request. After s~lerting from a plurality ofmodels, the salesperson completes the trAn~Action by s~lecting options to configure and price an automobile. The configuring of such a simple :jysL~
can be Accc.mplished with a pencil and paper.

As ~y~ lll specifications become more customi7eri and varied, configuration alternatives increase and the task of configuring a ~y~lelll berom~s more complex. This increased complexity has resulted in a need for CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 computer-based assistance with the configuration process. Early computer-based systems expand indep~n~l~ntly-generated configuration orders for syslellls into manllfactllring orders. They do not address the actual need for computer-based tools prior to the order expansion. That is, they do not 5 address the actual generation of a system configuration based on needs and/or request input.

An example of a complex system is a desktop computer system. The available configuration alternatives of a computer 5y5L~llL are numerous and 10 varied, including alternatives available when choosing the microprocessor, motherboard, monitor, video controller, memory chips, power supply, storage devices, storage device controllers, modems, and software.

Configuring a desktop computer system requires that a s~l~rtefl 15 component is compatible with the other components in the configured system. For example, a power supply must be sllffi~i~nt to supply power to all of the components of the system. In ~ lition, the moni~or must be compatible with the video controller (e.g., resolution), and the storage device must be compatible with its controller (e.g., SCSI interface). A motherboard 20 must have enough slots to hanllle all of the boards installed in the sysLellL.

The physical constraints of the cabinet that houses the system's components are also considered. The cabinet has a fixed number of bays available for storage devices (e.g., floppy disk drives, hard disk drives, or tape 25 backup units). These bays have A~l~litional attributes that further define their use. For example, the bay may be located in the front of the cabinet and provide access from the front of the cabinet. Another bay may be lorate~l CA 0221~294 1997-07-12 W 096t28784 PCT~US96/03406 behind the front-~ccessihle bays, and be limiterl to devices that do not need tobe accessed (e.g., hard disk drive). Bays may be full-height or half-hPight-Before a storage device can be added to the configuration, a configuration ~y~ must identify a bay into which the storage device will be housed. This 5 requires that at least the ~cressihility and height of the storage device must be examined to determine compatibility with an available cabinet bay.

The connection between a storage device and its controller must be ll~prminell based on the location of each. The cable that connects the storage 10 device and its controller must provide compatible physical interfaces (e.g., 2 pin male to a 2~pin female).

A method of establiching a rommllnir~h--n pathway in a computer :iy~ l is known as daisy rh~ining Daisy rh~ining provides the ability to 15 interccnnect components such that the signal passes through one component to the next. Determining whether a daisy chain may be established requires that the available logical (e.g., IDE or SCSI) and physical interfaces (e.g., 2~pin) of all ~ m~ntc in a daisy chain be known. In addition, it is important to know whether conversions from the source datatype to the destinAtion 20 dataty-pe are allowed. When a daisy rh~ining rAn~ te is added to the ~y~le---, the inLelco~ ectiQnc and conversions between existing components may be rherke~l to determine whether the new component should be an element of the daisy chain.

The power supply and storage devicè component examples illustrate the need to define the structural interrPl~hon.chips belw~-- components (i.e., physical and spatial r~l~tionchips). To further illustrate this notion, conci-1~r CA 0221~294 1997-07-12 W 096/28784 4 PCTrUS96/03406 placing components requiring electrical power such as computer, teleccmmunication, medical or consumer electronic components into two cabinets. Further, each cabinet has an associated power supply that supplies electrical power to the components inside the associated cabinet. To account 5 for electrical power consumption and the requirement that no power supply is overloaded, the model must comprehend the specific cabinet in which each component is placed and update the consumed power for each cabinet.
While the total power available in the two cabinets may be sufficient for all ofthe components to be placed in both of the cabinets, a component cannot be 10 included in a cabinet if its inclusion would cause the cabinet's power supplyto overload. Th~:.erore, the physical plAcPm~pnt of the component in a cabinet must be known to make a determination if the subsequent plAcPment of a component is valid. SimilArly, any physical conn~Pctions between these components must be taken into account. Each ccrnpenent's position in the 15 structural hierarchy is used to determine minimAl or optimal lengths for the connecting components.

Early computer-based configuration systems employed an approach referred to as the rule-based approach. Rule-based configuration systems 20 define rules (i.e., "if A, then B") to vAliclAte a selection of configuration AltPrnAhve5. Digital Equipment Corporation's system, called R1/XCON
(described in McDermott, John, "R1: A Rule-Based Configurer of Computer Systems", Artificial Intelligence 19, (1982), pp. 39-88) is an example of a rule-based configuration ~y:,L~ . R1/XCON evaluates an existing indep~ntl~nfly-25 generated ~y:jL~ order and irl~nhfie~s any required mo~lihrAti( ns to the~ysL~ to satisfy the model's configuration rules. The rules used to ~lr.,.m the configuration and vAliclAhQn processes are numerous, interwoven, and CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 interdep~nllPnt Before any modification can be made to these rules, the spider's web created by these rules must be understood. Any changes to .hese rules must be made by an individual that is experienced and knowledgeable regarding the effect that any mo-lificAfic)ns will have to the entire set of rules.
5 Therefore, it is rlifficlllt and time-consuming to mAintAin these rules.

A possible solution to the problems associated with rule-based ~y~L~ s is a constraint-based :jyslelll. A constraint-based ~ysl~m places constraints onthe use of a component in a configuration. For example, a hard disk drive 10 cannot be added to the configuration unless a compatible storage device controller is available for use by the request storage device. The requirement of a controller is a "constraint" on the hard disk drive.

While existing constraint-based ~y~L~ms address some of the 15 shol~co...ing~ of rule-based ~y~L~ s, they do not provide a complete configuration tool. Pure constraint-solving ~y~LellLs do not employ a generative approach to configuration (i.e., they do not generate a ~y~l~lL
configuration based on needs, cc, ll~onent requests, and/or resource requests).
Existing constraint-based ~y~l~llls use a fi-nctionAl hi~lcu~ly that does not 20 address structural aspects associated with the physical plArf~mPnt of a component in a configuration (e.g., m~mory chip on motherboard or m~mory expansion board, storage device in cabinet bay, or controller in motherboard slot).

Bennett et al., United States Letters Patent No. 4, 591, 983 provides an example of a cullsLlaillt-based ~ysLI:lll that employs a recognihon or verification approach to ~ysL~lll configuration instead of a generative CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 approach. That is, Bennett merely vAli~lAtPs an independently-configured system. In essence, an order is generated by an indepPn~lPnt source sudh as a salesperson, and 13ennett is used to verify that the ~ysL~ contAinefi in the order does not violate any constraints. Bennett does not generate a ~ysl~ll, 5 configuration based on needs or component requests (i.e., a generative approadh). Thus, Bennett does not provide the capability to interactively configure a system by interactively selecting its components.

A model consists of all of the PlPmPnfs that may be induded in a 10 configured system. In Bennett, the model PlPmPnt~ are grouped into an aggregation hierarchy. An aggreg~h~n hierardhy creates hierardhical levels that represent a group of PlPmf~nt~ Brandhes from one entry in the current level expand the entry, and the entry is "composed of" the PlPm~nt~ in the lower level brandhes. For example, a desktop computer ~y~ ll is "composed 15 of" a keyboard, a monitor, and a system box. A system box is "composed of" a power supply, motherboard, cards, and storage devices. The "composed of"
relationship merely describes the PlPmPnt~ that comprise another element.
However, the "composed of" rPlAhorl~hip does not define the structural rPlAtion.chips between the model PlPmPnt~. The "composed of" rPlAhon~hip 20 does not describe the physical, structural rPlAtiQnchips Amc)ng the elemPntc sudh as "physically contAine-l inside," "physically subordinate part of," and "physically connectP~l to." Using the desktop computer ~y~L~lll previously described, it cannot be determined whether or not a monitor is "physically contAine/l inside" a desktop computer system. A system box is "composed of"
25 storage devices, however it cannot be determined whether one or more of the storage devices are "physically c~ntAine-l inside" the ~y~Lelll box.

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 A fu~ctionAl hierarchy organizes the components of a model based on the purpose or filnction performed by the components in the model. Each entry in the hierarchy can be further broken down into more specific filnctionAl entries. Thus, an entry's parentage ~fin~s its functionAlity, and 5 progression from one level to the next particularizes the flmctionAlity of a hierarchy entry.

As used in current configuration :jy~ s, a functional hierarchy does not define the structural interr~lAtiorl~hips or the physical and spatial 10 interCoIlnection~ Amcng ~olem~nt~. A filnctionAl hierarchy cannot place a storage device in a cabinet bay, a controller card in a particular slot on the motherboard, or a memory chip in a slot on the memory expAn~ion board.

Figure 2 illuslrales an example of a fimctic)nAl hierarchy.
15 HardwareComponent 30 is the root ~lement of the hierarchy. The next level below HardwareComponent 30 (i.e., the second level 49) identifies general functions in the model. For example, ROM 31, Processor Unit 31, Processor 32, Memory 34, Cage 35, Board 36, ~'onnector 37, and Storage Device 38 all perform the flln~tion of Hardware Component 30 in Arl~lition to their own 20 speriAli7efl filnction~. Processor 33 can be speriAli7~1 to the function of a SpecialPurpose 40 or GeneralPurpose 41. SpecialPurpose 40 can be speria to ArithmeffrProcessor 51.

Referring to Figure 2, it can be seen that a filn~ional hierarchy does 25 not provide the ability to define the structural aspects of the :jy~ m. For example, there is no capability to determine the cc-ntent~ of Cage 35. The physical and spatial location of MotherBoardSlot 54 desrenclin~ from Slot 46, CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96103406 in turn ~iesc~n~1ing from Connector 37 cannot be determined from the functional hierarchy. There is no way of determining that MotherBoardSlot 54 is contAin~cl by the motherboard. It is not clear from the filnrfion~l hierarchy fl~finihc n whether Arithmeti.-Processor 51 is located on the 5 MotherBoard 44 or another model ~l~ment It cannot be deL~lllLined whether MemoryChip 42 and ROM 31 are located on MotherBoard 44, M~mcryBoard 52, or another model ~lemPnt A functional hierarchy does not provide the ability to define actual 10 iL.~t:rc~..n~rfion~ between configured instances or the data transfer. That is, that one component is co~necte-l to another with compatible logical datatypes (e.g., serial interface) and compatible physical ilLLerco..n~chnn~ (e.g., 24 pin). A filnchon~l hierarchy only ~lefines the function that a component performs.
Because it does not define the actual conn~cfioIl~ between the components s~lecte-l for a configuration, it cannot establish a daisy chain between configured components . Referring to Figure 2, a fil"chon~l hierarchy ~l~fin~ l'onnertor 37, Storage Device Controller 53, Floppy Drive 20 48, and Hard Drive 49 as types of components. To conserve resources, a user may wish to configure a system such that an occurrence of Floppy Drive 48 is daisy ~ h~ine~l to an occurrence of Storage Device Controller 53 through Hard Drive 49. However, the functional hierarchy can only reflect that fact that a configured system may ccntAin the filn~ tion~lity provided by Storage Device 25 Controller 53, Hard Drive 49, and Floppy Drive 48. It cannot reflect the factthat an occurrence of Floppy Drive 48 is connecfe-l to an occurrence of Storage Device Controller 53 through an occurrence of Hard Drive 49.

CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 - Thelerore, a flmchQn~l hierarchy can not traverse a ronnectinn pathway to identify structural interr~l~tion~hips among configured instances.
Thus, a functional hierarchy cannot establish a daisy chain. Th~lerore, a 5 funrtionAl hierarchy can not provide the ability to daisy chain component~-Another example of a constraint-based ~ysl~ln using a fllnctic-n~l hierarchy is provided in the following articles: Mittal and Frayman, "Towards a Generic Model of the Configuration Task," in Pro~eerlings of the 10 Ninth lJCAI (l;JCAI-89), pp. 1395-1401; and Prayman and Mittal, "COSSACK: A
Constraints-Based Expert System for Configuration Tasks," in Sriram and Adey, Knowledge-Based Expert Systems in Engineering: Pl~nnin~ and Design, September 1987, pp. 143 66.

The Cossack ~y~ L employs a function~l hierarchy-based configuration :jy~ . According to CQSS~k, a :~y~ ln using a fllnchon~l hierarchy must identify a configured ~y~ lll'S required fllnchon~. Once the required filnctioTl~ are i~nhfiP~ oss~k must identify some particular component, or components, that are crucial, or key, to the impl~mPn~tion of 20 these required filn~ tion~. The Cossack repr~r.t~on does not make structure explicit. Further, ~'oss~k does not provide me~h~ni~m~ for reasoning about or with structural inform~hon Th~:lerole, Coss~--k cannot make any structure-based illrel~llces. For example, the internal data transfer paths within components are not represented. Therefore, there is no ability 25 to trace data transfer within a component, and no ability to establish a data connPction with another ~l~m~nt CA 0221~294 1997-07-12 W096/28784 PCTrUS96/03406 A conffguration system, whether used to configure a computer system or other system, should provide a tool to interactively: define and m~int~in a model; define and m~intAin (i.e., upgrade) a configured :jy:~Lelll; generate marketing bundles; generate a graphic repr~cPnt~tion of the physical and 5 spatial locations of the components of the configured system; use the graphic represPnt~tion to modify or upgrade a configured system; and generate configuration reports (e.g., failed requests, quotations, and bill of materials).
Such a ~y~Lt:lll must define the components of a ~y~L~ll4 the structural r.ol~tion.ships ~mong the components (i.e., spatial and physical lo. ~tion~), the 10 actual physical and spatial interronnertion~ of the components, and the constraints imposed by each component.

CA 0221~294 1997-07-12 W 096t28784 11 PCTrUS96/03406 SUMMARY OF THE INVENTION

The present invention employs a generative approach for configuring systems such that a ~ysLelll may be configured based on component or 5 resource requests, or input in the form of need. The present invention provides a constraint-based configuration :jy:jL~ using a flmctionAl hierarchy that colllpreh~ ls hierarchical and non-hierarchical shructure, and associated constraints that can reason about and generate structural r.olAtionships. The shuch~ral aspects of the model provide the ability to 10 define a model elPmPnt as being contAine~l in, or by, another model .olement In addition, the struchurl model provides the ability to identify logical datatype and physical interconnection.s between elements and establish connçctions between ~lem~rlts.

To configure a :jy~lelll, the present invention accepts input in the form of requests (e.g., component or resource) or needs, such as an expression of a need for a desktop computer system to be used in a CAD (i.e., computer-aided design) environm~nt Using this informAhon, the present invention configures a ~y:,L~ln by identifying the resource and component needs, 20 constraints imposed on or by the resources or components i~l~nhfie~l, and the struchural aspects of the ~y~l~ll..

The sy~ ll- configuration can be based on a general tl~finition of a ~y~Lelll (i.e., desktop computer system to operate in a CAD environmPnt), or 25 at any level of increased specificity (e.g., disk drive by manl~fAc~hlrer and model number). The ~y~L~ll- configuration can be based on specific component requests (e.g., laser printer), or by need (e.g., printing capability).

CA 022l~294 l997-07-l2 W 096/28784 12 PCT~US96/03406 Once the system is configured, the configured ~y~ can be blln-lle~l into products, and a quote can be generated. The bundling process may include the spe~ificAtion of heuristics to control the product-to-component mapping.
For example, the product that covers the largest number of components can 5 be sPle~tefl over other possible product sPlectionc that cover a lesser amount of components.

The functional, structural hierarchy of the present invention provides the ability to define the structure of the configuration model and the :jy~ s 10 configured from the model. The structural hierarchy includes a contAinPr structure. A rcnPinPr provides the ability to specify that one component is contAinP-l by, or in, another component. Thus, it is possible, for example, to identify that a component request for a disk drive cannot be sAhcfiP~l because there are no empty cabinet bays in the cabinent specified to contAin the 15 component requested.

The structure hierarchy notion provides the ability to pool resources.
Explicit reprPCPntAhon of structure, spe- ifirAlly hierarchical structure, provides the ability to define and access inherited resources. For example, computer, telecommllni~Ation, medical, or consumer electronic components can be placed in a cabinet that provides power to those components. These individual components can inherit the electrical power resource from a structural superior (i.e., a hierarchical entry that resides one or more levels above the components in the model hierarchy). Further, the structural 25 superior can pool resources and provide an homogeneous resource to its structural inferiors (i.e., a hierarchical entry tht resides one or more levels below the structural superior in the model hierarchy). For example, a cabinet CA 022l~294 l997-07-l2 W 096/28784 13 PCT~US96/03406 might contAin more than one electrical power source, however, the resource is pr~srnteri to struchurally inferior components as a single resource pool.
Thus, if a component requires a particular resource, this resource can be supplied by a resource pool. For example, if a desktop computer system's 5 cabinet contains multiple power supplies, a disk drive component may draw from resource pool without any knowledge that the resource need is sAfisfie~l by multiple power sources.

In Ari~lihon, the sh uctural sperifirAtion provides the ability to specify 10 the ronn~chon~s between components of a configured ~y~lelll. As components are added to a configuration, the physical and logical in~lro....echons that are required to assemble the :jysL~l~l components may be verifie/l For example, before A~lcling a printer with a serial logical connection and a 24 pin physical connectirn to the configuration, a serial port 15 must be available in the configured ~y:,L~m. In A~1~1ition, a physical connertion must be made between the ~ L~l and a serial port. If the serial port is a 9-pin female physical ronnection and the printer has a 2~pin female ronn~rhon, a cable must be available to physically ronn~rt the ~lillL~l and the serial port. In A~l~lition, the actual ronrlechon is created in the configuration 20 and can be exAmine~l in subsequent connection pror~ssing . C'onnPrhon procf~ssing provided the ability to identify any criteria for satisfying a connection request. For example, connection criteria may indude the cheapeast, longest, or optimal throughput connertion-Connection pror~ssing may also be used to optimize the use of the configured ~y~L~n's resources. For example, a controller's resources can be optimi7e~1 by daisy rhAining other components together. By cor nerhin~ one CA 022l~294 l997-07-l2 W 096/28784 14 PCTrUS96/03406 component to another via multiple intervening components, multiple components may be connecte-l to a single component via a single port or connection.

In the presen~ invention, a modeling language is used to define a model hierarchy. The model hierarchy is structural and functional. The modeling language provides the ability to defiine a Product Base that may be grouped into Product Lines. The structural hierarchy model includes the Component, Composite, Container, Port, and Connector base classes. These 10 base classes may branch into derived classes (i.e., system-specific classes) and termin~te at leaf-descent1~nt~. Leaf-desc~n~1~nts define the type of components in the functional, structural hierarchy model. Attributes, datatypes, resources, and constraints further define the model.

A model language provides the format for ~1efining the elem~nt~ the constraints placed on the elemPnt~, and the structure of the model. The model language may be used directly, or generated based on input from an interactive model m~int~n~nce system used to h~ilit~te the creation and m~intPn~nce of the model.
The m~inten~nce system graphically displays the model, and provides the interface for the selection of model element~ to be updated. Once the desired updates have been made, the m~int~n~nce system provides the ability to test the new model, or verify that the new model can be s~lccessfullycompiled.

CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 Once a model has been successfully ~l~fine~l~ the present invention - provides the ability to configure a :,y~lelll using the functiQnAl, shuctural hierarchical model. An interactive interface provides the ability to express a configuration in terms of a model element (i.e., components) request, resource request, and/or needs (i.e., requirements) request. A configuration engine is invoked to satisfy these requests.

The configuration engine acc~ss.o~s the Product Base to satisfy the requests in a rl~finerl priority. A request is processed by ~d~ling components 10 to the configuration, or identifying existing components that can satisfy therequest. Further, the interconnections, data transfer pathways, and dyn~mic~lly-determined struchlral r~lAhonships are dpfinefl- When a request is sllcce~ssfully processed, the configuration modific~tions are "committed." Failed requests are reported.

A graphical depiction illustrates the configured sy~lelll and its structural characteristics. The ~l~m~nts of the configured ~y~elll are illustrated in terms of their physical and spatial location relative to other ~l~m~nts. ~l~m~nt~s are cont~ine~ in other Pl~mPnts~ comprised of other elements, or connecte-l to each other. This graphical depiction further provides an interface to modify and m~int~in el~ment~s of the configured :iySl~

The configured ~y~L~lll's ~l~m~nts are blmcllefl into available marketing and manllf~ctllring pAck~ges for ~y~l~m quotation and manufacturing purposes. The blm~lling process performs a product-component mapping based on product ~l~finitions.

CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 In one embodiment, a flash configuration cache is lltili7e~1 to speed up the process of configuring a user computer. This is performed by taking advantage of the fact that the invention uses a structured set of requests to 5 configure the user computer. The host computer first makes an initial determin~fion as to which set of requests take glea~el time to configure than the time taken to recall the resulting configuration from the host computer cache. Those requests are stored in the cache and are arranged in the form of a tree structure. When a new set of requests is obtained, the sets of old requests10 in the request tree are methodically searched to find a m~t~ hing set of old requests. The configuration col~ ol.~ling to the m~tl-hing set of old requests is then re~ 1 from the cache.

In other emboAiment~ the invention's flash configuration cache is 15 used to speed up the process of configuring a variety of end products. The end products are, for example, electronic systems such as voice mail ~y~l~llls, PBX ~ys~ s, central office switches, and h~n~lh~1~1 communication devices.
The present invention's flash configuration is also used to configure end products such as airplanes where a variety of power ~y~l, options, 1~n~1ing 20 ~y~lell~ options, and interior system options need by configured in an ~ffic~iPnt and thorough manner. Other end products configured by the flash configuration cache of the invention are trucks, test equipment, and l~hPmir~l processes. The flash configuration cache is also used to configure v~r~tion packages where each package involves a number of transportation options, 25 lodging options, and recreational options.

CA 022l5294 l997-07-l2 W 096/28784 17 PCTrUS96/03406 In another embotlim~n~, a bundling cache is used to speed up the process of blm~lling, namely, the process of mapping components required for a user computer configuration, or other end product configuration, into actual comm~rcial products.

CA 022l~294 l997-07-l2 W 096/28784 18 PCTrUS96/03406 BRIEF DESCRLPTION OF THE DRAWINGS

Figure 1 is a block diagram of the configuration computer system.

Figure 2 illustrates a functional hierarchy.

Figure 3 illustrates the functional, structural hierarchy comprised of the five base classes, derived classes, and component types.

Figure 4 is the fllnction~l, structural hierarchy for a model to configure computer ~y~Lellls.

Figure 5 illustrates component interconnertion~ with multiple intervening components and data types.
Figure 6 illustrates the Configuration Fngine process flow.

Figure 7 illustrates the SatisfyResourceRequest process flow.

Figure 8 illustrates the SatisfyC'onPinerConstraint and SatisfyComponentConstraint process flow.

Figure 9A illustrates the SatisfyConnechonConstraint process flow.

Figure 9B illustrates the ~~~n~ t~Ports process flow.

Figure 10 illustrates the EstablishSetCover process flow.

CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 Figure 11 illustrates a system window for a desktop computer ~y~
configuration.

5Figure 12 is a flow diagram illustrating the functional operation of the Configuration System.

Figures 13A-13C illustrate a flow diagram of the algorithm used to construct the search tree in the flash configuration cache.
Figure 14 is illustrates an example of how the search tree of the flashconfiguration cache is constructed.

Figures 15A-15C illustrate a flow diagram of the algorithm used to 15 search the search tree of the flash configuration cache.

Figure 16 is a diagram showing products mapped into available options.

Figure 17 is a diagram showing available options mapped into products.

CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 DETAILED DESCRIPTION OF THE lNVENTION

A metho-l and apparatus for configuring systems is desc~ibed. In the following description, numerous specific details are set forth in order to 5 provide a more thorough description of the present inv~nhon It will be apparent, however, to one sk~ in the art, that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the invention.

The present il.v~lLIion provides a tool for configuring systems that has application to a wide range of ~lomAins inrlll~ling the following: computer hardware, computer software, computer networks, telecommllnicAtion ~y~lell~s (e.g., PBX and voice mail), copiers, medical im~ing systems, vehicles (e.g., fire trucks and construction equipment), electronic control :jy~LellLs~
15 b~ lings, modular furniture, manufacturing equipment, manufacturing ~y~L~ s, consumer electronic equipment, and electronic ~y~L~llls.

Figure 1 is block diagram of the configuration system of this invention.
The configuration ~ysL~lll 10 is comprised of the Model MAintenAnce SuL,~y~L~ 12, the Configuration Generation ànd Reporting Sub:jysL~ll- 14, the Bl1n~ling/Quotation subsy~Lelll~ Communications Bus 18, Input/Output 20, ~mory 22, Central Pror~ssing Unit 24, and Mass Storage 26.

Figure 12 is flow diagram illustrating the fimctionAl o~elaLion of the 25 Configuration System. At block 600, a model base is read. The Configuration System uses a model base that contAins informAtic n about all of the ~lPm~nts CA 0221~294 1997-07-12 W 096/28784 21 PCTrUS96/03406 available to configure a system (e.g., components and resources) This model base is referred to as a Product Base.

A model language is used to create the Product Base. The model 5 language provides the sy-ntax, or st~temPnts, used to define the model elements, the conshraints placed on the model element~, and the sh~ch~re of the model. At processing block 604, the model definition can be entered using the model language and model (l~finipon proce~sing is ended at 606.

Model Maintenance - The process of ~lPfining a model can be facilitated if the Model l~inten~ce Sul~y~l~m is chosen at ~ieri~ion block 602 (i.e., "use Model ~intPn~nce SUbSY~l~1LL?"). At block 608, the model, either new or existing, is displayed. At block 610, the model can be edited. The Model l~inten~nce SUbSYSlem 12 provides the ability to test the validity of and 15 debug the modified model at ~iPri~ion block 612 (i.e., "write integrit ProductBase integrity-, or Debugger?"). A "write integrity-" sPlech~n rletPrminps the integrity- of the parse file (i.e., subsets of the Product Base)with the ~ ition of the mo~1ific~hons. a "ProductBase integrity" sPlection determines the integrity of the Product Base with the addition of the 20 modifications.

If the "Debugger" is chosen, bPnrhm~rk ~y~ m configuration requests are read from a file at block 618. At block 14, the Configuration Generation and Report System 14 is invoked to configure a sysl~m using the modified 25 model and the benchm~rk configuration requests. A trace of the proressing of these requests by the Configuration Generation and Reporting System 14 may be made to ex~mine the configuration process.
-CA 022l~294 l997-07-l2 W 096/28784 22 PCTrUS96/03406 If there are ~ ihc)nal modifications to the model at ~1eri~ion block 622 (i.e., "modify model?"), a graphic repr.ocf~ntAtion of the model is displayed at608, and the mo~fir~ff-~n process conhinll~c at block 610. If there are no othermodifir~fionc, the model ~lr-finihQn is generated at block 624, and the Model nten~nce SU~sy~ lL ends at block 606.

Configuration and Reporting System - The Configuration and Reporting System 14 uses the model ~1~finihif~n to generate a ~y~ LLI
10 configured accol-ling to the user-specified requests and needs. The resulting configuration is graphically depicted. Reports are generated to provide inform~ticn regarding the configuration. If it is determined that an e~asting configuration is being upgraded at rl~ricic)n block 630 (i.e., "upgrading existing system?"), the existing systm is read and its PlPmentc marked as existing in block 632. If a new system is being configured, a blank system instance is created at block 634. The forms used to input element requests or needs is displayed at 636. If input is not complete at ~iericion block 638 9i.e., "requests completed?"), processing continues at block 636.

Configuration Engine - Once all of the request and need input is completed, Configur~hor F.ngine is invoked to generate a configured :jysl~
based on the input at 640. A graphical reprPC~nt~tion of the configuration is displayed at 642. The configuration may be modified, reports may be generated, or the components of the configuration may be blm~le~l and a 25 quotation generated. If morlifir~tirnc are intr-n~le~l at ~lericion block 644 a.e., "configuration modification?"), proressing continues at (lericion block 652 (i.e., "filter model?"). If a filtered model is rhosr-n at (lericion block 652, a W 096/28784 23 PCTtUS96tO3406 subset of the model is generated at block 654. The model subset incl~
those model ~lpm~nt~ that can be s~lecte~ given the current configuration.
Prore~ing cc-ntinlles at 636 to display input forms. If a filtered model is not used, processing continues at 636.

After a ~y~l~m is configured, the ~ m ~nts of the configuration can be bundled into marlceting, or manufacturing, products. Bundler 660 maps the configuration components to products. Quoter 662 generates a cost quotation for the configured SysL~ . At 664, the quotation is displayed. If there are no 10 configuration modifirAtion~ at ~l~ri~ion block 666 (i.e., "configuration modification?"), processing ends at 606. If there are modifirAtion~ to the configllAtion, the Configuration Generation and Reporting Sub~y:,Lelll 14 iS
invoked at block 668.

CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 ST~UCTURAL HIERARCHY

The Configuration System of the present invention is a constraint-based scheme using a functional, structural hierarchy. Figure 3 illustrates the 5 functiort~l, shructural hierarchy and five intrinsic base classes. The functional, structural hierarchy contains a class hierarchy comprised of five intrinsic base classes 70 that define the basic types of model objects. These five base classes are: Component 60, Composite 62,(~onn~ctc-r 64, ContAin~r 66, and Port 68. The Component 62 is the base dass from which all other 10 dasses and component types are derived. From Component 62, each branch of the hierarchical tree begins with an intrinsic base class and branches into system-specific classes called derived classes 88. Derived classes 88 are rl~finition~ of broad component categories, such as storage devices, power supplies, and peripheral cards. Multiple generations of derived classes can descend from the base dasses. Each branch terrnin~s with "leaf descendants," or Component Types 90. Component Types 90, represent actual components that can be insPnh~te(l and configured.

The Composite class 62 iS a static shructure (i.e., .olem~nt~ that have 20 subshructure). Fl~ment~ in this class have, or are, subcomponents of a composition. The ~ nnector class 64 branches from the Composite class 62.
This class ~fin-o~ the model elements that connect ~lem~nt~. An el~mPnt in the ~~ontAin~r class 66 in/1ir~tes that the ~l~mPnt may ccnt~in other ~l~ment~.
Fl~m~nt~ in the Port dass 68 provide the port alternatives and define a port's datatype. Fl~m~nts derived from the Port class 68 can be physically cor-necte~l with other components derived from the Port class 68.

CA 022l~294 l997-07-l2 W 096128784 25 PCTrUS96/03406 The present invention provides the ability to represent within a structural hierarchy how components of a particular system exist spatially and physically. Within the structural hierarchy, there are three type of substructures: composite hierarchies, container hierarchies, and port relationships. Composite hierarchies identify components as part of other components. For example, a ~hA~ has eight card slots. C~ontAiner hierarchies identify components as being contAinefl in other components. A
~~ontAinPr hierarchy is a dynamic structure in that the structure is dynAmirAlly created when a configuration is generated. For example, a CPU
10 card is placed in slot 0 of the ~hA~si~). Port relationships identify components that ~nnert to other components. A ronnertion, or port, rf~lAtion~hip is dynAmirAlly created when a configuration is generated The rPlAtion~hi~s between generations within these substructures a.c expressed by the keywords "childOf," "contAine~lRy," and "connectsWith."

The "childOf" keyword in~iirAt~s that a component is part of a component that is descended from class Composite. The "conPine~lRy"
keyword in~ AtPs that a component is rc-nPinerl within a component that is desc~ncle-l from the ~~ontAin~r base dass. The "connect~With" keyword inrlirAtf~s that a component connert~ to a component that is desr~n~le~l from the Port Class.

~ ~ontAin~r hierarchies typically exhibit an alternating rolAtion~hip withComposite hierarchies. That is, a contAin~r is often a "dhildOf" a composite component, and the composite component is "rcntAine~lRy" another rc-nPin~r. Eadh substructure type has a root member that is also a ~s~n~lAnt of the base class of the same name (i.e., Composite, Container, or Port).

CA 0221~294 1997-07-12 Members of a substructure can be of any class ll~fine~l in the Class Hierarchy.
For example, a component of dass bay, d~cPn~lP~l from Container Class might contain a component of class storage-device (desrPn~lP-l from Component Class) or of class card_chassis (descended from (~ontAin~r Class).

Figure 4 illustrates a structural hierarchy with the five base classes, derived classes, leaf descPn-lAnt~, and substructure r~l~tioll~hirs. The structural rPlAtion~hips further define the structural aspects of the model.
For example, Slot 114 is a "childOf" Cabinet 110. Th~:refole, Slot 110 is a 10 subcomponent of the composite componen~, Cabinet 110. Further, Cabinet 110 is a l'ChildOf" System 116. Second occurrences of Card 118 (i.e., 118A) and Slot (i.e., 114A) illustrate the substructural relationship between Card and Slot. Card 118A is "contAine-lRy" Slot 114A. Similarly, StorageDevice 120A
is "contAinPflRy" Bay 122A, and DB25MaleDeviceOut 124A "connecf~With"
15 DB25FPmAlPl~eviceOut 126.

The structural aspects of the present invention~'s model provides the ability to inherit and pool resources. For example, a contAinPr component, Cabinet, may consist of a ~hA~si~ and two one-hur dred watt power supplies, 20 A and B. Each of the PlPmPnt~ within the chassis rontAinPr consume, or require some amount of power. If the chassis component conf~in~ two central pro~Pssing units (CPUs) that together consume one-hundred and ten watts (e.g., fifty-five watts each), random access memory that consumes seventy watts, and multiple cards (e.g., controllers) that consume a total of 25 twenty watts, neithPr of the power supplies independent of the other could supply sl~ffi~iPnt power to the ~hAs~is and its PlPmPnt~

CA 022l~294 l997-07-l2 W O 96/28784 27 PCTrUS96/03406 However, because the two power supplies are contained in, and are a part of, the Cabinet confAin~r, the two power supplies can be pooled together to supply the elements within Cabinet. Therefore, when the resource requisitions are being processed for the elements in this example, one or the other may be used to satisfy the request. In A~1cliti~)n, it is possible to satisfy the resource need for any one of the ~l~m~nfc by using both power supplies.
For example, if one CPU's resource needs are processed first using fifty-five watts of power supply A, and the resource proc~csing for the RAM is processed next, the resource needs of the RAM maynot be sAficfie-l by power 10 supply A alone. However, it is possible to satisfy the RAM's resource needs by using 45 watts from power supply A and twenty-five from power supply B.
Another resource that may use this resource pooling capability is a heat dissipation resource.

CONTAINERS

The structural hierarchy provides the ability to structure the model such that one model element, or group of model elements, may be ronPine by another. The use of the corlPine-l model ~lem~ont in a configuration will be constrained by the availability of a contAin~r model ~l~om~nt in the configuration.

Figure 8 illustrates the SatisfyC- nPinerConstraint and SatisfyComponentConstraint process flow. At ~le~icion block 500 (i.e., "required instance already available in configuration?"), if the required inctAnce exists and is available to satisfy the constraint, the constraint is sAtisfi~l by this available instance and proc~ssing returns at block 526. If not, CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 the required instance is inst~nfi~te-l, and the Modifir~fic-n~ List is updated at processing block 502. At decision block 504 (i.e., "any constraints to be processed?"), if there are no constraints on the new instance, the constraint is5~fi~fi~-l by the new instance, and prorf~ssing returns at block 526.

If there are constraints to be proresserl, the next constraint is j~lenfifierl at block 508. If it is determined that it is a requires~~onf~inPr constraint at ~ieri~ion block 510 (i.e., "requiresContainer?"), processing continl~ at prorrcsin~ block 512 (i.e., "satisfy~~ont~inerConstraint") to satisfy the 10 requires~~ont~iner col-s~aint, and proc~ssin~ conf nll~ at ~leri~ion block 522 (i.e., "constraint s~ti~fie~l?").

If it is deterInined that it is not a requiresC'ont~in~r constraint at decision block 510, but it is ~leterrninell that it is a requires~~onnf~cfion constraint at cieri~iQn block 514 (i.e., "requiresConnection?"), proressing continues at proressing block 516 (i.e., "satisfyConnecfionConstraint") to satisfy the requires~'onnecfic n constraint, and proc~s~ing continues at 11e~ n block 522 (i.e., "constraint s~ti~fie~l?").

If it is not a requires~'ont~inPr constraint at llefi~ion block 510 and not a requires~'onn~cfior col,sL,dint at ~ ion block 514 (i.e., "requires~~onnecfion?"), proc~sing continues at ~eri~ion block 518 (i.e., requiresComponent?"). If it is determined that it is a requiresComponent constraint at fie~i~lon block 518 (i.e., "requiresComponent?"), pro~sing 25 continues at proc~ssing block 520 (i.e., "satisfyComponentConstraint") to satisfy the requiresComponent constraint, and proc~sing continues at lle- i~ion block 522 (i.e., "constraint s~h~fiP~l?"). At tleri~ion block 522 (i.e., CA 0221~294 1997-07-12 W 096/28784 PCT~US96/03406 "constraint sAti~fie~l?"), if the constraint was sAh~fie-1, processing continues at ~ ~lefi~ion block 504 (i.e., "any constraints to be processed?"). Lf the constraint was not sAti~fi~ the constraint is marked as not being sAti~fie-l by an existinginstance or the new instance, and the new instance is removed from the 5 MorlifirAtir ns List at proce~sing block 524. ProrPssing returns at block 526.

CONNECTION PROCESS~G

The use of a model ~l-om~ont in a configuration may also be constrained 10 by the ability to establish a connechion to another model ~lPn~nt The requires~'onnerhon constraint requires that a physical cc nnertion exist between two compr~nent~. Figure 9A illustrates the process flow for satisfying the requires('onnection constraint. At procP~sing block 280, a target component is splerte~1 and a list of ports is created. At proc~ssing block 282, 15 the requested resources are allocated. At proressing block 284, ~~Anfli~lAt~Ports(list) is invoked to identify llnc~)nnertecl ports that are accessible from the target component At procP~sing block 286, cAn~ lAte local ports (i.e., those ports that are lmronnectecl and have the ap~ liate datatype) are iriPnhifie(l. At pror~ssing block 288, rAnAif1Ate connectors are 20 identified.

At decision block 290 (i.e., have all connectQrs been tested?"), if all of the connectors have been tested, the request is marked as failed, and proressing continues at block 306 (i.e., "return"). If not, the next ronrtertor is 25 s~lerte-l at block 294. At ll~ri~ion block 296 (i.e., "can physical type of rc~nnertor's portl rc)nn~rt with physical type of target port?"), if portl of the connertor is not the same physical type (e.g., 25 pin) as the target port's CA 0221~294 1997-07-12 W 096/28784 PCT~US96/03406 physical type, prorPccing continues at ~lericion block 290 (i.e., "have all connectors been tested?").

Otherwise, proressing continues at decision block 298. At riericjon 5 block 298 (i.e., "can physical type of ronnertor's port2 connect with physicaltype of local port?"), if port2 of the connector is not the same physical type (e.g., 25 pin) as the local port's physical type, processing continues at llericirn block 290 (i.e., "have all connectors been tested?"). Otherwise, procf~csing continues at ~lericion block 300. At ~iericic~n blocl- ~00 'i.e., "does a transfer 10 path exist between portl and port2?"), if a transfer path does not exist between portl and port2, proc~csing contin~lPs at decision block 290 (i.e., "have all rrnnertors been tested?"). Otherwise, the requested resource is allocated at block 302. At proressing block 304, the target port is ronnectP~l to the ~ onnect r's port2, and the local port is rrnnerte-l to the connector's portl.
15 Pro~ .ocsing ends at block 306.

C~n~ te ports must be i~l~ntifi~-l to satisfy a requiresConnectiQn constraint. Figure 9B illustrates the C~n~ teports(list) process flow.
Pror~csing block 310 of ~'~nrli~l~t~Port5(1i5t) set thePort variable to the next20 port in the list. At decision block 312 (i.e., "is the port connected?"), if the port is conn~c te~l, processing ~ ontinll~c at prorPscing block 316. If not, flericic~n block 314 (i.e., "thePort the right datatype or are conversions allowed?") ~lPtermines if the datatypes are romp~tihle If not, proressing continues to block 310 and the next port is found.
If they are compatible, thePort is added to the port list, and procPcsing continll~s at block 310. If it is determined that thePort is already connerte~l at -CA 0221~294 1997-07-12 W 096/28784 31 PCT~US96/03406 (1erisiQn block 312, processing continues at proc~ssing block 316, and newPort is set to the port to which thePort is connected. At block 320, a new port list is created for all ports to which newPort transfers. At ~le~ision block 322 (i.e., "does newList contain a port of the requesting component?"), if the newList 5 contains one of the requesting component's ports, the connertion is marked as already being in existence at block 326 and proc~ssing returns at block 328.
If not, C'~n-licl~t~Ports(list) is invoked for the newList.

CONFIGURATION ENGINE
When the user has selected the components for the ~y5lelll to be modeled, the user requests the invocation of the configuration Pngin~. The configurator accesses the Product Base to identify the object class. After certain v~ tion checks are successfully performed, the configurator 15 instantiates (i.e., creates) a member of that class, called an object instance. The configurator only inst~nti~te~s those objects required to configure the requested :jysL~

The configuration engine processes component and resource requests in the priority specifie-l As each request is processed, the existing configuration is modified by: (1) Acl~iing the requested component and other components required to support the component requested, or (2) idellLiryillg existing components and new components requir~d to provide the requested resource. When a request is sllccessfully processed, the configuration modifi~ ~tions are "committed," and this configuration becc-me~s the input configuration in proce~ssing the next request.

CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 32 Figure 6 illustrates the Configuration Fngine process flow. Prorr-~sing block 202 creates a prioritized list of requests. Lf it is determined that all of the requests have been processed at ~leri~ion block 204 (i.e., "all requests processed?"), processing ends at block 206. Lf not, the next request is s~l~cte~l at pror~sing block 208.

The request type is determined at ~1eri~ion block 210 (i.e., "request type?"). If the request is a component request, proressing continues at proc~sing block 212. At block 212, the component requested is in~Pnh~terl 10 and posted to the Modifir~tion~ List, and procr-~sin~ continues at lleri~ion block 216. If the request is a resource request, the component that can supply this resource is i~lpntifi~fl at processing block 214 (i.e., "SatisfyResourceRequest"), and proc~sing contint~P~ at rlert~ion block 216.
At rleri~ion block 216 (i.e., Inst~nhAhcn or allocation sl~ccessful?"), if the component insPnh~hion or resource allocation is sllcressful, procr~;sing continues at ~l~rt~ n block 224 (i.e., "any constraints to be processed?"). If the component inst~nhi~tion or resource allocation is not s~ccessful, proressin~
continues at ~leri~ion block 218 (i.e., "do any other alternatives exist to satisfy this request?").

If it is deterrnined at ~lr-ri~ion block 218 (i.e., "do any other alternatives exist to satisfy this request?") that no other alternatives exist to satisfy therequest, the request is i~lrntifir-~l as a failed request, and procr-~sing continues at rleri~ion block 204 (i.e., all requests processed?"). If there are other alternatives, the failed alternative's modifir~tion~ are removed from the Modific~hc-n~ List at 220, the next alternative is posted to the Modifications CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 List at 222, and processing continues at decision block 224 (i.e., "any constraints to be processed?").

At ~i~ricion block 224 (i.e., "any constraints to be processed?"), if there 5 are no constraints to be processed, the modifications are cc~mmitted to the configuration at procPcsing block 244, and processing continues at ~iericion block 204 (i.e., "all requests processed?"). If there are constraints to be processed, the next constraint is i~lentihe~l at block 226. If it is determined that it is a requiresContAiner constraint at ~ericion block 228 (i.e., 10 "requiresC'onPinPr?"), pror~ssin~ continues at proc~ssin~ block 230 (i.e., "satisfyContainerConstraint") to satisfy the requiresContAin~r constraint, and processing continues at decision block 240 (i.e., "constraint sAhcfie~l?~ If it is determined that it is not a requiresContainer constraint at fiecicion block 228 but it is determined that it is a requires~~onnechon constraint at rlericion 15 block 236 (i.e., "requiresConnection?"), proc~ccing continues at processing block 232 (i.e., "satisfy(~onn~rtiQnConstraint") to satisfy the requiresConnecti(-n constraint, and processing continues at llerisiorl block 240(i.e., "constraint satisfied?").

If it is not a requiresContAin.or constraint at decision block 228 and not a requiresCo~nectio~ constraint at decision block 236 (i.e., "requiresfonn~rtion?"), processing continues at decision block 238 (i.e., requiresComponent?"). If it is determined that it is a requiresComponent constraint at ~ericion block 238 (i.e., "requiresComponent?"), pro~eccing 25 continues at processing block 234 (i.e., "satisfyComponentConstraint") to satisfy the requiresComponent constraint, and proressing continl1~s at ~ericion block 240 (i.e., "constraint sAticfi.o~?"). At ~lerici~n block 240 (i.e., CA 022l~294 l997-07-l2 W096/28784 PCTrUS96/03406 "constraint sAtisfie~?"), if the conshraint was sAhsfie-i, proces~sing continues at ~leciSion block 224 (i.e., "any constraints to be proc~sseci?"). If the constraint was not sAtisfie~l, processing continl~e~s at decision block 218 (i.e., "do any other alternatives exist to satisfy the request?").

The fact that resources are offered by individual component instances, and are not represented as global system ~ntih~s, assists in the exploration of alternatives. Figure 7 illushrates the SatisfyResourceRequest process flow. At procPssing block 250, the next component that offers the required resource is 10 found. If, at ~iPrision block 252 (i.e., "any component instances found?"), it is determined that no component offers the resource, proc~ssing continues at proc~ssing block 262.

If a component is found, pror~ssing continues at ~i~ri~ion block 254 (i.e., "has this resource been consumed?"). Lf the resource has been consumed pror~ssin~ continues at proc~ssing block 250 (i.e., "Find next component that offers the required resource"). If the resource has not been consumed, a check is made to del~i ...;..e whether class requir~m~nts and optional requir~m~nts are valid at decision block 256. If all of the checks are valid, the current resource instance is rhos~n at proc~ssing block 258, and processing cc-nhn~ s at procl~ssing block 264. Lf one of the checks is invalid, processing co~tinllPS at ~erision block 260 (i.e., "have all resource instances been rherkefl?"). If all of the resource instances have not be rherke~, proc~ssing continues at block 250 where the next component offering the resource is found.

W 096/28784 PCTrUS96/03406 If all of the components offering this resource have been checked, or it is deterInined (at decision block 252) that no existing component offers this resource, proce~ssing co~tinlle~s at block 262, and a new component instance that offers the resource is created, the configuration modification is posted tothe Mo-1ihcAti- ns List, and proc~SSing continues at block 264. At block 264, aninstance of the requested component type is Assigne~l to the requesting component's returned instance variable. Processing continllf~s at deri~slon block 266 (i.e., "does the current instance satisfy query and test conc~iti~ns?~) to deL~ ulle if all query and test fllnctions are sAtisfiefl If not, proc~s~sing10 continues to proc.ossing block 250. If they are, proce~s~sing ends at block 268.

MODEL LANGUAGE

The model language provides the ability to define a model (e.g., model elements, model constraints, and model structure). Using the syntax of the model language, st~t~nt~nts may be entered to d~ ~ nc tl e model base, or Product Base. The Product Base contAinS all of the information about a model. The Product Base co~tAins the information used to configure a ~y~L~lll.

The Product Base may also contain Hierarchical Product Lines.
Product Lines allow a Product Base to be subdivided into groups. An example of such a grouping is marketing divisions, such as DesktopSystems.
A DesktopSystem might contain all of the components that are commonly sold as parts of a desktop computer ~y~L~lll such as operating system software, modem cards, microprocessor chips, etc. Only components that are part of the same product line can be configured together. However, each component CA 0221~294 1997-07-12 W 096/28784 PCT~US96/03406 type can be part of several product lines. Product Lines hierarchies may also be declared. A child in a product line hierarchy inherits from the parent, and every component in the parent is inherited by the child. The format of a product line declaration is as follows (Note: reserved words are bold, double-5 underscores incli~-~te repetitive portions, and portions conPin~l in "<<>>"
are required):

prodllrfT in~ <<ProductLineName>>;
Or, to dedare product line hierardlies:
prodllr~T.ine <<ProductLineNamel>>: <<ProductT inP~Jame2>>;

System models are stored in files, called parse files. (~ollertively, the parse files are known as the Product Base. Parse files cont~in inform~ti( n 15 about a general category within a system model. Data reprP~Pnt~tion~ of individual system parts are known as objects. Cabinets, storage devices and peripheral cards are examples of objects in a Product Base used to configure computer systems. A ~lOp~l ly provides attributes of an object. For example, in a computer ~y~L~ms~ Product Base, r~p~ity, power requirPmPnt~, and 20 connPchon interface are properties of a storage device object. Further, a property categorizes an object. That is, objects with similar ~,o~llies are called a class of objects. Objects can inherit properties from other objects.
That is, one class of objects acts as the parent of another class, and the childclass exhibits all of the properties of the parent class in ~ iTion to others.
Attributes define the aspects of a component that must be con~i~.ored to sl~ccPssfully configure a component. Examples of attributes of a power supply are the cabinet space required for the supply and the rPm~ining power CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 available after power-consuming components are added to the configuration.
Attributes can be ~signe~l at the class level, and descen~l~nt~ of that dass inherit the class attributes. In addition, attributes can be associated with particular component types. There is no limit to the number of attributes 5 that can be assigned to a component or class.

Attribute values may be of type flo~ting point, boolean, string, dataty-pe, component, and resource. Attributes may be multivalued. That is, multivalued attributes can have more than one value. For example, with a 10 component that can use either a full height internal bay or a front ~( c~ssihle bay, the attribute "attribute_Bay_type_required" can retain both values. An attribute is declared by the st~tPment (Note: " I " indicates a choice):

AttributeType <<Attribute Name>>; I
Multivalued AttributeType <<AttributeName>>;

An example of attribute declarations are:

Float Position Float throughput_available Float load_consumed resource space_type_required A resource is a ~y:jLelll rommo-lity that is associated with component types. A resource may be ~ssignerl to multiple component types. Multiple resources may be ~Signe~l to a component. When a component is inst~nti~teri, the resource ~signe~l to this component type is made available to the configuration. When a component's resource is consumed, only the CA 0221~294 1997-07-12 W096/28784 PCT~US96/03406 resource supplied by its associated component becomes unavailable. The availability of a resource of the same type that is offered by a second component is unaffected by the consumption of the first component's resource. Therefore, if the same resource type is available from a second 5 component, the consumption of the first component's resource does not consume all of this resource type in the modeled :jy:,L~

Before a resource type can be A.~Si~l~l to a component type or used by a component instance, the resource type must be dedared. A resource 10 declaration has the following format:

resource <<ResourceName>>;

An example of a resource declaration is as follows:
~5 resource static_RAM_resource;

Datatype declarations define the types of interfaces and data transfer protocols available to ronnertion~ in a modeled system. SCSI and IDE are 20 examples of datatypes. A datatype is declared as follows:

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 dataType <<DataTypeName>>;

A derived class is ~l~finefl by the following StAt~TnPnt (Note: the portion with the ''c'' symbol is optional):

Class <<ClassName>>: <<BaseClassName I SuperClassName>>
displayStatus: <<HIDDEN I LISTED I DRAWN>>
~ attributes:
<<AttributeName = AttributeValue;>>~
~-lim~n~:ions [Xsize, Ysize];~
c connecfionOrigin <~TRUE I FALSE>>;~

The display status includes the values Hi~ n, Listed, and Drawn.
Drawn allows the class member to be displayed in the graphical rendering of the configuration. Listed allows the class members to be listed on the A~ ionAl components list. Hidden is used for members that are Hidden (i.e., not drawn), but have children that are Drawn. An attribute value may 20 be A~sigT~ at the time of declaration, but this is not necessary. ~~QnneC~iOnorigin i~lenhfi~ whether or not instances of this class are to be used as starting points for cabling report generation. An example of a derived class declaration is as follows:

class Bay: ConPiner {

displayStatus: DRAWN;
attributes:
front_accessible;
height;
half_height_compatible;
position;

CA 0221~294 1997-07-12 W 096/287~4 40 PCTrUS96/03406 In this example a derived class, bay, is created. It is a member of the Cont~iner base class. Thererore, it may ccmt~in other PlemPn~. Its attributes define its height, half_height compatibility, front_accessibility (i.e., is a component installed in this bay accessible from the front of a :jysl~ln cabinet), 5 hPight, and position. These attributes will be inherited by each descpn~l~nt of this derived class.

System components, or component types, are ~ fine~l by the following declaration:

co..-~olLent <<ComponentTypeName>>: <<DerivedClassName>>
~prod~lct~.in~s: <<ProductLineName;>>~
~ label: <<"LabelName";>>~
~ ~5~rirtion <<"DescriptionString";>>~
resou~ce: <<ResourceName ~, IntegerValue ~ ;>>~
dataType: <<DataTypeName;>>~
partNum: <<"PartNumString";>>~
~ subComponents: <<SubcomponentName;>> V
<<SubcomponentName~Integer~;>>c ~transfers: <<SubcomponentName[0~ <-~SubcomponenWame[11;>>~
~,r1imf~ncionc: [<<Xsize, YSize>>l;i values: <<AttributeName = AttributeValue;;>> V
<<AttributeName = {AttributeValue, . . . };>>~
~fillDirection: [ <<TB I BT I LR I RL>> ];<
}

The label field defines the label given to the graphical represPn~tion of this component. The description field ~lefines the description that is 30 displayed or reported. The dataType field is used if the component type is rles~ en~led from a port, and ~lpfinps the type of data that may be transferred from this component type. The subComponents field ~iefines the structural children of a Composite component type. The transfers field ~l~fines the CA 0221~294 1997-07-12 W 096/28784 41 PCTrUS96/03406 paths that data can travel through a Composite component. Transfers are a mechanism for ex~,ressil,g an internal data path within a Composite component. For example, a cable is represented as a component with two ports, and the cable is used to transfer data from one port to another. The 5 values field provides the ability to establish a component's attributes, or properties. The fillDirection describes the order in which multiple components in a single rc-nt~in~r are drawn.

The following is an example of a component definition:

Component Cabinetl: Cabinet partNum: "001-001 ";
Children: Slotl_l;
Slotl_2;
Slotl_3;
...
Slotl_9;
Slotl_10;
CabinetBay {4};
Values:
position = l;
resources_provided = {lO_Slot_Resource, CPU_Slot_Resource, MCU_Slot_Resource, Mem_Slot_Resource, Bay_Resource};
}

This example rl~fines a component type, Cabinetl, within Cabinet and Composite classes. Figure 4 is the structural hierarchy for a model used to configure computer systems. Cabinetl 108 is des~ enc~e~ from Cabinet 110 30 which is a desrPnll~nt of Composite 112. Therefore, Cabinetl 108 is a composite component type. It has subcomponents, or children, Slotl_l through Slotl_10 and CabinentBay{4} ). The integer "4" indicates that there are four CabinetBay component types within Cabinetl.

CA 0221~294 1997-07-12 W 096/28784 PCT~US96/03406 42 The following is an example of a Composite component type that descends from a connector:

Component SCSIChainCable: Cable {

description: "SCSI Chain Cable";
partNum: "003-002";
subComponents:
SCSICablePort_3;
SCSICablePort_4;
values:
length = 2;
transfers:
SCSICablePort_3 <-> SCSICablePort_4;
}

The following is an example of a component type ~finihon that provides a resource:

Component 16mbMemCard: Card description: "16mb Memory Card";
partNum: "004-016";
resource: MPm~ry_Resource, 16;
values:
slot_resource_required = Mem_Slot_Resource;
}

Constraints provide conflict resolution information used to determine whether components may be added to the configured system. Constraints can control such things as space allocation, space occlusion, and additional component requirPm~nt.~. Constraints are expressed as component q~ ifi~rs and component dependencies. Constraints test the attributes and lineage of CA 0221~294 1997-07-12 W O 96/28784 43 PCTrUS96/03406 components and identify the components that are required for the sll~ cessful instantiation of components.

constraint <<ConskaintName>> on <<ClassName>>
{
<<re~lui~esCo~ ol,ent I requi~es~'o..l~;..er~>
(<<ClassName, ResourceName i ClassName I ComponentName>>, <<?Returne~lTn~tance>> ~, ?ReturnedInstance.AttributeName~
~, Consumed~ ~, FYi~tin~ ~, New~);
}
constraint <<ConstraintName>> on <<ClassName>>
<<requires~'onnection ( ~StartingComponentName,~
<<ClassName, ResourceName I ClassName I ComponentName>>, <<DataType>>, <<?Returne-lTn~tance>>, <<%Path>>
,~?Returne~lTnstance.AttributeName~
i, ConnectQr ( <<ClassName>>, <<?ConnectorInstance>>, <<?ConnectorInstance.AttributeName>>)~
~, ~ ong~st~ ~, Cons~lme~ , FYictin~ ~, New~ ~, Convf~rciQnc~ );
}

The Constraint Name and the Class upon which the conskaint may be applied are i-l~ntifiefl in the ffrst line of the declaration. The requiresComponent, requiresCont~iner and requiresConnection expression 25 identifies additional items (i.e., components, cont~in~r, or connection~) that are required to configure the constrained component. The additional items neelle~l may be i~ientifie~1 by a derived class name and resource combin~tion~
a derived class name, or the name of the component type. When a request is satisfied during configuration, the configuration engine returns the instance 30 of the requested component type found. The ?ReturnedInstance variable identifies the variable that is associated to the instance of the requested component type found by the configuration engine. A request may further ask that the configuration engine make a choice based on attribute maximization. That is, make a choice that will maximize a given attribute.

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 Therefore, a ?ReturnedInstance.AttributeName declaration will return the requested item with the greatest amount of At~ributeName. The attribute maximi7Ation option can also be an expression that refers to other returned instances created by previous component requests with the current conshraint 5 and perform operations with them. A component instance is said to be consumed when it is unavailable to satisfy a conshraint requirement. The Consumed keyword can be used to mark an instance returned by a request as unavailable. Once an instance is consumed, the configuration engine will exclude this instance in subsequent searches to satisfy another request. The 10 Existing keyword limits the search to existing instances. The New keyword requests that a new instance be created to satisfy a constraint requirement.

The requiresC'onnecticn constraint requirement has additional argllm~nt~ that ~lesrrihe the requir~m~nt~ for an entire connectic-n path that 15 can ront~in several different components. The requires~~onnPction constraint requirement has one requirement that is ~ ition~l to and different from the requiresComponent and requires~'ont~iner constraints.
Like the other two conshraint requirf~m~nt~, the requiresConnection requires that the request be s~h~fie~l In ~ ition~ the requiresConnechion constraint 20 requirement, requires that the constrained instance be connecte~l to the satisfying instance.

The StartingComponentName field, or variable, refers to the starting component in the connection (i.e., where the connection will begin). If this 25 variable is not set, the starting component is assumed to be the constrained instance. The next line (i.e., "<<ClassName, ResourceName I ClassName I
ComponentName>>") i~1~ntifi~s the connertir~n component.

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 The type of data that the connection will carry is specified by the DataType field. The dataType field specifies the data type requir.oments of a port of the requested instance. Further, the dataType field specifies the data 5 type requir.orn~nts of a port of the conshrained instance. Because the dataType field only requires that the constrained instance's port and the requested instance's port be of data type dataType, a conn~chon constraint can be sAtisfie~l by a multiple stage ronnertion- For example, it is possible to connect a SCSI device to a SCSI card through illL~l v~-~ing components.
Figure 5 illustrates component interconnectiolls with multiple intervening components and data types. ConstrAine~Tnstance 161 has port 160 and port 162. Port 162 is ronnerte~l to Connector 179 at Port 163. Port 164 of C- nnertc)r Block 179 is connecte-l to Port 165 of 15 FirstInterveningComponent 166. Port 167 of FirstInterveningComponent is roIlnerte-l to Port 168 of C'onnectQr 180. MultipleInterveningComponents 183 represents some number of il~ ,elling components that may be placed between FirstInterveningComponent 166 and NthInterveningComponent 173. Connector 180 and C'onnertrr 181 are positione(l on either end of the 20 MultipleIl~l~l v~llingcomponents 183. Port 171 of Connector 181 is connected Port 172 of NthInterveningComponent 173. Port 174 is co~nerte-l to Port 175 of Connertor 182. Port 176 of C~onnertQr 182 is connPcte~l to Port 177 of DiskDriveController 178. Chain 184 represents the chained communication or ~c-nnertinn path between ConstrAine-lTnstance 161 and 25 DiskDriveController 178.

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 The ?Return~rlTnctance and ?Returne~lTnctance.AttributeName fields have the same f~mrtion~lity as in the requiresComponent and requires~~onPinPr constraint expression. The %Path variable is bound to all of the instances used to make the r~ nnertion That is, all of the instances 5 involved in a ronnertion are referred to as the connPrfion path.

With respect to the ?Returne~1Tnctance.AttributeName and the ?Returne~lTnctance instance variables, the maximi7~tiQn option is the same as for the requiresComponent and requiresConPiner constraints. There are 10 two maximi7~tion options for the path instance variable. The first option is the rc-nnector the option. The ClassName field specifies the desired dass of co~nector inct~nreS used to build the path. The ?~~onnPctorInstance field is bound to the returned connector instance, and the AttributeName is the connertc r instance attribute to be ma~cimi7e~1 The request for 15 ?~~onnertorInstance is ma~imi7e~1 in the same way as the returned instances for requiresComponent and requires~~Qnt~in~r.

The second maximi7~hcn option provided by requiresConnPrfion is the path length option. This option provides the ability to prioriti e rhojcf~c 20 Among paths from the requested component to the requesting component.
The length of a path is ~lPfinefl as the number of component instances in the path, in~lllcling instances of class ~'onnertor. The longest path may be specified by using the "Longes'" keyword in the constraint declaration. If the longest path option is not dhosen, the configuration engine selects the 25 shortest path.

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 The Consumed, Existing and New specifirAtion~ of the requiredConnection constraint have the same functionality as in the requiresComponent and requiresCont~in~r constraint declarations. The Conversions option provides the ability to specify that the requested instance 5 can have a datatype that is ~ similAr to the constrained instance. That is, ifthis option is chosen, the requested-side port is no longer required to carry data of type DataType. The only requirement is that the datatype specified by the dataType variable be available at the requester-side port. This option expands the alternatives that the configuration engine is allowed to ron~ r 10 in satisfying the connection request, since it does not have to choose the terminal component with the same datatype as the requester instance.
Thererole, if a connertion constraint allows conversions, satisfaction of a request for a SCSI ronnertifon need only deliver SCSI data to the requesting instance.
The following is an example of a constraint definition:

constraint Storage_device_constraint on StorageDevice requiresC'onnerh.~ n (SCSICard, SCSIDatatype, ?card, %path, ~~onn~ctor (Cable, ?c,-?c.length, Longest));
requiresContAin~r (Bay, Bay_Resource, ?bay.Consumed);

}

The requiresC~ontAinpr constraint indicates that the StorageDevice component type requires a cQntAin~c~r (i.e., a bay). In A-ifliti.~ n, this constraint 30 definition imposes a constraint on the StorageDevice class of the model CA 0221~294 1997-07-12 hierarchy and all of its ~ieCcpn~lAntc It requires the longest cable component type connechon to a SCSICard component type. The type of data that will be carried by this connection is of datatype SCSIDatatype. A port of the constrained instance must also be of this datatype. The datatype constraints 5 may be flllfillPrl with a multiple stage connPction. Thus, the SCSI
StorageDevice may be connecte~ to the SCSICard through intervening components. The variable ?card iclPnhfies the SCSICard instance used. The %path variable contains informA~ion regarding the instances used to make the connechion-The model language provides the ability to perform further tests andqueries to ensure that the configuration engine returns usable instances or instance sets. If a constraint contains a component request, these queries and tests are placed after that request. If the queries and tests are not sAhcfie~l, the 15 configuration engine continues to search for another alternative to satisfy the request. The following are examples of the tests provided in the model language:

mAthPmAti~Al ope~ a~ors;
+ (A~ ihon) - (subtraction) (multiplication) (division) ABS (absolute value) SQRT (square root) rPlAtionAl operators:
> (greater than) < (less than) (equality) >= (greater than or equal to) <= (less than or equal to) != (not equal) boolean op~laLors:

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 OR (logical inclusive or) AND (logical conjunction) NOT (logical negation) A~signment operator:
:= (becomes; takes the value ofl For example, in configuring a computer ~ysl~ln, a test may be performed when configuring a floppy disk drive for the computer :jy~l~m. A
floppy disk drive requires a bay or slot within the system cabinet. Such a 10 constraint would be expressed as a requiresC~ontAin~r component request.
This request would cause the configuration engine to search for a ~An~ te instance to satisfy this request. Once the engine returns the rAnfli~te instance (i.e., .7bay), further testing can be done to determine whether the drive will fit in the returned instanc~. This can be tested by comparing the 15 height attribute values of the rAnAi~lAte instance (i.e., ?bay) and the constrained instance (i.e., ?this) as follows:
?bay h~ight >= ?this.height Intrinsic functions provide A~i~ihonal capability to ~ tests and queries. Intrinsic filncti~n~ can be grouped into query functions and predicate functions. The following are examples of query functions:
ceil Queries an attribute of type float, or any expression that evaluates to a floAf1ng point value, for the smallest integer value greater than or equal to the floA~ing point value.
- Returns an integer.
5yntax: ceil (<<Expr~ssiQn~>) ClassName Queries a set variable for all instances in the set that belong to the specified class.
Syntax: ClassName (<<%InstanceSet>>) CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 ComponentName Queries a set variable for all instances in the set that belong to the specified component type (i.e., leaf class).
Syntax: ComponentName (<<%ReturnerlTnstance>>) Component Queries a set variable for all instances that are not ~lPsrpn~e~l from class Conne~tor.
Syntax: Component (<<%InstanceSet>>) component Queries an instance for the component type (i.e., class hierarchy leaf class) from which it is descPn~le~ Returns the parent component type.
Syntax: component (<< %ReturnedInstance>>) COUNT Queries a set variable for all instances in the set that belong to the specified class.
Syntax: COUNT (<<ClassName I
ComponentTypeName>> <<(%InstanceSet)>>) The following is an example of a constraint ~iPfinihon using query and pre~lir~te funrtion~lity:

constraint Storage_device_constraint on Storage Device {
requires~~onnPrtion (SCSICard, SCSIDatatype, ?card, %path, C'onnPctor (Cable, ?c, -?c.length, Longest);
requires(~o~f~inPr (Bay, Bay_Resource, ?bay, Consumed);
ancestor (.7bay, Cabinet) == ancestor (?card, Cabinet);
FORALL (?instl, Storage_Device (CONNECTS(FIRST(%path))));
ancesior (?instl, Cabinet) == ancestor (?this, Cabinet));

In this example, Storage_Device requires a ronnPrtion to a component of type SCSICard. The connecti~ n must be of datatype SCSIDatatype. The component instance of type SCSICard is bound to the instance variable ?card, and the components in the connPrtir n path are bound (as a set) to the set CA 0221~294 1997-07-12 W O 96/28784 51 PCTrUS96/03406 variable %path. The connector component used to complete the connection must be of type Cable, and is bound to the instance variable ?c. C-An~ Atp cables are ordered from shortest to longest, and if alternative paths from the SCSICard instance exist, the longest path (in terms of number of components) is ~le~ d.

This example further incli~ AtPs that Storage_Device must be placed in a container component of type Bay. This instance of type Bay must supply Bay_Resource. The instance of Bay is bound to instance variable ?bay, and 10 the instance is marked as comsumed (i.e., unavailable in subsequent requests for compoents of type Bay).

In the example, the phrase "ancestor (?bay, Cabinet) == ancestor (?card, Cabinet" requires that the structural ancestor (of type Cabinet) of the instanceiclPnfffie~l by ?bay must be the same instance as the structural ancestor (of type Cabinet) of the instance inrlPnfffie~ by ?card. In other words, the card and the bay must be in the same cabinet.

The "Forall" phrase used in the previous example in~icAtes that all 20 component instances of type Storage_Device connecte~l to the first cable in %path must be in the same cabinet as the constrained instance of Storage_Device.

- Constraint relationships may be established either at the component 25 level or at the class level. At the component level, constraint rPlAhon.chipsspecify which component types are constrained by what constraints. The component rlesignAte~l in the constraint relationship may be any of the CA 0221~294 1997-07-12 W 096/28784 52 PCTrUS96/03406 component types that have been ~1Pfinell by a Component Type declaration.
The constraint may be a constraint dedared by a Constraint declaration. The following is the syntax for specifying a component level constraint:

<<ComponentTypeName>> con~tr~ine~lRy <<ConstraintNamel>>
~<<OR I AND>> <<ConstraintName2>>c i, <<OR I AND>> <<ConstraintNameN>><, Constraints may also be expressed at the class level. A class-level 10 constraint is evaluated as a conjunct in component-level constraint expressions for all component types derived from the constrained cdass.
When a component-level constraint expression is evaluated, class-level constraints are appended to the be~innin~ of the constraint expression and end with that constraint's request and pre-lir~te function expressions. If a 15 component inherits dass level col,sLrdints from several levels in the Class Hierarchy, the constraints are ordered from the most primitive class a.e., the root class Component) to the most system-specific class(i.e., the user-rirfine~1component type). The syntax for a dass-level constraint relationship dedaration is as follows:
~0 conskain class <<ClassName>> with <<ConstraintName>>

The present invention provides the ability to represent within a structural hierarchy how components of a particular system exist spatially 25 and physically using three type of substructures: composite hierarchies, cont~iner hierarchies, and connection relationships. Composite hierarchies identify components as part of o~er components. (~ont~iner hierard~ies identify components as being co~ il.ell in other components. Connecfion ~ =
CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 relationships identify components that connect to other components. The relationships between generations within the structural hierarchy are expressed by the keywords "childOf," "contAine~lRy," and "connectsWith."
Structural r~l~tionships are declared as follows:

<<ClassName>> childOf <<ClassName>>
<<ClassName>> con~inedBy ~<ClassName>>
<<ClassName>> connectsWith <<ClassName>>

A model can be ~l~finefl by providing stAfr-mPntS that synt~rtirAlly conform to the model language described above. In addition, an interactive facility, the Model MAint~nAnce Sub~y~ , provides the ability to ~1efine~ and 15 maintain a model, using a graphical user interface. The Model l~Aint~onAnce Sub~y~le,l. provides the ability to interactively define the Product Base using a graphical user interface. The s~m~ntic repres~nt~tions, class hierarchies, and structural hierarchies of the model may be viewed (i.e., browsed) and modified (i.e., edited) interactively using a graphical user interface. Further,20 constraint input is verified. Testing and debllgging capabilities are provided to identify problems in the model, and to test and optimize the performance of the modified model. For example, model ~iefinihon syntax is parsed and verified, and sample requests may be executed. Diagnostics filnrtion~ may be invoked to monitor the performance of the configuration requests with the 25 modified model.

The browsing capability of the m~intpn~nce :jy~lll provides the ability to view graphic representations of the class and substructural components of CA 0221~294 1997-07-12 W O 96/28784 54 PCTrUS96/03406 the model hierarchy. A Class Tree is used to represent objects ~escen-ling from base dasses within the model hierarchy (i.e., an object class hierardhy).
The object class hierarchy is represented by five separate trees, one for each base class. Each branch may have multiple desc~n~i~nt~. ~

A Component Tree is used to depict the Composite, Connector and Container Component substructural interrelationships. Composite Trees are listed first followed by Cor~nectQr and Cont~iner Trees.

A hierarchy member may be s~lecteri for mo-lification by double-~ lirking on the box that contains the hierarchy member. An editor window for the s~lecte-l hielar.1~y member is displayed. A List menu may also be used to select the member to be edited. In the ~le~lled embo~lim~nt, the List menus are a series of pulldown menus that may be s~lecte-i from a menu bar 15 of the M~inten~nce window. The initial menu bar contains a selection for each general ~lPm~nt of the ProductBase model (i.e., dasses, component types, constraints, etc.). Once a general el~m~nt is chosen, a new window is displayed that lists the model members of the general type selection. A
model member may be chosen along with an operation (i.e., Comm~nt, 20 View, New, or Edit). A c-omm~nt operation provides the ability to add a comm~nt to the Pro~ ctR~e after the selecte-l member. A View operation provides the ability to view the settings for the selected model el~ment The model member may be modified by choosing either a New or Edit operation.

For example, to modify an attribute of a model member in the ~re~elled embo~lime~t~ the attribute type is chosen from the List Menu. Once the attributes are displayed, a New or Edit operation may be chosen to add a CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 new attribute, or modify an existing attribute, respectively. An attribute s~lectioll must also be made, if the Edit operation is chosen. After these ~lectic)rls have been made, the Attribute Editor window is displayed. The fields of the window (e.g., name, attribute type, and multivalued) are 5 inihAli7e~3 to either blank or the default sethngS for a New operation, or initi~li7e~ to the current attribute sefflngs for an Edit operation. The attribute name field may be selecte-l and modified. The type field may be modified by s~lecting from a list of valid attribute types. The multivalued field may be toggled on or off. After mAking modifil Ati- ns, the modifications may be 10 saved or cAnc~llell Resources and Datatypes may be added or modified in a mAnn~r that is similAr to the method for A~l~ling or modifying an attribute. Model f~l~ments that require r~lAhonAl cl~finihons require A~ ih~nA1 ~1esignAtion.s F~Ample5 15 of these are derived dasses, product lines (i.e., parent Product Line), constraints (i.e., constrained class), and component types.

In the ~r~.~ed embo~lim~nt, A~i~ling a derived class requires an A~lclihQnal initial step to define the location of the new derived dass within 20 the model hierardhy. At this point, the New and Edit operations have the same operational characteristics, including the ability to save or cancel. That is, the derived class field values (existing, default, or blank) are displayed in an Editor window. In Afl~lition, attributes may be added to all members of the derived classes and their component types; constraints may be specified at the 25 class level for the derived class; structural hierarchy r~lAhon~hips may be t1~finefl for the derived class; the Syst~m Window display status may be ~1~fine~l; the derived class may be s~l~rte~l as a ronnection origin (i.e., a , CA 022l~294 l997-07-l2 W096/28784 56 PCT~US96/03406 starting point of a cabling report); and the component distance (i.e., the average distance from members of the derived class to other objects that are a part of the same composite, and the distance from the member of the derived class to an external port on the composite) may be ~lpfiner1 for children of composite objects that are involved in connections.

To add a new component to the model, the class from which the new class is ~lescPn~le~i must be chosen. The subcomponent field provides the ability to specify the structural hierarchy (i.e., structural children) of a 10 composite component. The New or Edit operations further provide the ability to specify ronnechvity fields such as transfers (i.e., paths that data can travel through a Composite component), datatype, connechon origin. In addition, the following field information may be spel ifier1 component type name, associated attributes, products lines (i.e., product lines that cont~in this component), leaf-level constraints, resources, description, label, part number, fill direction, and display status.

The ~inten~nce system further provides the capability to test a modified model. The Write integrity option determines whether a ParseFile 20 (i.e., ) can be parsed, and a modified ParseFile written. The ProductBase Integrity option determines whether a ParseFile (i.e., ) can be parsed, and a modified ParseFile written. If not, syntax error messages are displayed. The Debugger (i.e., Configure) option reads component requests from a request file and attempts to configure those components using ~electe~l constraints in the current ParseFile. The Debugger provides a tracer capability to provide constraint tracing. A deep trace generates trace output for a traced constraint CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 and all the constraints it spawns. A shallow trace generates a trace output for traced constraints.

NEEDS ANALYSIS

The process of tr~n~l~ting customer requirements into specific components and configurations is called "Needs Analysis." The model language provides the ability to express a model in terms of customer needs and requir~m~nts.
With a needs analysis approach to molleling, a configuration may also be expressed in terms of capacities (e.g., minimllm required response time) or throughput. The needs analysis configuration may be illustrated by a voice m~ss~ging :jy~ mo-lel A configured voice mf~ss~ging ~yslelll may be 15 required to record some specific number of hours of voice data, and provide aresponse time of less than five seconds for ~cco~sing stored nless~ges~ To further illustrate, a telecomml~nic~tions configuration may be specified in terms of traffic load supported and some maximum acceptable failure rte (e.g., dropped calls), or a computer :jy~l~lll configuration may be required to 20 support certain pror~sing loads, data storage requir~ments, and response times.

The model language provides the capability to express a needs analysis model in the configuration modeling language by: (1) illl~l~relillg customer 25 requirement qll~ntih~ (e.g., voice m~cs~ge storage capacity), and (2) identifying associated ql~ntiti~s of configuration components and resources.
This provides the ability to make modeling requests in terms of needs in CA 022l~294 l997-07-l2 W 096128784 PCTrUS96/03406 58 Ac~ciitiQn to component requests. Components can be ~ nhfiP~l as satisfying requirPm~PntC or needs. That is, components may be i~lPntifie~1 as supplying some quantity of a resource (e.g., megabytes of storage capacity). When a user expresses a system, or some portion of a system, in terms of needs or requirPm Pntc, one or more components that satisfy the needs may be 5Plertefi from the ProductBase.

INPUT FORMS

Input forms provide the capability to accept component requests from the user. Input forms allow the user to specify the types and ql~AnffhPc of components in the system to be configured. Input forms consist of standard windowing formats such as listboxes and pushbuttons. A third type of input form provides the ability to specify a quantity of a given component. The user cPlPrtion~c: on the input forms are called component requests. Input forms provide the ability to associate a ~lpfatllt priority for component requests.
Default prioritiPs may be overridden by a requestPriority. These priorities provide the ability to designate the order in which component requests are 5Ati~fie.l by the configuration Pnginp.

PRODUCT-COMPONENT MAPPING

Product_component mapping ~lPfinec discrete and composite components as parts and products in a sales inventory, and then maps those parts and products (i.e., bundles) onto a set of all component instances in a configured ~y:,Leln. The product-component map contAinc reprPSPntAtionc that define each part and product in terms of its required and optional CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 constituent components. These representations further specify how the products are displayed by the Quoter. A repre~ntAtion is comprised of a the following se~ion.s: a Product Header, an Optional Equipment List, and an Option Restriction List.

The Product Header section provides the product name as it appears in the ProductBase. This allows the Bundler to match components in a configured system to products and identify a set cover. This section also includes the following ~ litionAl information: a Product Description String 10 that describes the product for use by other portions of this invention (e.g., the Quoter); a Product Number String; the Price (i.e., the price of the product);
Product Lines String i~lPntifif~ the product lines of which the product is a member, and is used to narrow the set cove~ g seardh; and a Required Components List that identifies components (i.e., by part number) or products (i.e., by product number) that are required by this product.

The Optional Equipment List is a list of additional product p~rk~ges that can be induded in the base package (i.e., the product described in the Product Header). An Optional Equipment List entry contains: an Option 20 Unique ID to uniquely identify the entry; an Option Description that describes the entry; an ~ihon~l Cost to identify an additional cost associated with the inclusion of this entry; and a Constituent Product Number List i~len~ifi~s those products or components, by number, that colll~lise the entry.

The Option Restriction List is a list of groups of options that are interdepPncl~nt or that must be dhosen according to special criteria. Each entry in the Option Restriction List cc-nt~in~ the following: a Group Unique CA 0221~294 1997-07-12 W 096/28784 PCT~US96/03406 ID to uniquely identify the entry, a Quantity Specifier, and an Option Unique ID List. The Quantity Specifier field specifies the number of members of an option group that may or must be chosen. The Qll~ntifier Specifier field may consist of bounds or the atLeastOne, atMostOne, or exactlyOne keywords.
5 The bounds are two integers (enclosed in parentheses and separated by a comm~) that express the lower and upper bound. The atLeastOne keyword indicates that one member of the option group must be chosen. The atMostOne keyword indicates that only one member of the option group may be l~hc s~n, and that it is not required that any member be chosen. The 10 exactlyOne keyword in~ tPs that at least one member of the option group must be chosen, but no more than one. The Option Unique ID List is a space-separated list of Option Unique ID's.

An example of an entry in a product-component map for a model configuring computer systems is as follows:

product base_system description: "Base System";
productNumber:"001-001";
cost: 10000;
values:
categoryl = "System";
category2 = "XXX";
prodll~T ines Tower;
required: ("001-001" reference) "002-001" "002-002";
options:
COMl "Comm Option 1" 1 "002-005";
COM2 "Comm Option 2" 1 "002-006";
optionGroups:
gl atMostOne Coml Com2;

CA 022l~294 l997-07-l2 W 096/28784 61 PCTrUS96/03406 BUNDLER

The Bundler bundles components into product (i.e., marketing) packages. The Bundler uses the product-component map to establish a set 5 cover for a configured system. A set cover is a set of many-to-one mappings of component instAnces in a configured system to product packages in which each component instance is mapped to one product package.

Set coveril,g is the process of cove~ g a set of objects (e.g., component 10 instances in a configuration) with a set of covers (e.g., products). This process is used to associate components created for the current configuration with some grouping or cover (e.g., products). A common problem associated with the set cove~ g process is that as the number of objects and set cover alternatives increase, the number of set COV~:lillg alternatives explodes 15 exponenhAlly. To limit the set COv~illg alternatives, heuristics may be used to identify the minimum set of covers. The Lowest Cost Cover is an example, of a heuristic. Using this heuristic, covelil~g is mA~imi~Prl and cost is minimi~e~ That is, the products providing the most cover for the least amount of cost are sPlecte-Another heuristic is based on the structural collLexl of the alternatives.That is, in some instances, a product will have structure, and that structure will define a physical unit or grouping of components. This may occur, for instance, when a reduction in manllfActtlring cost is incurred when 25 components are produced as a unit. This savings may be passed on to the purchaser of a ~y~L~lll where the re~ ed-cost unit is actually being purchased. Therefore, it is necessAry to examine the configured components CA 022l~294 l997-07-l2 W096/28784 PCT~US96/03406 to determine their structure cont~t, and then match these attributes with the structure cc nt~t of the products. An example of this is a disk array in a computer configuration model. The disk array is physically configured, or manllf~rtl-red, with a chassis, power supply, controller and five disk drives.
Therefore, it is necessary to examine the structure CO1LLeXI of any disk drive component requests. The process of sPlechng instances as "covered" by the disk array product must include a determinz~tion that the "covered" instances were configured to be inside the chassis, or as a disk array unit.

Figure 10 illushrates the EstablishSetCover process flow. At proc~sing block 450, the products that can cover some or all of the component instances in the current configuration are ic~Pnhifi~l At rleri~ion block 452 (i.e., "any products i~lPnfifiP~l?"), if no products have been i~l~nhfiefl, proressing ends at block 454. If products were i~lPnfifi-o~, the products are prioritized based on the number of instances that can be covered by the product at proc~sing block 456. At ~ieri~io~ block 458 (i.e., "any instances not covered?"), if all of the instances have been mapped to the current prioritized product list, a new product list is created that covers products in the current configuration at block 474, and pror~sing continllP~ at ~ieri~ion block 452 (i.e., "any products 20 identified?").

If not, the next product is sPlecte~l from the list at block 460. At decision block 462 (i.e., "do all required ~l~ment~ exist?"), if all of the ~l~ment~ of the product do not exist in th~~ configured 5y5l~m, pror~sing ccntinll~s at prorPssing block 460. If they do exist, the instances that have not been previously mapped and that can be covered by the current product are ntifi~l at prorf~sing block 464. At rieri~irn block 466 (i.e., "any instances CA 022l~294 l997-07-l2 W 096/28784 63 PCTrUS96/03406 i~lenhfieA?"), if no instances can be covered by the product processing continues at ~3e~ i~ion block 458 (i.e., "any instances not covered?").

If some instances were i~l~ntified, it is determined whether any product option restrictions can not be met at decision block 468 G.e., "any product option restrictions that are not met?"). If there are, processing continues at decision block 458 (i.e., "any instances not covered?"). If not, processing continll~s at ~ieri~ion block 470 (i.e., "all structural contexts satisfied?"). Lf they are not, processin~ continues at block 460 and the next 10 product is obtained. If they are, the mapped component instances are marked as covered by the current product at block 472 and pro~essing conf;n~ at decision block 458 (i.e., "any instances not covered?").

REPRESENTATION OF MODELED SYSTEM

Once a ~y:,L~ has been configured based on the requests made, various l~olLillg tools are employed to provide i"~"mation regarding the configured sy~L~ . In the ~lerel,ed embofiimPnt, these tools include a graphical depiction of the general layout of the sy~l~lll, a list of m~teri~l~, a list of spare parts, and a list of any component requests that could not be satisfied.

The present invention provides the ability to express a model in structural terms. That is, components are ~l~fine~1 in terms of their structuralparents (i.e., cont~iners)~ inl~r~;u~ echoI~ and compositions. Therefore, the present invention has the ability to graphically display the configured ~y~L~
along with its structural characteristics.

CA 0221~294 1997-07-12 W096/28784 PCTrUS96/03406 The graphical depiction of the configured system and its structural characteristics, called the system window, provides a depiction of the general layout of the configured system. In the ~lefe-led embo~limpnt~ the sy~L~
5 window for a model that configures computer :jy~L~ms shows the interior and front of all cabinets used in the :jy:~L~lll, and shows the plAc~mPnt of cards, power supplies, and storage devices. Figure 11 illustrates a system window for a desktop computer system configuration. System Window 540 illustrates the configured Sy~L~ 's components and their relative locations 10 within the system. C'hAcsi~ 550 c~,..l~i..s System Board 552, DriveCage 554 and Power Supply 556. Main Board 552A is a r1etAile/l depiction of System Board 552.

Main Board 552A illustrates the physical plAc~m~nt of other 15 components on the sy~l~lll board and their relative positio~. For example, EVGA Video Board 558 is located below CPU Board 560. Further, the placPm~nt of Network Card 562 and FAST SCSI 564 in slots relative to CPU
Board 560 can be determined from System Window 540. Free slots 566 can be viewed as being open and the closest slots to CPU Board 560. Memory 20 Expansion Board 568A is a ~letAilerl depiction of Memory ExpAn~ion Card 568.
lM Simrn chips 570 are located on Memory Expansion Board 568A. Eight mPmory banks 572 remain unused. Drive Cage (Side View) 554A is a detailed depiction of the Drive Cage 554. 535 MB Hard Drive (SCSI) 574, 3.5" 1.44MB
FD 576, and a 525MB Tape p~A~'kl~p (SCSI) 578 are contAinerl within the Drive 25 Cage 554. Front 580 indicates the location of the front side of Drive Cage (Side View) 554A. Thererole, 3.5" 1.44MB FD 576 and 525MB Tape RA~ ktlp 578 have been configured to be front-A~ce~ssihle componPnt~- Bay 582 is a front--CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 Acc~ssible bay that does not contain any device. Bay 584 is a free bay located in the back of the Drive Cage 554.

The Yy:,L~ window further provides the ability to interactively edit 5 the graphically rendered structures. The present invention provides the ability to modify the structural aspects of the configured ~ysl~ll, by A~l~ling,deleting or replacing components within a configured structure. The present invention further provides the ability to modify the configured structure by modifying the shructural inLercululections and compo~sihons.
This capability to graphically display and edit can be used on a newly configured ~y~l~ll" or an existing configuration, or sysl~ln. That is, any upgrades to an existing, configured ~ysL~lll may be performed graphically. A
"freeze and fill" capability allows the user to freeze some portion of the 15 existing ~y~lell" and fill, or modify the unfro~n portion. This "free~ and fill" capability further provides the ability to generate a quote for the new configuration that represents only those components added to the original configuration, and that incorporate any credit for the ~elete~1 or replaced components.
In the ~ler~lled embo(lim~nt, the list of materials, called the Bill of Materials (BOM) provides a list of all of the configured components and spare parts that are used in the system since the last request to configure the ~ysL~
The part number and description is provided for each component and spare 25 part.

_ CA 0221~294 1997-07-12 W 096/28784 PCT~US96103406 In the y~e~lled embo~in~ent, the parts list provides infonnAhic-n regarding A~ ihonal components (i.e., spare parts), resource totals, failed requests, and failed optional requests. Resource totals provides a total of all coll,yollents and resources requested clirectly from the user. Failed Requests 5 and Failed Optional Requests are those component requests that could not be s~h~he~1 because of a lack of space, cc-nnector availability, etc.

OUOTER

The Quoter rAlclllAtes the cost of the individual product packages and determines the cost of all product packages required to complete the system.
The Quoter provides the ability to display the quote in various ways. For example, the quote may be displa~d by product with the capability to expand or collapse the product information to show pricing for individual product 15 parts or for the entire package, respectively. The way in which products are pr~s-onte-l or prices are ~ AlclllAt.orl may be customi7~1 THE FLASH CONFIGURATION CACHE

An embodiment of the present invention includes method and apparatus for expeflihng configuration of a variety of "end products."
Examples of the end products are computers, electronic systems such as voice mail ~ysL~-lls, PBX systems, central office switches, and hAn~h~
comm~lni~Ation devices. The present invention's flash configuration is also 25 used to configure end products such as airplanes where a variety of power ~y:~Lelll options, l~n~ling ~y~LellL options, and interior system options need be configured in an ~ffi~ient and thorough n~.AnnPr. Other end products CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 configured by the flash configuration cache of the invention are trucks, test equipment, and chf~mic~l processes. The flash configuration cache is also used to configure vacation packages where each package involves a number of transportation options, lodging options, and recre~tionAl options.

In order to provide a specific example, the application of the flash configuration cache of the invention in configuring user computers is exrl~ine-1 below. However, it is understood that the flash configuration cache applies as well to configure end products other than computers, 10 examples of which end products were given above. Thus, in one implPmf~ntAtion, the flash configuration cache of the invention is used for expediting configuration of a customer computer (also referred to as the user computer) in response to "new" customer requests. According to this embo-liment, certain "old" customer requests for configuring the user computer are structured in the form of a tree (also called a "search tree") and saved in a "flash configuration cache" by the computer processing the requests (also called the host computer). A "branch" of the search tree is llefinecl as a number of customer requests that origin~t~s from the root node of the tree and ends in a terminal node. For example, referring to Figure 14, customer requests Rl, R2, R3, R4, R5, and R6 constitute a tree branch which origin~t~s from the root node and ends with a terminal node (i.e., the last customer request R6). A "path" of the search tree is defined as a number of customer requests that originates from a root node, but that does not end in a terminal node. In the example, customer requests Rl, R2, and R3 constitute a tree path which origin~t~ from a root node and ends with a non-terminal node (i.e., the non-terminal node of customer request R3). From the above fl~finihon it is apparent that each branch consists of a number of paths. In CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 the example, the branch Rl,R2,R3,R4,R5, and R6 consists of five paths, which are (1) Rl;(2)Rl and R2;(3)Rl,R2, and R3;(4)Rl,R2,R3, and R4; and finally (5)Rl,R2,R3,R4, and R5.

Each branch or path of the tree represents an "old configuration." Each old configuration represents a number of old customer requests. As each set of new customer requests is obtained, the flash configuration cache is searched to match the new requests with an old configuration stored in the flash configuration cache, namely, a path or branch of old customer requests 10 stored in the search tree. The longest path or branch of old requests, representing the maximum extent of mAtt hing requests, is then found and s~lerte-l The old configuration represented by the mAtt~hing path or branch is then re~All-o~l from the cache. In this mAnner, new customer requests can be quickly configured if they at least partially match against previously 15 configured requests. In other words, instead of generating a compllPfionAlly int~n~ive new configuration, a preronfigured ~y~Lelll correspon~ling to an old of set of requests is re~ All~l from the cache. This results in a speed advantage.
A partially mAt~ he~l configuration is then partially configured and hence can be configured from that point on.
In this embo~iiment~ a request is either a component request or a resource request. Each component or resource request is associated with a number of constraints that are specified in the productbase. As each new request is compAred to an old reques$, ~he constraints associated with the new request are i~lenhfie(l in order to match them against the constraints A~sr~iAfe~l with the old request. However, it is understood that if the productbase has not changed, the constraints associated with the old and new CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 requests alltom~tically match. Accordingly, if the productbase has not changed, the matching of the constraints is unnec.o~s~ry. For mA~--hing the old and new component requests, the component name, quantity, priority, and attribute values should match. In m~trhing old and new resource 5 requests, component class names, quantity, priority, and allocation types should match.

According to the flash configuration cache embollimf~nt of the invention, the cache is initially void of requests and the corresponding 10 configurations. However, as customer requests are obt~in~ certain ones of the requests and their correspon(ling c.onfigurations are saved in the cache.
The requests that do get stored are called "old" requests, and their corresponcling configurations are called "old" configurations.

The host computer makes a ~lel~ision as to which ones of the requests should be stored in the cache. The requests that are stored in the cache are those for which generating a new configuration is more time consuming than re~lling the prerc)nfigured requests from the cache. Accordingly, the host computer keeps track of the time that it takes to generate each 20 configuration in response to a given set of requests. The host computer then compares the time consumed in generating a configuration to a predetermined time. If the generation time is greater than the predetermined time, the configuration is stored in the cache. Otherwise, the configuration is not saved. The predetermined time is typically an estimate of the time that it 25 takes to recall a given configuration from the cache. By way of example, suppose that in ,e~o"se to customer requests for a monit )r, a floppy drive, an IDE hard drive, a power supply cabinet, an IDE hard drive controller, a 486 W 096128784 PCT~US96/03406 CPU, and a memory board, the host computer generates a new user computer configuration. In this example, the generation of the configuration takes five minutes of the host computer time. The host computer compares this time (namely, the five minutes) with a predetermined time, for example one 5 second, that it takes to recall a new configuration from the cache. Since the generation of the configuration is more time consuming than recAlling the configuration from the cache, this configuration gets stored in the cache as a configuration representing the specific customer requests that resulted in the configuration. This configuration is stored in the cache and reprr~nte(l by 10 the "old" set of requests that resulted in that configuration. The old set ofrequests is stored as one path or branch of the search tree. When a set of new customer requests is input to the host computer, the host computer methodically searches the tree to find a path or branch of old customer requests that mAtrhr-s the new customer requests. If a mAtching set of old 15 customer requests is found, the host computer recalls from the cache the old configuration associated with the set of old customer requests. This is because the host computer has already determined that the time required to generate a new configuration for the new customer requests is longer than the time required for rerAlling the mAtrhing old configuration from the flash 20 configuration cache.

Thus, the configurations that are saved in the cache are those that require a shorter time to be recAllr-~ from the cache than be regenerated. The sets of stored requests (namely, "old" requests) are org~ni7~fl in a "tree"
25 structure and methodically searched so that a new set of requests can be mAtrhe~1 against an old set of requests. Each set of old requests is stored as apath or branch, and a number of branches constitute the search tree. The CA 022l~294 l997-07-l2 W 096128784 71 PCTrUS96103406 algorithm and related flow diagrams to construct and to search the tree are explained below. For simplicity in the following discl~sicn, the assumption is made that all of the request sets take longer to conffgure than they take forrecall from the cache.

As stated above, the cache does not initially have any requests stored therein. As each set of customer requests for user computer (or other end product) configuration is obtained, the search tree is expAn~lefi Thus, the cache size increases as time goes by. Accordingly, the chances that new 10 customer requests have already been stored in the cache increases as time goes by. Figures 13A-13C illustrate the algorithm used for bllilrling the searchtree and adding requests to the cache. The algorithm for searching the request tree begins in step 101. Since a new request list is to be configured, the algorithm searches for the root of the search tree (step 103). The algorithm 15 then proceeds to search for the first request of those stored sets of requests that diverge directly from the root node of the tree (step 105). Then the host computer determines whether any of these stored first requests mAtrhes the first request in the new request list (step 107). If none of the stored first requests dive~ g from the root node mAt~hes the first request in the new 20 request list, the entire new request list is added to the tree (step 109). The new request list is added such that the entire request list diverges from the root node of the tree. The reason that the new request list is added as div~giLLg from the root node is that the root node is the only common node between the new request list and the stored request lists. The host computer then 25 generates a new configuration and stores it in the cache. The new configuration is represented by the set of requests that was just added to the search tree (step 110). After All~ling the new set of requests to the flash CA 0221~294 1997-07-12 W O 96/28784 PCT~US96/03406 configuration cache, the algorithm for searching the request tree ends (step 113). Thereafter, the request list just added is cc-n~i~lered as a list of "old"requests constituting one of the branches of the search tree stored in the flashconfiguration cache.

If, however, there is a match between the first request and one of the stored first requests directly dive~ g from the root node, the algorithm proceeds to determine whether the next request in the request list m~t--hPs an old request diverging from the first stored request diverging from the root 10 node (step 111). In other words, the algorithm proceeds to match the next request in the new request list against a s~.ored request diverging from the first m~t~ hing stored request. In step 115, the algorithm determines whether a stored request diverging from the first m~t~ hing request m~t~hes the next request in the new request list. If no mach is found, the new request list is 15 added to the search tree (step 117). This is performed b~ ng the new request list in a m~nnPr such that the first ~n~trhing request is shared with another branch of the search tree. As such, the new request list dive-E;es from the first m~t~hing request of that other branch. In step 118, the new configuration represented by the new request list is generated and added to 20 the cache. After ~ ing the list of new requests to the flash configuration cache, the algorithm for searching the request tree ends (step 121).
Thereafter, the request list just added is con~ red as a list of "old" requests constituting one of the branches of the search tree stored in the flash configuration cache.
If, however, there is match between the stored request diverging from the first m~t~hing request and the next request in the new request list, the -CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 algorithm proceeds to det~rmine whether the next request in the new request list matches an old request diverging from the next stored request diverging from the root node (step 119). In other words, the algorithm proceeds to match the next request in the new request list against a stored request 5 diverging from the second m~trhin~ stor~d request. In step 123, the algorithm determines whether a stored request diver~ g from the second m~t~ing request m~t~h~ the next request in the new request list. If no mach is found, the new request list is added to the search tree (step 124). Thisis performed by A~l~ling the new request list in a m~nn~r such that the second 10 m~t~ hing request is shared with another branch of the search tree. As such, the new request list div~lges from th~ second m~t~hing request of that other branch. In step 125, the new configuration represented by the new request list is generated and added to the cache. After ~rl~ling the list of new requests to the flash configuration cache, the algorithm for searching the request tree 15 ends (step 126). Thereafter, the request list just added is cc~ red as a list of "old" requests const t lting one of the branches of the search tree stored in the flash configuration cache. The algorithm continues in this m~nn~r until all of the requests are processed (step 127). When all of the requests in the list of new requests are processed the algorithm ends (step 129). The following 20 example illustrates the operation of the algorithm.

Referring to Figure 14, suppose that the first request list to be processed is that consisting of R1, R2, R3, R4, R5, and R6. Following the algorithm of Figures 13A-13C and since there are no preexisting requests stored in the 25 cache, the host computer finds no m~t~hes between the first request (n~m~ly R1) and the c( n~Pnt~ of the cache. Accordingly, the entire request list consisting of R1, R2, R3, R4, R5, and R6 is added to the cache as shown in CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 Figure 14. The host computer then generates a new configuration repr-o~Pnte~l by this request list and adds the new configuration to the cache.

Suppose that the next request list consists ofRl,R2,R3,R4,R7, and R8.
In this case, the algorithm first finds a match for the first request (Rl) whichis already stored in the cache as a part of the stored request branch consistingof Rl,R2,R3,R4,R5, and R6. The algorithm continues by searching for the next rnAt~hing request that diverges from Rl. In other words, the algorithm searches all of the second requests of the stored branches that had Rl as their 10 first request. The only branch is the Rl,R2,R3,R4,R5, and R6 branch which is stored in the cache. Since there is an R2 diverging from Rl in this branch, the algorithm finds a match between the first and second requests (Rl and R2) of the new request list and the stored branch consisting of Rl,R2,R3,R4, R5, and R6. The algorithm continues in this mAnnPr and finds that the first four requests in the stored branch consisting of Rl,R2,R3,R4,R5, and R6 match the first four requests of the new request list consisting of Rl,R2,R3, R4,R7, and R8. The algorithm then finds that no mAt~ hing request for R7 has been stored in the cache. Accordil,gly, as shown in Figure 14, the rPmAin~lPr of the new request list, namely R7 and R8 are added to the cache as brAn~hing off from the first four requests of the request list already stored inthe cache. Finlly, the algorithm generates a new configuration reprPsPnt~P
by the new request list, i.e. Rl,R2,R3,R4,R7, and R8, and stores the new configuration in the flash configuration cache.

The next request list is Rl,R9,RlO,Rll,R12, and R13. The algorithm finds a match only for the first request in the list of new requests, namely Rl.The rPmAining requests, R9,RlO,Rll,R12, and R13, are added to the cache as CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 a new branch diverging from R1 of the stored request list as shown in Figure 14. Then the algorithm generates a new configuration repre~nte~ by the new request list, i.e. R1, R9, R10, R11, R12, and R13, and stores the new configuration in the cache. The next request list is R14, R15, and R16. For this5 request list no matches are found. Thus, the algorithm saves the entire request list as branching off from the root node as shown in Figure 14.
Thereafter, the algorithm generates a new configuration represented by the new request list, i.e. R14, R15, and R16, and stores the configuration in the flash configuration cache.
The assumption implicit in expl~ining the algorithm and in rli~cll~sing the above example was that all of the request lists ~ cl~sed take longer to configure than they take for recall from the cache. In actual operation, before storing any of the request lists, the host computer makes an initial 15 determination whether the configuration time exceeds a pre~eterTnined time. The requests are stored only when the configuration time exceeds the predetermined time. The predetermined time is typically the time that it takes to recall a configuration from the cache.

Thus far the procedure for bl-il~ling and organi7ing the conhonts of the flash configuration cache was discussed. Now the operation for re~ Alling a stored configuration from the cache is discussed. To this end, the host computer must, partially or completely, match a new request list with an old request list stored in the cache and then recall the configuration represented 25 by the old request list. The m~trhing operation is similar to the operation for storing the requests. As shown in Figures 15A-15C, the algorithm begins by searching for the root of the tree (steps 201 and 203). Then, a search is CA 022l~294 l997-07-l2 W 096/28784 PCTrUS96/03406 performed on all stored paths for their first stored requests diverging from the root of the tree (step 205). The algorithm then determines whether any of the stored paths has a first request that mAtrh~s the first request of the new request list (step 207). If there is no match, the host computer proceeds to 5 generate a new configuration for the user computer (or other end product) (step 209) and the operation ends (step 213). If there is a match, the algorithmchecks the next new request diverging from the first request of the new request list. This is done by performing a search on all stored paths that had asllcc~sful match on their first requests. These paths are searched for their 10 secon~i stored request div~lgillg from their respective first requests (step 211).
The algorithm then determines whether any of the stored paths has a second request that m~tf-h~s the second request of the new request list (step 215). If there is no match, the host computer recalls the configuration for the mAt~ hing requests (step 216). At this point only the first request is mAtrhing Thus, the configuration c~ e:,~onding to the first request is re~All~fl from theflash configuration cache. The host computer proceeds to generate a configuration colle~onding to the r~m~ining (lmmAtt hefl) requests in the new request list (step 217). Thus, the cor~gura~ of the end product now consists of the combin~hc n of an old configuration and a newly generated configuration. After completion of the configuration process, the operation ends (step 221).

If there is a match, i.e. if one of the stored paths has a second request that m~t~hes the second request of the new request list, the algorithm ron~ rs the next new request diverging from the second request of the new request list. This is done by p~l~)lllUllg a search on all stored paths that hadsll~c~ssful m~t.-h~s on their first and second requests. These paths are CA 0221~294 1997-07-12 W 096/28784 PCTfUS96/03406 searched for their third stored request diverging from their respective second requests (step 219). The algorithm then determines whether any of the stored paths has a third request that matches the third request of the new request list(step 223). If there is no matrh, the host computer recalls the configuration 5 for the matching requests (step 224). At this point only the first and secc-nArequests are matrhing. Thus, the configuration corresponding to the first and second requests is rer~lle-1 from the flash configuration cache. The host computer proceeds to generate a configuration colle~ol.ding to the rPmaining (un~AtrheA) requests in the new request list (step '~ ). Thus, the 10 configuration of the end product now consists of the combin~tirJn of an old configuration and a newly generated configuration. After completion of the configuration process, the operation ends (step 226). This process contin until all requests in the new request list are processed in the m~nn~r described above. The algorithm ends when all of requests in the set of new 15 requests have been processed (steps 227and 229).

From the above description, it is apparent that there may in fact be a set of new requests for which there is a "partial match." This can happen in two ways. A first way is when the m~trhing branch is "too short" for the new 20 request list. By way of example and rer~llillg to Figure 14, suppose that theset of new requests consists of requests R14, R15, R16, and R17. The m~trhing set of requests is the branch consisting of R14, R15, and R16 as shown in Figure 14. Thus, following the algorithm described above, the invention recalls the configuration corresponding to the matching branch R14, R15, and 25 R16 which is only a "partial configuration" relative to the set of new requests consisting of R14, R15, R16, and R17. This "partial configuration" is comhineA with a configuration that the host computer generates for the CA 0221~294 1997-07-12 W O 96/28784 PCTrUS96/03406 nm~t~he-l new request, namely R17. The combination of the partial configuration corresponding to R14,R15, and R16 and the new configuration corresponding to R17is a complete configuration correspon~ling to the set of new requests R14, R15,R16, and R17.
In this mAnn.or, the rlecf~sity to genera~ an entirely new configuration for the new request list is obviated and the process of configuring the user computer (or other end product) in response to the new set of requests is expedited.

A second way in which a "partial match" occurs is when there is a m~t~hing path, as opposed to a m~trhin~ branch, which is "too short" for the new request list. Referring to Figure 14 and by way of another example, suppose that the set of new requests consists of Rl,RZ,R3,R18, and Rl9.
Following the above algorithm, the invention finds the m~t~hin~ path consisting of Rl,R2, and R3 bPlonging~.o tl:e bra~.h Rl, R2, R3,R4,R5, and R6 in Figure 14. The host computer then recalls the configuration colle~on~ling to the path Rl,R2, and R3. This configuration is a "partial configuration" for the set of new requests Rl,R2,R3,R18, and Rl9. The host computer then generates a new configuration for the r~m~ining (lmm~tl herl) requests, na~nely R18 and Rl9. The newly generated configuration is then combined with the old "partial configuration." The combination of the newly generated configuration and the old partial configuration makes up a complete configuration for the set of new requests Rl,R2,R3,R18, and Rl9.

CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 THE BUNDLING CACHE

Another embodiment of the invention includes a bundling cache.
The bundling cache is used to speed up the process of converting a 5 configuration generated by the host computer into actual available commercial products. As with the flash configuration cache, the applil Ation of the bundling cache is not limi~tefl to user computers. However, in order to provide a specific example, application of the invention's bundling cache to user computers is discll~sefl below. It is nevertheless understood that the 10 blln~lling cache of the invention is also used to expedite the process of converting the configurations generated by the host computer into actual romm~rcial products for end products other than user computers. Examples of such end products were given above and include voice mail systems, PBX
~y~ s, central office switches, h~nllhPl~l commlmicAtion devices, airplanes, 15 trucks, test equipment, chemical processes, and v~l Ation packages.

Thus, the invention's blm~lling cache is used to expedite the process of converting, for example, user computer configurations into actual commercial products. In generating a configuration of the user computer, 20 the host computer requires a number of computer component~ The computer components then must be converted into available commercial products. For example, suppose that as a part of the configuration of the user computer, the host computer requires a series of components such as certain types of monitors, floppy drives, IDE hard drives, power supply cabinets, and 25 IDE hard drive controllers, 486 CPU's, and memory boards. Often, many components such as the ones mentioned above are available as a group in a single r~-mm~rcial product. In other wcrds, each comm~rcial product is CA 0221~294 1997-07-12 W 096/28784 PCTrUS96/03406 comprised of a number of components. For example, a single commprcial product may ront~in a monitor, a floppy drive, an IDE hard drive, a power supply cabinet, an IDE hard drive controller, a 486CPU, and a memory board.
~- By way of a specific example, a rommPrcial product called 486-100 contains a 5 Tower Powerhouse 486/33, a 4MB system mPmory, a 3.5"1.44MB floppy drive, a 100 MB IDE disk drive, an IDE controller card, and a VGA monitor.

The host computer may, in addition to requiring a number of components for the user computer configuration, require certain options.
10 For example, the host computer may require mPmnry upgrade options of 4MB,8MB, and 12MB. A cc-mmPrcial product that consists of the components required by the host computer may or may not offer the required options. For example, the cc.n~mercial product 486-100 offers three different mPmory upgrade options of 4MB,8MB, and 12MB. Each mPmory upgrade option offers a respective ~ 1ition~l amount of memory of 4MB,8MB, or 12MB beyond the 4MB system memory that is provided by the 486-100 commercial product.

The blln-lling cache is llhli7P-l to speed up the process of fin~ling products that match the required components. In the absence of the blm~lling cache, the host computer searches for products that offer the required components in various large data bases. This is a slow process. According to the blm-lling cache embo~limPrlt of the invPntion, a cache of products and ~eir required part numbers is m~int~ine~l The various products that offer the required components of the configuration generated by the host computer are obtained from various data CA 022l~294 l997-07-l2 W O 96/28784 PCT~US96/03406 bases Acc~ssihle to the host computer. Each of these products offers certain options as shown in Figure 16. For example, product Pl requires options 01, 02, 03 and 05. Product P2 requires options 02, 03, 04, and 05, and product P3 requires only option 05. A first hash table in the host computer correlates 5 each product to the required (i.e. ne~ssAry) options offered by that product.

A second hash table is built which correlates all the available options to their respective products in which they are required (i.e. n~c~ssAry). As shown in Figure 17, option 01 is correlated to product Pl only. Option 02 is 10 correlated to products Pl and P2, option 03 to products Pl and P2, option 04 to product P2, and option 05 to products Pl, P2, and P3. The products that do not offer the required options are not of interest to the host computer for b~ ling the b~nrlling cache. Thus, the b~n-iling cache is lltili7e~1 to store inforrnAtion related to those products that have been kl~nfifie~i as offering 15 the options required by the host compu~er. For example, if the host computer requires options 01 and 02 in generating a configuration for the user computer, using the second hash table the host computer determines that only Pl offers both these options. Thus, every time that a set of requests results in a configuration requiring options 01 and 02, product Pl is rerAlle~
20 from the b~m~lling cache and is ll~ili7erl in implementing the configuration of the user computer. Products such as Pl that are stored in the b--n~ling cache are compiled in a product data base that is used in impl~rnPnting the configurations generated by the host computer.

Claims (22)

1. A method using a host computer for configuring an end product in response to a plurality of new requests, said method comprising the steps of:
arranging a plurality of old requests into a plurality of paths and branches constituting a tree, each path or branch representing a unique old configuration of said end product stored in said host computer;
inputting said plurality of new requests;
searching a cache of said host computer for finding a matching path or branch, said matching path or branch having a plurality of old requests matching said plurality of new requests; and recalling from said cache one of said plurality of old configurations represented by said matching path or branch.

2. The method of claim 1 wherein said end product is a user computer.

3. The method of claim 1 or 2 wherein said plurality of old requests and said plurality of new requests are component requests.

4. The method of claim 1 or 2 wherein said plurality of old requests and said plurality of new requests are need requests.

5. The method of claim 1 or 2 wherein said plurality of old requests and said plurality of new requests are resource requests.

6. The method of claim 2 wherein said plurality of old requests and said plurality of new requests comprise container, connection and component constraints.

7. A method using a host computer for configuring a user computer in response to a plurality of new requests, said method comprising the steps of:
defining in said host computer a plurality of old configurations of said user computer comprising a plurality of old requests;
arranging said plurality of old requests into a plurality of branches constituting a tree, each branch representing one of said plurality of old configurations;
inputting said plurality of new requests;
searching a cache of said host computer for finding a matching branch, said matching branch having a plurality of old requests matching said plurality of new requests; and recalling from said cache one of said plurality of old configurations represented by said matching branch.

8. The method of claim 7 wherein said plurality of old requests and said plurality of new requests are component requests.

9. The method of claim 7 wherein said plurality of old requests and said plurality of new requests are need requests.

10. The method of claim 7 wherein said plurality of old requests and said plurality of new requests are resource requests.

11. The method of claim 7 wherein said plurality of old requests and said plurality of new requests comprise container, connection and component constraints.

12. A method using a host computer for configuring a user computer in response to a plurality of new requests, said method comprising the steps of:
(a) defining in said host computer an old configuration of said user computer comprising a plurality of old requests;
(b) arranging said plurality of old requests into a branch, said branch representing said old configuration;
(c) determining a total time by adding a first time period for execution of the defining step to a second time period for execution of said arranging step;
(d) storing said branch and said old configuration in a cache of said host computer if said total time is greater than a predetermined time;
(e) repeating steps (a)-(d) to store in said cache a plurality of branches and a respective plurality of old configurations;
(f) inputting said plurality of new requests;
(g) searching a tree comprised of said plurality of said branches for finding a matching branch, said matching branch having a plurality of old requests matching said plurality of new requests; and (h) recalling from said cache one of said plurality of said old configurations represented by said matching branch.

13. The method of claim 12 wherein said plurality of old requests and said plurality of new requests are component requests.

14. The method of claim 12 wherein said plurality of old requests and said plurality of new requests are need requests.

15. The method of claim 12 wherein said plurality of old requests and said plurality of new requests are resource requests.

16. The method of claim 12 wherein said plurality of old requests and said plurality of new requests comprise container, connection and component constraints.

17. A method using a host computer for configuring an end product, said method comprising the steps of:
(a) generating a configuration of said end product in response to a request list, said configuration comprising a plurality of components;
(b) searching a product catalog to find a plurality of matching products, each of said plurality of matching products correlating to one of said pluralityof components;
(c) inputting a respective list of required options for each of said components; and (d) storing in a cache each of said plurality of matching products which offers said respective list of required options for a corresponding component.

18. The method of claim 17 wherein said end product is a user computer.

19. The method of claim 17 or 18 further comprising the steps of storing in said cache said respective list of required options for a corresponding one of said plurality of matching products.

20. The method of claim 17 or 18 wherein said list of required options is comprised of one or more options.

21. The method of claim 17 or 18 further comprising the step of storing in said cache each of said plurality of matching products when no options are required for a respective one of said plurality of correlating components.

22. A method using a host computer for configuring a user computer, said method comprising the steps of:
(a) generating a configuration of said user computer in response to a request list, said configuration comprising a plurality of components;
(b) constructing a product catalog comprising the steps of:
(i) inputting a plurality of required options for each of said plurality of components;
(ii) generating a first hash table correlating each of said plurality of matching products to its plurality of required options;
(iii) identifying said plurality of required options among said plurality of required options;
(iv) generating a second hash table correlating each of said plurality of required options to respective ones of said plurality of matching products, thereby identifying a target group of said plurality of matching products;
(iv) storing said target group of said plurality of matching products as said product catalog in a cache of said host computer; and (c) searching said product catalog to find a plurality of matching products, each of said plurality of matching products correlating to one of saidplurality of components.