FIELD OF THE INVENTION
Embodiments of the present invention relate generally to computer-based product configuration systems.
BACKGROUND INFORMATION
Computer software tools have become indispensable to managing the complexity entailed in designing and manufacturing many modern products. Automobiles are one example of such products.
One aspect of the complexity involved in the design and manufacture of an automobile is the great number and variability of its constituent parts. Typically an automobile model is assembled from a catalogue of parts according to a particular set of design specifications. Because of the number and variability of parts, it can be difficult for designers to ensure that the combinations of the parts are correct.
An approach that uses a computer-based system and associated software to help manage this aspect of complexity is described in U.S. Pat. No. 6,223,094 ('094). As described in the '094 patent, a complex product such as an automobile may be represented in terms of a hierarchical data structure. A top or highest node of the data structure represents the end product (e.g., a compact car), while lower or subordinate nodes represent the components of the end product and associated production processes. A data structure of this kind, used in conjunction with, for example, a graphical user interface (GUI) with various different views tailored to specific user needs, helps to simplify design and production.
More specifically, the GUI may enable users, e.g., designers, to specify particular values to design a desired end product. The values may act to select particular variants of components of the end product. That is, a component may be represented in terms of its function within a product or as an abstraction of materials that may be used for the component, and there may be a number of possible variants associated with the component. The variants may be actual concrete realizations of the function or abstraction of the component: for example, one concrete realization of a component abstracted as a “seat” could be a leather seat, while another might be a vinyl seat. Based on the desired end product, only one of these realizations might be suitable for inclusion in the end product.
FIG. 1 shows an example in the prior art of a hierarchical data structure 10 corresponding to a “configurable product.” “Configurable” here means, among other things, that by providing specific values for characteristics of an end product via, for example, a GUI as described earlier, a desired end product may be defined. The end product could be tailored to, for example, particular customers or markets. The configuring process may generate a list of components referred to as an “order bill of materials” (order BOM) that describes everything needed to produce a given end product according to some specific customer or production order. The overall structure of nodes and variants from which an order BOM may be configured may be referred to as a “super” BOM.
Referring to FIG. 1, high-level nodes 100 include a top-level node that may represent a product class, such as a compact car, and high-level variants such as a model “A” and a model “B” of the compact car. The node structure 10 may further comprise intermediate nodes 101, not illustrated in detail, below the high-level nodes 100. A structure of additional intermediate nodes 102, below nodes 101, is shown with some particularity as an illustrative example. The node structure 10 may further comprise still more nodes 103, not shown in detail, at a lower level.
As the node structure 10 is traversed from high-level nodes to low-level nodes, the nodes may be viewed as representing components of the end product at progressively finer levels of granularity. For example, node 104 could represent, generically, “an engine” while nodes 105-107 represent specific components of the engine and associated variants thereof. For example, node 105 could represent a specific engine component, and associated variants 105.1 could represent three different possible concrete realizations of that specific engine component. Along similar lines, nodes 106 and 107 could represent components of component 105, and associated variants 106.1 and 107.1, respectively. There could be variants of variants 107.2 in the node structure 10.
As noted above, there are known GUIs that work with data corresponding to a hierarchical node structure as shown in FIG. 1. However, one disadvantage of such a GUI is that it requires manipulation of data at the node and variant level. It may be appreciated from the discussion of FIG. 1 that a hierarchical node structure comprising such nodes and variants can become quite complex. Thus, manipulating data at a node and variant level can require detailed knowledge of the hierarchical node structure, and require a laborious and error-prone manual process that involves entering data on multiple screen displays.
SUMMARY OF THE INVENTION
Embodiments of the present invention relate to a GUI for product configuration that reduces the amount of user manipulation required as compared with the prior art. According to the embodiments, high-level user inputs are processed by background functionality to automatically generate data corresponding to node structures, without the user having to manipulate data at the node and variant level. Instead, the user is presented with a single screen display comprising fields for entering simple, high-level input values.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows an example of a prior art hierarchical node structure used in product and process maintenance;
FIG. 2 shows a screen display of a GUI according to embodiments of the present invention;
FIG. 2A shows a display device and input devices that may be used to manipulate the GUI;
FIGS. 3-6 show various operations associated with the screen display;
FIG. 7 shows an example of a production version data file according to embodiments of the present invention;
FIG. 8 shows a process flow according to embodiments of the present invention; and
FIG. 9 shows a computer system for implementing embodiments of the invention.
DETAILED DESCRIPTION
Embodiments of the present invention relate to an easy-to-use GUI for creating a “production version.” A production version is a data file containing information relating to how a given product is to be made. The production version could be used in a manufacturing facility, for example, to inform and guide the various processes involved in manufacturing the product. More specifically, the production version could comprise component information and routing information. The component information includes such things as a list of the components of a product, quantities of the components, and the like. The routing information relates the components to processes for making the product.
An example now follows of creating a production version using a GUI according to embodiments of the present invention. FIG. 2 shows an example of a screen display 200 of a GUI according to embodiments of the present invention. Referring to FIG. 2A, the display 200 could be generated by computer-executable instructions according to embodiments of the present invention on a display device 201 coupled to a computer 202 and input devices such as a keyboard 203 and a mouse 204. The display 200 could present a plurality of fields for entry and display of information relating to product configuration. The GUI could perform background processing, as described in more detail further on, on information entered into the fields as part of operations according to embodiments of the present invention.
Referring again to FIG. 2, the fields for entry of information in the display 200 may comprise a production version field 200.1, a component field 200.2, and a routing field 200.3. The fields represent all the data needed to describe a complete product, and in contrast to prior art GUIs, can be filled in with user input all in a single display 200. The production version field 200.1 may be used to specify a production version, which as noted above is a data file or “container” that contains component and routing information relating to a particular product. The component field 200.2 may be used to specify components of the product, quantities of the components, and the like. The routing field 200.3 may be used to specify processes for making or assembling the product and related information. The appearance (visibility of buttons, columns, field names, order and choice of fields, size of fields, etc.) of the display 200 may be controlled by profile definitions and user settings. The profile and user settings can also be used to define the functionality of a field or define default values for fields.
Production versions may be created from scratch, or pre-existing production versions may be retrieved from a master database and used as a starting basis for a modified production version. FIG. 3 shows an example of the latter. Based on search criteria entered by a user, the. GUI according to embodiments of the invention may present a list of pre-existing production versions in the production version field 200.1 for the user to select from. More specifically, the search criteria may include an identifier of an output product. Based on the identifier of the output product, a search for pre-existing production versions on the master database that relate to the output product may be executed. A result of the search may be presented as a list. In FIG. 3, the identifier of the output product is JH_AUTO (ref. no. 200.11), and the resulting list shows that two pre-existing production versions, JH_SCM41_LOCATION/VERSION 1 (ref. no. 200.12) and JH_SCM41_LOCATION/VERSION 2 (ref. no. 200.13) relate to the output product JH_AUTO. Reference number 300 indicates the selection in the production version field 200.1 of JH_SCM41_LOCATION/VERSION 1 for further processing.
As noted earlier, an advantage of the present invention is that it allows a user to enter high-level inputs and frees the user from the low-level manipulation of node and variant data. The output product identifier 200.11 is an example of such a high-level input. The output product identifier 200.11 is analogous to a node as discussed in connection with FIG. 1. In the particular case of the output product identifier 200.11, the node is a “header” node with an associated set of subordinate variants.
As further shown in FIG. 3, based on the production version selected from a list or otherwise entered in the production version field 200.1, a pre-existing component list 301 corresponding to the output product identifier may be retrieved and displayed in the component field 200.2. The component list 301 may comprise, for example, a variant sub-field 200.21 and a product sub-field 200.22. The product sub-field 200.22 and the variant sub-field 200.21 may respectively identify components, and specific variants of the components, of the product identified by the high-level output product identifier 200.11. For example, the component list 301 shows that the output product JH_AUTO of production version JH_SCM41_LOCATION/VERSION 1 includes a variant 10 of a component JH_SCM41_WHEEL (representing a steering wheel), a variant 20 of a component JH_SCM41_ENGINE (representing an engine), and so on. A different production version, e.g., JH_SCM41_LOCATION/VERSION 2 (ref. no. 200.13) not selected in this example, might contain a different component list for the output product JH_AUTO.
On the other hand, a new production version with its routing and component list could be created entirely from scratch, as noted earlier. In such a case, a new, unique output product identifier could be entered by a user into the corresponding field of the production version 200.1 (FIG.2). Components of the newly-identified output product could be entered into the component field 200.2 of the display 200 as a new component list. Routing data for the new component list could be newly entered in the routing field 200.3. The new product identifier and associated component list and routing data could be subsequently saved to the database, and retrieved later by another process of modifying or displaying a production version.
The discussion now returns to the example, introduced above in connection with FIG. 3, of retrieving a pre-existing component list. Before a user is allowed to enter additions/deletions/modifications relating to a component list in display 200, a number of checks, such as authorization checks, may be performed in the background of the GUI. Once the checks have been performed and passed, the fields of the display 200 may be set editable. Referring now to FIG. 4, it may be possible, for example, to enter component quantities in a quantity sub-field 200.23, units of the quantities in a unit sub-field 200.24, and the like.
After the component list and associated information have been entered, the corresponding routing may be defined in the routing field 200.3. This is illustrated in FIG. 5. In FIG. 5, the routing field 200.3 is editable for entering operations 200.31 (with associated names 200.311), activities and modes (activities and modes not shown in FIG. 5) which are used for structuring the routing. More specifically, an operation may comprise a plurality of activities which may be performed in various modes. As shown in FIG. 6, the operations 200.31 and associated activities 200.32 (with corresponding activity names 200.321) defined as shown in FIG. 5 may be mapped to or associated with components of the corresponding line number in the component field 200.2. Advantageously, according to embodiments of the present invention, the sequence of operations/activities is automatically derived from the line order in the routing field 200.3. In a completed production version, a sequence of operations/activities and the association of components with activities may guide an actual manufacturing process. For example, the component-to-activity mapping shown in FIG. 6 might represent the sequence: “Install steering wheel in steering column (Operation 1, Activity 1); Install engine in car chassis (Operation 2, Activity 2); Install seat in car chassis (Operation 3, Activity 3); Paint car body (Operation 4, Activity 4)”. The routing field 200.3 may further be used to assign resources 200.33 to the manufacturing process, such as specific workers.
FIG. 6 further illustrates that the single screen display 200 can be formatted in such a way that routing information is enterable in the component field 200.2. Although not shown, component information could similarly be enterable in the routing field 200.3. This feature provides further flexibility and ease of use.
After entering values in the display 200 as described in the preceding, a user may save the values. More processing of the values may be performed, and a modified data file corresponding to a changed JH_AUTO/JH_SCM41_LOCATION/VERSION 1 may be saved. The data file may be saved on a machine-readable medium such as disk. FIG. 7 shows a display of a data organization (i.e., a hierarchy of a single header node and associated variants) corresponding to the production version modified as described in the. foregoing. That is, associated with a production version data file 700 identified as JH_AUTO/JH_SCM41_LOCATION/VERSION 1, there is a component list and related information, and associated routing information. These are grouped hierarchically under a header 701 identified as H000000001_JH_AUTO, which corresponds to a header node as described earlier. Under the header 701 are the identifiers 701.1, 701.2, 701.3, 701.4 of the information relating respectively to the component variants entered in the sub-field 200.21 as further described earlier. Along with the variant information is the associated routing information with respective identifiers 701.11, 701.21, 701.31.
In view of the foregoing example, FIG. 8 shows a process flow according to embodiments of the present invention. As shown in block 800, the process may comprise invoking a GUI comprising a screen display having a production version field, a component field, and a routing field. When the GUI is invoked, profile definitions may be read to determine an appearance and functionalities of fields of the display.
Values entered into the production version field may be processed to determine whether there are pre-existing production versions stored on a database that relate to the same output product. More specifically, as shown in block 801, it may be determined based on an output product identifier whether there are any pre-existing production versions on the database that relate to the same output product. If there are, the production version(s) may be presented in the form of a list for the selection of an existing component list corresponding to the output product. Alternatively, an entirely new production version may be constructed based on values entered in the fields.
As shown in block 802, the component field may be set editable to receive inputs defining the component list. In view of the above, the inputs could be modifications or additions to pre-existing information, or could be newly entered.
The routing field may be set editable to receive routing information associating activities and operations with components in the component list, as shown in block 803. The routing information could be modifications or additions to pre-existing information, or could be newly entered.
As shown in block 804, a production version data file comprising the component list and associated routing information as defined by the inputs entered in the GUI may be saved to a database.
FIG. 9 shows a high-level representation of a computer system for implementing embodiments of the present invention, such as might be realized by a variety of known and commercially available hardware and software elements. The system comprises a memory 900 including ROM and RAM, processor 910 and user interface 911 comprising a video display 912, keyboard 913 and mouse 914. Elements may communicate via system bus 909. The system may further comprise a network 917 connected by a network medium 918 and network interface 915.
A computer program or collection of programs comprising computer-executable instructions for performing a method according to embodiments of the present invention may be stored and transported on machine-readable media such as diskette 901, CD-ROM 902, magnetic tape 903 and fixed disk 904. To perform the embodiments, computer instructions may be retrieved from the machine-readable media 901-904 using their respective drives 905-908 into memory 900, and executed by a processor 910. The functionality disclosed hereinabove for performing the embodiments may find specific implementations in a variety of forms, which are considered to be within the abilities of a programmer of ordinary skill in the art after having reviewed the specification.
Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
Patent Application
20050268255
