[0001] 1. FIELD OF THE INVENTION
[0002] This invention relates to the field of computer-based system configuration.
[0003] 2. BACKGROUND ART
[0004] Configuring a system refers to the process of selecting and connecting components to satisfy a particular need or request. If a system is based on a limited number of components, the process of configuring the system can be relatively straightforward. For example, the purchase of an automobile requires a salesperson to configure a system (automobile and assorted options) to satisfy a customer's request. After selecting from a plurality of models, the salesperson completes the transaction by selecting options to configure and price an automobile. The configuring of such a simple system can be accomplished with a pencil and paper.
[0005] As system specifications become more customized and varied, configuration alternatives increase and the task of configuring a system becomes more complex. This increased complexity has resulted in a need for computer-based assistance with the configuration process. Early computer- based systems expand independently-generated configuration orders for systems into manufacturing orders. They do not address the actual need for computer-based tools prior to the order expansion. That is, they do not .address the actual generation of a system configuration based on needs and/or request input.
[0006] An example of a complex system is a desktop computer system. The available configuration alternatives of a computer system are numerous and varied, including alternatives available when choosing the microprocessor, motherboard, monitor, video controller, memory chips, power supply, storage devices, storage device controllers, modems, and software.
[0007] Configuring a desktop computer system requires that a selected component is compatible with the other components in the configured system. For example, a power supply must be sufficient to supply power to all of the components of the system. In addition, the monitor 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 must have enough slots to handle all of the boards installed in the system.
[0008] The physical constraints of the cabinent 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 backup units). These bays have additional attributes that further define their use. For example, the bay may be located in the front of the cabinent and provide access from the front of the cabinet. Another bay may be located behind the front-accessible bays, and be limited to devices that do not need to be accessed (e.g., hard disk drive). Bays may be full-height or half-height. Before a storage device can be added to the configuration, a configuration system must identify a bay into which the storage device will be housed. This requires that at least the accessibility and height of the storage device must be examined to determine compatibility with an available cabinet bay.
[0009] The connection between a storage device and its controller must be *.determined based on the location of each. The cable that connects the storage device and its controller must provide compatible physical interfaces (e.g., 24-pin male to a 24-pin female).
[0010] A method of establishing a communication pathway in a computer system is known as daisy chaining. Daisy chaining provides the ability to interconnect 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., 24-pin) of all elements in a daisy chain be known. In addition, it is important to know whether conversions from the source datatype to the destination datatype are allowed. When a daisy chaining candidate is added to the system, the interconnections and conversions between existing components may be checked to determine whether the new component should be an element of the daisy chain.
[0011] The power supply and storage device component examples illustrate the need to define the structural interrelationships between components (i.e., physical and spatial relationships). To further illustrate this notion, consider placing components requiring electrical power such as computer, telecommunication, 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 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 of the components to be placed in both of the cabinets, a component cannot be included in a cabinet if its inclusion would cause the cabinet's power supply to overload. Therefore, the physical placement of the component in a cabinet must be known to make a determination if the subsequent placement of a component is valid. Similarly, arty physical connections between these components must be taken into account. Each component's position in the structural hierarchy is used to determine minimal or optimal lengths for the connecting components.
[0012] Early computer-based configuration systems employed an approach referred to as the rule-based approach. Rule-based configuration systems define rules (i.e., “if A, then B”) to validate a selection of configuration alternatives. Digital Equipment Corporation's system, called R1/XCON (described in McDermott, John, “R1: A Rule-Based Configurer of Computer Systems”,
[0013] A possible solution to the problems associated with rule-based systems is a constraint-based system. A constraint-based system places constraints on the use of a component in a configuration. For example, a hard disk drive 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.
[0014] While existing constraint-based systems address some of the shortcomings of rule-based systems, they do not provide a complete configuration tool. Pure constraint-solving systems do not employ a generative approach to configuration (i.e., they do not generate a system configuration based on needs, component requests, and/or resource requests). Existing constraint-based systems use a functional hierarchy that does not address structural aspects associated with the physical placement of a component in a configuration (e.g., memory chip on motherboard or memory expansion board, storage device in cabinet bay, or controller in motherboard slot).
[0015] Bennett et al. U.S. Pat. No. 4, 591, 983 provides an example of a constraint-based system that employs a recognition or verification approach to system configuration instead of a generative approach. That is, Bennett merely validates an independently-configured system. In essence, an order is generated by an independent source such as a salesperson, and Bennett is used to verify that the system contained in the order does not violate any constraints. Bennett does not generate a system configuration based on needs or component requests (i.e., a generative approach). Thus, Bennett does not provide the capability to interactively configure a system by interactively selecting its components.
[0016] A model consists of all of the elements that may be included in a configured system. In Bennett, the model elements are grouped into an aggregation hierarchy. An aggregation hierarchy creates hierarchical levels that represent a group of elements. Branches from one entry in the current level expand the entry, and the entry is “composed of” the elements in the lower level branches. For example, a desktop computer system is “composed 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 elements that comprise another element. However, the “composed of” relationship does not define the structural relationships between the model elements. The “composed of” relationship does not describe the physical, structural relationships among the elements such as “physically contained inside,” “physically subordinate part of,” and “physically connected to.” Using the desktop computer system previously described, it cannot be determined whether or not a monitor is “physically contained inside” a desktop computer system. A system box is “composed of” storage devices, however it cannot be determined whether one or more of the storage devices are “physically contained inside” the system box.
[0017] A functional hierarchy organizes the components of a model based on the purpose or function performed by the components in the model. Each entry in the hierarchy can be further broken down into more specific functional entries. Thus, an entry's parentage defines its functionality, and progression from one level to the next particularizes the functionality of a hierarchy entry.
[0018] As used in current configuration systems, a functional hierarchy does not define the structural interrelationships or the physical and spatial interconnections among elements. A functional 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 expansion board.
[0019]
[0020] Referring to
[0021] A functional hierarchy does not provide the ability to define actual interconnections between configured instances or the data transfer. That is, that one component is connected to another with compatible logical datatypes (e.g., serial interface) and compatible physical interconnections (e.g., 24 pin). A functional hierarchy only defines the function that a component performs.
[0022] Because it does not define the actual connections between the components selected for a configuration, it cannot establish a daisy chain between configured components . Referring to
[0023] Therefore, a functional hierarchy can not traverse a connection pathway to identify structural interrelationships among configured instances. Thus, a functional hierarchy cannot establish a daisy chain. Therefore, a functional hierarchy can not provide the ability to daisy chain components.
[0024] Another example of a constraint-based system using a functional hierarchy is provided in the following articles: Mittal and Frayman, “Towards a Generic Model of the Configuration Task,” in Proceedings of the Ninth IJCAI (IJCAI-89), pp. 1395-1401; and Frayman and Mittal, “COSSACK: A Constraints-Based Expert System for Configuration Tasks,” in Sriram and Adey,
[0025] The Cossack system employs a functional hierarchy-based configuration system. According to Cossack, a system using a functional hierarchy must identify a configured system's required functions. Once the required functions are identified, Cossack must identify some particular component, or components, that are crucial, or key, to the implementation of these required functions. The Cossack representation does not make structure explicit. Further, Cossack does not provide mechanisms for reasoning about or with structural information. Therefore, Cossack cannot make any structure-based inferences. For example, the internal data transfer paths within components are not represented. Therefore, there is no ability to trace data transfer within a component, and no ability to establish a data connection with another element.
[0026] A configuration system, whether used to configure a computer system or other system, should provide a tool to interactively: define and maintain model; define and maintain (i.e., upgrade) a configured system; generate marketing bundles; generate a graphic representation of the physical and spatial locations of the components of the configured system; use the graphic representation to modify or upgrade a configured system; and generate configuration reports (e.g., failed requests, quotations, and bill of materials). Such a system must define the components of a system, the structural relationships among the components (i.e., spatial and physical locations), the actual physical and spatial interconnections of the components, and the constraints imposed by each component.
[0027] The present invention employs a generative approach for configuring systems such that a system may be configured based on component or resource requests, or input in the form of need. The present invention provides a constraint-based configuration system using a functional hierarchy that comprehends hierarchical and non-hierarchical structure, and associated constraints that can reason about and generate structural relationships. The structural aspects of the model provide the ability to define a model element as being contained in, or by, another model element. In addition, the structural model provides the ability to identify logical datatype and physical interconnections between elements and establish connections between elements.
[0028] To configure a system, 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) environment. Using this information, the present invention configures a system by identifying the resource and component needs, constraints imposed on or by the resources or components identified, and the structural aspects of the system.
[0029] The system configuration can be based on a general definition of a system (i.e., desktop computer system to operate in a CAD environment), or at any level of increased specificity (e.g., disk drive by manufacturer and model number). The system configuration can be based on specific component requests (e.g., laser printer), or by need (e.g., printing capability). Once the system is configured, the configured system can be bundled into products, and a quote can be generated. The bundling process may include the specification of heuristics to control the product-to-component mapping. For example, the product that covers the largest number of components can be selected over otil er possible product selections that cover a lesser amount of components.
[0030] The functional, structural hierarchy of the present invention provides the ability to define the structure of the configuration model and the systems configured from the model. The structural hierarchy includes a container structure. A container provides the ability to specify that one component is contained by, or in another component. Thus, it is possible, for example, to identify that a component request for a disk drive cannot be satisfied because there are no empty cabinet bays in the cabinent specified to contain the component requested.
[0031] The structure, hierarchy notion provides the ability to pool resources. Explicity representation of structure, specifically hierarchical structure, provides the ability to define and access inherited resources. For example, computer, telecommunication, 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 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 might contain more than one electrical power source, however, the resource is presented to structurally 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 cabinet contains multiple power supplies, a disk drive component may draw from resource pool without any knowledge that the resource need is satisfied by multiple power sources.
[0032] In addition, the structural specification provides the ability to specify the connections between components of a configured system. As components are added to a configuration, the physical and logical interconnections that are required to assemble the system components may be verified. For example, before adding a printer with a serial logical connection and a 24 pin physical connection to the configuration, a serial port must be available in the configured system. In addition, a physical connection must be made between the printer and a serial port. If the serial port is a 9-pin female physical connection and the printer has a 24-pin female connection, a cable must be available to physically connect the printer and the serial port. In addition, the actual connection is created in the configuration and can be examined in subsequent connection processing . Connection processing provided the ability to identify any criteria for satisfying a connection request. For example, connection criteria may include the cheapeast, longest, or optimal throughput connection.
[0033] Connection processing may also be used to optimize the use of the configured system's resources. For example, a controller's resources can be optimized by daisy chaining other components together. By connecting one component to another via multiple intervening components, multiple components may be connected to a single component via a single port or connection.
[0034] In the present 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 define 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 base classes may branch into derived classes (i.e., system-specific classes) and terminate at leaf-descendants. Leaf-descendants define the type of components in the functional, structural hierarchy model. Attributes, datatypes, resources, and constraints further define the model.
[0035] A model language provides the format for defining the elements, the constraints placed on the elements, and the structure of the model. The model language may be used directly, or generated based on input from an interactive model maintenance system used to facilitate the creation and maintenance of the model.
[0036] The maintenance system graphically displays the model, and provides the interface for the selection of model elements to be updated. Once the desired updates have been made, the maintenance system provides the ability to test the new model, or verify that the new model can be successfully compiled.
[0037] Once a model has been successfully defined, the present invention provides the ability to configure a system using the functional, structural 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.
[0038] The configuration engine accesses the Product Base to satisfy the requests in a defined priority. A request is processed by adding components to the configuration, or identifying existing components that can satisfy the request. Further, the interconnections, data transfer pathways, and dynamically-determined structural relationships are defined. When a request is successfully processed, the configuration modifications are “committed.” Failed requests are reported.
[0039] A graphical depiction illustrates the configured system and its structural characteristics. The elements of the configured system are illustrated in terms of their physical and spatial location relative to other elements. Elements are contained in other elements, comprised of other elements, or connected to each other. This graphical depiction further provides an interface to modify and maintain elements of the configured system.
[0040] The configured system's elements are bundled into available marketing and manufacturing packages for system quotation and manufacturing purposes. The bundling process performs a product-component mapping based on product definitions.
[0041]
[0042]
[0043]
[0044]
[0045]
[0046]
[0047]
[0048]
[0049]
[0050]
[0051]
[0052]
[0053]
[0054] A method and apparatus for configuring systems is described. In the following description, numerous specific details are set forth in order to provide a more thorough description of the present invention. It will be apparent, however, to one skilled 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.
[0055] The present invention provides a tool for configuring systems that has application to a wide range of domains including the following: computer hardware, computer software, computer networks, telecommunication systems (e.g., PBX and voice mail), copiers, medical imaging systems, vehicles (e.g., fire trucks and construction equipment), electronic control systems, buildings, modular furniture, manufacturing equipment, manufacturing systems, consumer electronic equipment, and electronic systems.
[0056]
[0057]
[0058] A model language is used to create the Product Base. The model language provides the syntax, or statements, used to define the model elements, the constraints placed on the model elements, and the structure of the model. At processing block
[0059] Model Maintenance—The process of defining a model can be facilitated if the Model Maintenace Subsystem is chosen at decision block
[0060] If the “Debugger” is chosen, benchmark system configuration requests are read from a file at block
[0061] If there are additional modifications to the model at decision block
[0062] Configuration and Reporting System—The Configuration and Reporting System
[0063] Configuration Engine—Once all of the request and need input is completed, ConfigurationEngine is invoked to generate a configured system based on the input at
[0064] After a system is configured, the elements of the configuration can be bundled into marketing, or manufacturing, products. Bundler
[0065] The Configuration System of the present invention is a constraint-based scheme using a functional, structural hierarchy.
[0066] The Composite class
[0067] 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 chassis has eight card slots. Container hierarchies identify components as being contained in other components. A Container hierarchy is a dynamic structure in that the structure is dynamically created when a configuration is generated. For example, a CPU card is placed in slot
[0068] The “childOf” keyword indicates that a component is part of a component that is descended from class Composite. The “containedBy” keyword indicates that a component is contained within a component that is descended from the Container base class. The “connectsWith” keyword indicates that a component connects to a component that is descended from the Port Class.
[0069] Container hierarchies typically exhibit an alternating relationship with Composite hierarchies. That is, a container is often a “childOf” a composite component, and the composite component is “containedby” another container. Each substructure type has a root member that is also a descendant of the base class of the same name (i.e., Composite, Container, or Port). Members of a substructure can be of any class defined in the Class Hierarchy. For example, a component of class bay, descended from Container Class might contain a component of class storage-device (descended from Component Class) or of class card_chassis (descended from Container Class).
[0070]
[0071] The structural aspects of the present inventions's model provides the ability to inherit and pool resources. For example, a container component, Cabinet, may consist of a chassis and two one-hundred watt power supplies, A and B. Each of the elements within the chassis container consume, or require some amount of power. If the chassis component contains two central processing 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 twenty watts, neither of the power supplies independent of the other could supply sufficient power to the chassis and its elements.
[0072] However, because the two power supplies are contained in, and are a part of, the Cabinet container, 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 addition, it is possible to satisfy the resource need for any one of the elements 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 processing for the RAM is processed next, the resource needs of the RAM maynot be satisfied by power 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.
[0073] The structural hierarchy provides the ability to structure the model such that one model element, or group of model elements, may be contained by another. The use of the contained model element in a configuration will be constrained by the availability of a container model element in the configuration.
[0074]
[0075] If there are constraints to be processed, the next constraint is identified at block
[0076] If it is determined that it is not a requiresContainer constraint at decision block
[0077] If it is not a requiresContainer constraint at decision block
[0078] The use of a model element in a configuration may also be constrained by the ability to establish a connection to another model element. The requiresConnection constraint requires that a physical connection exist between two components.
[0079] At decision block
[0080] Otherwise, processing continues at decision block
[0081] Candidate ports must be identified to satisfy a requiresConnection constraint.
[0082] If they are compatible, thePort is added to the port list, and processing continues at block
[0083] When the user has selected the components for the system to be modeled, the user requests the invocation of the configuration engine. The configurator accesses the Product Base to identify the object class. After certain validation checks are successfully performed, the configurator instantiates (i.e., creates) a member of that class, called an object instance. The configurator only instantiates those objects required to configure the requested system.
[0084] The configuration engine processes component and resource requests in the priority specified. As each request is processed, the existing configuration is modified by: (1) adding the requested component and other components required to support the component requested, or (2) identifying existing components and new components required to provide the requested resource. When a request is successfully processed, the configuration modifications are “committed,” and this configuration becomes the input configuration in processing the next request.
[0085]
[0086] The request type is determined at decision block
[0087] If it is determined at decision block
[0088] At decision block
[0089] If it is not a requiresContainer constraint at decision block
[0090] The fact that resources are offered by individual component instances, and are not represented as global system entities, assists in the exploration of alternatives.
[0091] If a component is found, processing continues at decision block
[0092] If all of the components offering this resource have been checked, or it is determined (at decision block
[0093] 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, statements may be entered to define the model base, or Product Base. The Product Base contains all of the information about a model. The Product Base contains the information used to configure a system.
[0094] 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 system 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 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-underscores indicate repetitive portions, and portions contained in “<<>>” are required):
[0095] productLine <<ProductLineName>>
[0096] Or, to declare product line hierarchies:
[0097] productLine <<ProductLineName1>>: <<ProductLineName2>>
[0098] System models are stored in files, called parse files. Collectively, the parse files are known as the Product Base. Parse files contain information about a general category within a system model. Data representations 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 property provides attributes of an object. For example, in a computer systems' Product Base, capacity, power requirements, and connection interface are properties of a storage device object. Further, a property categorizes an object. That is, objects with similar properties 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 child class exhibits all of the properties of the parent class in addition to others.
[0099] Attributes define the aspects of a component that must be considered to successfully configure a component. Examples of attributes of a power supply are the cabinet space required for the supply and the remaining power available after power-consuming components are added to the configuration. Attributes can be assigned at the class level, and descendants of that class inherit the class attributes. In addition, attributes can be associated with particular component types. There is no limit to the number of attributes that can be assigned to a component or class.
[0100] Attribute values may be of type floating point, boolean, string, datatype, component, and resource. Attributes may be multivalued. That is, multivalued attributes can have more than one value. For example, with a component that can use either a full height internal bay or a front accessible bay, the attribute “attribute_Bay_type_required” can retain both values. An attribute is declared by the statement (Note: “I” indicates a choice):
[0101] AttributeType <<Attribute Name>> I
[0102] Multivalued AttributeType <<AttributeName>>
[0103] An example of attribute declarations are:
Float Position Float throughput_available Float load_consumed resource space_type_required
[0104] A resource is a system commodity that is associated with component types. A resource may be assigned to multiple component types. Multiple resources may be assigned to a component. When a component is instantiated, the resource assigned to this component type is made available to the configuration. When a component's resource is consumed, only the 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 component, the consumption of the first component's resource does not consume all of this resource type in the modeled system.
[0105] Before a resource type can be assigned to a component type or used by a component instance, the resource type must be declared. A resource declaration has the following format:
[0106] resource <<ResourceName>>
[0107] An example of a resource declaration is as follows:
[0108] resource static_RAM_resource;
[0109] Datatype declarations define the types of interfaces and data transfer protocols available to connections in a modeled system. SCSI and IDE are examples of datatypes. A datatype is declared as follows:
[0110] dataType <<DataTypeName>>
[0111] A derived class is defined by the following statement (Note: the portion with the
Class <<ClassName>>: <<BaseClassName | SuperClassName>> { displayStatus: <<HIDDEN | LISTED | DRAWN>> << }
[0112] The display status includes the values Hidden, 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 additional components list. Hidden is used for members that are Hidden (i.e., not drawn), but have children that are Drawn. An attribute value may be assigned at the time of declaration, but this is not necessary. Connection origin identifies 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: Container { displayStatus: DRAWN; attributes: front_accessible; height; half_height_compatible; position; }
[0113] In this example a derived class, bay, is created. It is a member of the Container base class. Therefore, it may contain other elements. 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 system cabinet), height, and position. These attributes will be inherited by each descendant of this derived class.
[0114] System components, or component types, are defined by the following declaration:
component <<ComponentTypeName>>: <<DerivedClassName>> { << << }
[0115] The label field defines the label given to the graphical representation of this component. The description field defines the description that is displayed or reported. The dataType field is used if the component type is descended from a port, and defines the type of data that may be transferred from this component type. The subComponents field defines the structural children of a Composite component type. The transfers field defines the paths that data can travel through a Composite component. Transfers are a mechanism for expressing 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 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 container are drawn.
[0116] The following is an example of a component definition:
Component Cabinet1 : Cabinet { partNum: “001-001”; Children: Slot1_1; Slot1_2; Slot1_3; . . . Slot1_9; Slot1_10; CabinetBay {4}; Values: position = 1; resources_provided = {10_Slot_Resource, CPU_Slot_Resource, MCU_Slot_Resource, Mem_Slot_Resource, Bay_Resource}; }
[0117] This example defines a component type, Cabinet
[0118] 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; }
[0119] The following is an example of a component type definition that provides a resource:
Component 16mbMemCard : Card { description: “16mb Memory Card”; partNum: “004-016”; resource: Memory_Resource, 16; values: slot_resource_required = Mem_Slot_Resource; }
[0120] 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 requirements. Constraints are expressed as component qualifiers and component dependencies. Constraints test the attributes and lineage of components and identify the components that are required for the successful instantiation of components.
constraint <<ConstraintName>> on <<ClassName>> { <<requiresComponent | requiresContainer>> (<<ClassName, ResourceName | ClassName | ComponentName>>, <<?ReturnedInstance>> } constraint <<ConstraintName>> on <<ClassName>> { <<requiresConnection ( <<ClassName, ResourceName | ClassName | ComponentName>>, <<DataType>>, <<?ReturnedInstance>>, <<%Path>> <<?ConnectorInstance.AttributeName>>) }
[0121] The Constraint Name and the Class upon which the constraint may be applied are identified in the first line of the declaration. Tile requiresComponent, requiresContainer and requiresConnection expression identifies additional items (i.e., components, container, or connections) that are required to configure the constrained component. The additional items needed may be identified by a derived class name and resource combination, a derived class name, or the name of the component type. When a request is satisfied during configuration, the configuration engine returns the instance of the requested component type found. The ?Returnedlnstance 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. Therefore, a ?ReturnedInstance.AttributeName declaration will return the requested item with the greatest amount of AttributeName. The attribute maximization option can also be an expression that refers to other returned instances created by previous component requests with the current constraint and perform operations with them. A component instance is said to be consumed when it is unavailable to satisfy a constraint 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 Existing keyword limits the search to existing instances. The New keyword requests that a new instance be created to satisfy a constraint requirement.
[0122] The requiresConnection constraint requirement has additional arguments that describe the requirements for an entire connection path that can contain several different components. The requiresConnection constraint requirement has one requirement that is additional to and different from the requiresComponent and requiresContainer constraints. Like the other two constraint requirements, the requiresConnection requires that the request be satisfied. In addition, the requiresConnection constraint requirement, requires that the constrained instance be connected to the satisfying instance.
[0123] The StartingComponentName field, or variable, refers to the starting component in the connection (i.e., where the connection will begin). If this 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>>”) identifies the connection component.
[0124] The type of data that the connection will carry is specified by the DataType field. The dataType field specifies the data type requirements of a port of the requested instance. Further, the dataType field specifies the data type requirements of a port of the constrained 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 connection constraint can be satisfied by a multiple stage connection. For example, it is possible to connect a SCSI device to a SCSI card through intervening components.
[0125]
[0126] The ?ReturnedInstance and ?ReturnedInstance.AttributeName fields have the same functionality as in the requiresComponent and requiresContainer constraint expression. The %Path variable is bound to all of the instances used to make the connection. That is, all of the instances involved in a connection are referred to as the connection path.
[0127] With respect to the ?ReturnedInstance.AttributeName and the ?ReturnedInstance instance variables, the maximization option is the same as for the requiresComponent and requiresContainer constraints. There are two maximization options for the path instance variable. The first option is the connector the option. The ClassName field specifies the desired class of connector instances used to build the path. The ?ConnectorInstance field is bound to the returned connector instance, and the AttributeName is the connector instance attribute to be maximized. The request for ?ConnectorInstance is maximized in the same way as the returned instances for requiresComponent and requirescontainer.
[0128] The second maximization option provided by requiresConnection is the path length option. This option provides the ability to prioritize choices among paths from the requested component to the requesting component. The length of a path is defined as the number of component instances in the path, including instances of class Connector. The longest path may be specified by using the “Longest” keyword in the constraint declaration. If the longest path option is not chosen, the configuration engine selects the shortest path.
[0129] The Consuned, Existing and New specifications of the requiredConnection constraint have the same functionality as in the requiresComponent and requiresContainer constraint declarations. The Conversions option provides the ability to specify that the requested instance can have a datatype that is dissimilar to the constrained instance. That is, if this 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 consider in satisfying the connection request, since it does not have to choose the terminal component with the same datatype as the requester instance. Therefore, if a connection constraint allows conversions, satisfaction of a request for a SCSI connection need only deliver SCSI data to the requesting instance.
[0130] The following is an example of a constraint definition:
constraint Storage_device_constraint on StorageDevice { requiresConnection (SCSICard, SCSIDatatype, ?card, %path, Connector (Cable, ?c, −?c.length, Longest)); requiresContainer (Bay, Bay_Resource, ?bay.Consumed); * * * }
[0131] The requiresContainer constraint indicates that the StorageDevice component type requires a container (i.e., a bay). In addition, this constraint definition imposes a constraint on the StorageDevice class of the model hierarchy and all of its descendants. It requires the longest cable component type connection 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 may be fulfilled with a multiple stage connection. Thus, the SCSI StorageDevice may be connected to the SCSICard through intervening components. The variable ?card identifies the SCSICard instance used. The %path variable contains information regarding the instances used to make the connection.
[0132] The model language provides the ability to perform further tests and queries 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 satisfied, the configuration engine continues to search for another alternative to satisfy the request. The following are examples of the tests provided in the model language:
mathematical operators: + (addition) − (subtraction) * (multiplication) / (division) ABS (absolute value) SQRT (square root) relational operators: > (greater than) < (less than) == (equality) >= (greater than or equal to) <= (less than or equal to) != (not equal) boolean operators: OR (logical inclusive or) AND (logical conjunction) NOT (logical negation) assignment operator: := (becomes; takes the value of)
[0133] For example, in configuring a computer system, a test may be performed wlLen configuring a floppy disk drive for the computer system. A floppy disk