Method and apparatus for automatic and interactive configuration of custom products5745765Abstract A method for configuring a product from a plurality of selectable components includes establishing for each component a list of available classes, defining specific properties for each class of each component, defining constraints among components based on said specific properties, selecting a first plurality of components for a product configuration, identifying each of said first plurality of components as selectable, eliminated, or contradicted based on said constraints, and altering said product configuration to avoid eliminated and contradicted components. The method permits computer added design of a system which allows interactive participation of the designer in identifying required components for a redesign when an initial design is inoperable. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Card.sub.-- cage class
Model number Slots Provided
______________________________________
Chassis.sub.-- KL4
4
Chassis.sub.-- KL8
8
Chassis.sub.-- IV4
4
______________________________________
Thus the three models of card cage component make up the classes of card cages. Specific brands of card cages that a customer can buy are called "allowed values." Next, each of the three classes has specific properties. One property of a card cage is how many card slots it provides. In the table above two classes of card cages have four slots each while one class provides eight slots. One property of memory and processor cards is the number of card slots they require within the card cage. The following are tables for classes of memory cards and processor cards, respectively:
______________________________________
Model number Slots Required
______________________________________
Memory.sub.-- Card
Western.sub.-- 4MB
1
Intel.sub.-- 8MB
2
Intel.sub.-- 16MB
4
Processor.sub.-- Card
MIPS.sub.-- 040 1
MIPS.sub.-- 050 2
MIPS.sub.13 060 3
______________________________________
When analyzing properties that involve containment problems, where one class contains another, it is useful to think of properties in terms of what they provide, or what they require. Instances are the particular models or brands of the product components that make up a class, as noted in the model numbers in the above tables. Menus can be defined for viewing a class in the computer. These are then used in the system layout. In defining constraints between components based on the specific properties, relationships provide the logic system for the model. Instance to instance relationship is the most basic kind of relationship. One basic example of an instance to instance relationship is to tell the product model to automatically select an allowed value of a product component upon the selection of a master component. For example, one could set up the system that upon selecting Chassis.sub.-- KL4 from the card cage class window, the model automatically selects the MIPS 040 processor card. An instance to instance relationship like this might be useful to establish a tie between a component and a cable that is required by that component, thus ensuring that the cable is not forgotten in the product package. Another type of instance relationship is elimination. One can set up the models so that an RHS allowed value is eliminated as an option upon selection of an LHS allowed value. Although an entire product model could be constructed based on instance relationships, it would be very time consuming and require much computer space. This translates to a product model that is extremely difficult to update. In accordance with the invention constraint relationships provide a much more efficient way of establishing ties between class instances. In building a simple constraint, first consider the nature of the model. Card cages provide a limited number of card slots. The memory card and processor card must be provided within the cage. Thus the number of slots provided by the card cage must be greater than or equal to the total number of slots required by the memory card and the processor card combined. If the equation is written in standard infix notation, it looks like the following: Card.sub.-- Cage:SlotsPrv>=(Memory.sub.-- Card:SlotsReq+Processor.sub.-- Card:SlotsReq) When converting the equation to prefix form, it looks like this: (>=Card.sub.-- Cage:SlotsPrv (+Memory.sub.-- Card:SlotsReq Processor.sub.-- Card:SlotsReq)) Note that each component (card.sub.-- cage, memory.sub.-- card, processor.sub.-- card) in the equation is described by a property (SlotsPrv or SlotsReq). In building constraint relationships, the properties among product components are related. From the foregoing the basic procedures or product modeling are established. Consider now the concept of compatibility. Compatibility ensures that one component is compatible or usable with another component. Like the containment model, the properties established in a compatibility model can be expressed in terms of Prv (provided) and Req (required). Assume that there are two items each available in different colors. Certain colors are compatible with one item while other colors are not. An item A can be purchased in red, blue, or yellow while item B must be purple, blue, or orange. A model is to be designed that, upon selecting one of the items, will eliminate all colors that are not compatible for that item. Thus, if item A is chosen, the colors red, yellow, and blue are selectable while orange and purple are eliminated. Upon selecting item B, purple, orange, and blue are available while red and yellow are not. Thus certain colors are compatible with certain sets or vice versa.
______________________________________
Item Color
______________________________________
Item A blue, red, yellow
Item B blue, purple, orange
______________________________________
Note that there are two classes, item and color. Two pop-up menus can be provided in a final model screen as well. From the item class, the user selects either item A or B and the program informs the user which colors are compatible with that selection. The first step is to establish the classes for the model. Two classes, color and item are present in this example. Thereafter, the property that needs to be established is color provided. As for the colors, each color provides itself; red provides red, purple provides purple, and orange provides orange. Therefore, the property that needs to be established is color provided. In working with compatibility problems, the majority of time one uses string property types. As for the class item, each item is compatible with one of three colors. Therefore, each item requires three colors as options. The specifying of instances for the class, color, is simply a matter of listing the total colors available. The compatibility relationship is a type of constraint relationship. A string index (Str-index) tells the system to take the first part of an equation and search for that part within the second part of the equation. The first part must be smaller in order that it be contained within the second part. The final equation for color is: (Str-index ?Color:ColorPrv ?Item:ColorReq) This equation tells the system to search for color within the list of color options for an item. The equation works forwards and backwards. If a color is chosen first, a compatible set for that color becomes selectable. If an item is selected first, a compatible color will be selectable. In using string index equations, the system starts the search process from the smallest component of the equation and searches for it within the larger component. Notice that the property values that are entered under the property color Prv are all single words (red, yellow, blue, purple and orange). The system searches for these individual pieces of information within the larger list of property values for color Req, which for item A is red, yellow, blue (all three together) and for item B is purple, blue, orange. If the equation were written with the larger component coming before the smaller one, upon selecting item A the system would search for the information "red, blue, yellow" among individual color instances like "red", "orange", or "blue" and would never find a match because the system reads "red, yellow, blue" as one chunk of information and can never find it within individual words. The invention can be summarized in the flow diagram of FIG. 5. The algorithm expressed in the flow diagram can be summarized as follows: Algorithm Define Classes Define Properties Define Allowed Values Define Variables Define Constraints Define Variable/View Associations Layout Views on Windows Compile (produce rule file) Run (Have standard rule engine load rule file+5 state rules) Interact (Have user interact with standard rule engine through the User interface) Define Classes For each class, Enter the class's name the class's parent class Define Properties For each property, Enter the property's name the property's associated class the property's type (symbol, string, integer, float, set or enumeration) the property's default value "5 State"--Selectable, Selected, Eliminated, Contradicted, User Selected The various cases of inputs and outputs in the following algorithm are summarized in the following table:
__________________________________________________________________________
##STR1##
The table below is constructed so that on a per allowedValue, avState,
VariableState basis,
rules have no feed-back (e.g., output == selected => input == eliminated
on the same group). We
do this to keep from inadvertently "storing state."
INPUTS OUTPUTS
case
MLT
INF otherAvInput
usrInpt input
output
avState.srcavState.value
__________________________________________________________________________
0 y * don'tCare
select.about.select.about.E.about.
none input
selectable
1 y * don'tCare
select.about.select+E.about.
select
input
select
2 * * don'tCare
select.about.select.about.E+
eliminate
input
eliminate
3 * * don'tCare
select.about.select+E+
none input
contradiction
4 y * don'tCare
select select*E.about.
select
userInput
select
5 * * don'tCare
select select*E+
select
userInput
selectContradiction
0d n n select.about.
select.about.select.about.E.about.
none input
selectable
0a n y select.about.E+-
select.about.select.about.E.about.
none input
selectable
0b n y select.about.E++
select.about.select.about.E.about.
select
input
select ;sherlock holmes
0c n *? select+E*
select.about.select.about.E.about.
eliminate
input
eliminate
1a n * select.about.E*
select.about.select+E.about.
select
input
select
1b n * select+E*
select.about.select+E.about.
none input
contradiction
4a n * select.about.E*
select select*E.about.
select
userInput
select
4b n * select+E*
select select*E.about.
select
userInput
selectContradiction
select
-1 E.about.
no eliminated input
select*
-0,1 E+-
at least one of other inputs is not
eliminated
select+
at least 1 E++
is where all other inputs are eliminated
select.about.
0 MLT
multiple selectable
E* at least on eliminated input
Src
source
E+ 1 eliminated input av available
__________________________________________________________________________
There has been described a computer method and apparatus for configuring a product from a plurality of selectable items which facilitates the identification of eliminated or contradicted items and the altering of product configuration to avoid eliminated and contradicted components. While the invention has been described with reference to specific embodiments, the description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||