Conceptual Design Tool

1. Field of the Invention

The present invention generally relates to a computer based project management system and, more particularly, to a system which uses a top down functional approach to hardware product design which involves creating and exploiting a hierarchical tree view of the product structure early in the design process.

2. Description of the Prior Art

The process of designing, developing and manufacturing a new product, or making major changes to existing products, presents many challenges to product managers and engineers to bring the product to market for the least cost, within schedule while maintaining product quality. In today's highly competitive industries, product managers and engineers require information to address many problems that arise because of the complexity of new products and the complexity of world-wide production and the changing nature of competition. Because new products need to be brought to market in a very short time period to meet the competition, the traditional learning curve formerly associated with product development has disappeared, creating the need to better control product release and determine cost impacts of designs early in the design process.

To meet these needs, many companies are realizing that the conventional product design process is not satisfactory. They require early involvement of manufacturing engineering, cost engineering, logistics planning, procurement, manufacturing and service/support with the design effort. In addition, they require planning and control of product data through design, release and manufacturing.

Project Management, as a modern management tool, has its origins in the early part of this century when Henry L. Gantt, while working for the government during World War I, developed his now famous visual aid for work control. The Gantt chart is a graphic representation of a project schedule that shows each task as a bar having a length proportional to the duration of the task. Later during the 1950s, Dr. John Presper Mauchley, a co-inventor of the EDVAC at the University of Pennsylvania, developed the Critical Path Method (CPM) which was further developed by Willard Frazer, a consultant on the Polaris submarine project. Frazer's contribution was called Program Evaluation and Review Technique (PERT). A PERT chart is one that resembles a flow chart showing predecessor and successor tasks of a project and the critical path.

PERT/CPM models are known and have been used for many years by many large corporations for project management. Such project management tools were first implemented on main frame computers and then on mini computers, equipment which was readily available to large corporations but not to small corporations and firms. More recently, various project management software products have been developed for micro or so-called personal computers. These have made computer based project management tools more economically accessible to small corporations and firms, but their application requires some degree of sophistication on the part of the user. As a result, many small corporations and firms still use manual methods of project management, often relying on an expediter to stay one step ahead in scheduling supplies and work on a day to day basis.

Rupert A. Schmidtberg and Mark A. Yerry in an article entitled "Designing Complex Assemblies Using the Top-Down Approach" published in Autofact 1986 Proceedings, at pages 9-31 to 9-43, describe a design approach where the engineer first creates the top-most assembly and works downward, filling in of the subordinate subassemblies and parts. In this approach, a hierarchical representation of the design object is built and refined. As a design concept is refined, design constraints are communicated down the hierarchy. Evaluation of the design concept at each level of refinement may cause feedback to be passed up the hierarchy in the form of recommendations for design changes or requests to relax some design constraints.

This top-down design approach has significant advantages over the traditional approach to design of a new product. The Schmidtberg and Yerry implementation, however, is in the environment of a CAD/CAE system which assumes a high degree of computer design sophistication on the part of the user. What is needed is a simpler to use system which takes advantage of the top-down design approach.

It is therefore an object of this invention to provide an easy to use system which implements a top-down functional approach to hardware product design.

It is another object of the invention to provide a system which integrates a top-down design approach and prompts the new product designer by a graphic display of the product components.

According to the invention, a sketch sheet approach on a computer display is used to enter the functional design of a product. The user needs to key in only part descriptions, and the system automatically draws a hierarchical tree structure on the computer display. The user is then prompted to consider, part by part, all of the parts in the product. A series of menus pop-up and guide the user through manufacturing planning for that part.

The process begins by producing a functional sketch of the product design. This sketch is in the form of a hierarchical tree structure, thereby encouraging the top-down design approach. The system queries the user for component parts of the product, and as the query process progresses, the tree structure is created on the computer screen for the user to view.

Behind each element, or item, in the functional hierarchy of the product, associated engineering design and manufacturing information is gathered. This manufacturing detail is used for product release planning and scheduling, and manufacturing planning, as well as for feasibility level cost estimating. The user has the option at any time during the design process to deal with the proposed product or product components at a high level or at a very detailed level. At any level, manufacturing details which are not known by the user can be defaulted from a relational database using the known item attributes.

The product designer is aided in implementing early manufacturing involvement, or the integration of the design process with manufacturing and other production-related concerns. The designer is prompted to enter manufacturing data for each item in the product structure, thus introducing a third dimension to the hierarchical tree structure. This third dimension serves several purposes. The manufacturing data can be manipulated to produce needed estimates and schedules for the designer. The manufacturing data of interest falls under four categories: (1) information which assists in planning the manufacture of the product, (2) information which assists in producing a cost estimate of the product, (3) information which assists in generating a product release schedule, and (4) information which will assist a CAD/CAM designer or product planner in locating similar items. In the fourth instance, the designer or planner then has the option to use the similar design, avoiding another design effort, or to use the existing design as a template to modify or for other guidance in preparing the new design.

The hierarchical approach implemented by the invention provides a convenient interface to product costing, as early cost estimates will consider only the very high level assemblies and not consider low level detail. As the release plan reaches completion, however, much more detail becomes available and the product cost estimate will roll up the more detailed tree structure to provide a more precise estimate. Cost estimates at the very early development phase of the product help determine product feasibility as well as to direct engineering effort at the most significant portions of the product.

The invention will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1 is a system block diagram showing the functional requirements for implementing the conceptual design tool according to the present invention;

FIG. 2 is a screen illustrating the computer display of a hierarchical tree structure generated by the system for a hypothetical product under design;

FIG. 3 is a screen illustrating the computer display of early manufacturing involvement data for one component of the structure shown in FIG. 2;

FIG. 4 is a screen illustrating the computer display of early manufacturing involvement data for one component with default data entered by the system;

FIG. 5 is a flow chart showing the logic of the conceptual design tool according to the invention implemented in software;

FIG. 6 is a flow chart showing the logic of the query session during which a relational data base table is built;

FIG. 7 is a flow chart showing the logic of the product costing using the conceptual design tool according to the invention; and

FIG. 8 is a flow chart showing the logic of the generation of a parts list in the form of an indented bill of materials.

Referring now to the drawings, and more particularly to FIG. 1, there is shown in functional block diagram form the conceptual design tool according to the invention. The key parts of this system are the database 10 and the query system 12. The database 10 could be any of several products currently available, but for purposes of the preferred embodiment, IBM's DATABASE 2 (DB2) is used. DB2 is a relational database management system, but it will be understood by those skilled in the art that other databases, including hierarchical databases, could be used. The query system 12 could be an expert system, but for purposes of the preferred embodiment, IBM's Restructured Extended Executor (REXX) language is used. General information on IBM's DB2 can be had with reference to publication GC26-4073-2 published by IBM Corp. A description of the REXX language is provided in Virtual Machine/Systems Product, System Product Interpreter User's Guide, Release 4, publication SC24-5238-2 published by IBM Corp.

The user 14 is first queried on the functional product structure by the query system 12, and in response to the user input, the database 10 captures the structure in a table. The query session begins by prompting the user to input the name of the product. The product might be a new lawnmower, for example, and the user would simply type in "LAWNMOWER". Then the user is able to type in the major components of the product. In the case of the lawnmower, this might be a handle, a grass catcher, a motor cover, a blade, wheels, documentation, electronics, and a battery. These would be individually entered by the user, in no particular order, in response to a prompt to enter the next component or indicate that there are no more major components by entering "END" or by pressing a designated key. Once the major components have been entered by the user, the user enters "END" or presses the END key causing the query system to examine the subcomponents of the major components that have been entered. For example, the query system 12 would prompt the user 14 to enter the components of the handle. These components might be an upper handle assembly with controls and a lower handle assembly which attaches to the lawnmower frame. Again, when all the subcomponents for the handle have been entered, the user enters "END" or presses the END key, causing the query system to next prompt the user to enter the components of the grass catcher, and so on. The process continues until the user has entered all the components of the new product to a level of detail desired, at least for the time being. It should be understood, however, that the user can return to the design session at any time and add more detail and/or change earlier input component data.

As the query session progresses, the components entered by the user 14 are captured in a table of the relational database 10 and a functional hierarchical tree of the structure 16 is generated on the computer screen. For the example described above, this hierarchical tree structure is shown in FIG. 2 of the drawings to the first level of detail of the design. While only two levels are shown, those skilled in the art will understand that, within practical limits, an indefinite number of levels may be generated depending on the product and the level of detail required to define that product. In a specific embodiment of the invention, up to thirty levels of the tree structure are allowed. Experience indicates that this is sufficient for all but the most complex of products. Also, depending on the capabilities of the display system being used, the hierarchical tree structure may be displayed on several successive screens as the level of detail progresses.

To do product costing, a product structure is first created using the hierarchical tree structure. For each item in the product structure, the user must enter known manufacturing information. From this information, cost estimates can be drawn from the database 10. The user inputs a rough estimate on overall product assembly time in hours per unit, as well as a contingency factor, like 15%. The system decomposes the product structure into a parts list 18, and quantity of each part as well as cost per part are pulled from the manufacturing information table in the relational database associated with each item. The cost estimating function then multiplies each part on the list by quantity of that part, then by cost of that part. The results for the parts list are added. The labor estimate is multiplied by the standard hourly labor and burden rate. The results of the parts list multiplication and the labor multiplication are added, and the result is output to the user.

The manufacturing data a user would be interested in would depend on the nature of the business, but some examples are listed below:

1) Function of the item (e.g., fastener, cover, sealant, etc.);

2) Process by which the item is made (e.g., injection molding, casting, grinding, etc.);

3) Material used to make the item (e.g., PVC plastic, aluminum, etc.);

4) Item type (e.g., assembly, detail part, etc.);

5) Cost of the item;

6) Finish type and quality;

7) Weight;

8) Size (e.g., diameter, length, etc.);

9) Technology required to produce the item;

10) Procurement source;

11) Lead time to design the item;

12) Lead time to provide tooling to make the item;

13) Lead time to procure the item; and

14) Lead time to prototype the item.

FIG. 3 shows a screen from a computer display which would appear when the user selects, for example, BATTERY as the object and chooses the action "DETAIL". The design engineer keys in known manufacturing data using this screen. In this example, the designer intends to use an "off the shelf" battery to be purchased complete from Sears. There is one battery in the product structure, and its function is power unit. The user can then choose to have default values supplied from the relational database based on known item attributes. The user selects the action "DEFAULT", and the screen shown in FIG. 4 is displayed. The method by which the relational database can access these defaults is by accessing the table in which the user input data was captured during the query session. More specifically, the attributes in the table are accessed by attribute numbers and these numbers, in turn, are used as an index to access the default attributes for items, these values having been previously stored for similar parts in the database. The screen shown in FIG. 4 displays the resultant default values, marked by an asterisk. The system has generated an item number, A000. From the position of the item within the tree, the system has determined that it is a Main Assembly. The full name of the vendor, Sears Roebuck, Inc., is inserted. The process by which the battery is incorporated into the product is assembly. Tooling leadtime defaults to zero since the item is purchased complete off the shelf. The cost per battery, based on actuals, is $15.00. An item classification, or group technology classification is system generated based on the gathered attributes, function, sourcing strategy and vendor. This item classification code can be used in many production planning functions, including scheduling and procurement.

Referring now to FIG. 5, there is shown a flow chart of the logic of the conceptual design tool according to the invention implemented in software. One of ordinary skill in the art can write source code from this flow chart in any suitable computer language, such as BASIC, Pascal or C, for any desired computer system, such as the IBM Personal System (PS) computers which support those computer languages.

The process begins by inputting the functional structure of the product as indicated by function block 100. This is done during the query session as is described in more detail with respect to FIG. 6. Once the functional structure of the product has been input and the hierarchical tree structure has been generated to the current level of detail desired, the user is prompted to select an item in the structure in function block 102. When the user selects an item, the system provides a pop-up panel for manufacturing details in function block 104. This pop-up panel allows the user to key in known manufacturing information in function block 106. When this information has been input by the user, the system generates an item number in function block 108. The system then allows the user to choose to access default information in function block 110. A test is made in decision block 112 to determine if the user has chosen to access default information. If not, a test is next made in decision block 114 to determine if there are more items for which manufacturing details are to be input. If so, then the process loops back to function block 102.

Assuming that the test in decision block 112 is positive, that is, the user chooses to access default information, then in function block 116, the system accesses the default values in database 10 and inserts those values. Then, in function block 118, the system generates an item classification code. The user is given the option of overriding any of the default data in function block 120. A test is made in decision block 122 to determine if the user chooses to override any default data. If so, the system loops back to function block 106 which allows the user to key in known manufacturing data as a typeover of the previously inserted default data; otherwise, the system loops to function block 102 to select the next item in the functional structure of the product. Eventually, the test in decision block 114 will be negative, and the process ends.

FIG. 6 show in flow chart form the logic of the query system according to the invention. This flow chart in combination with a dialog system, such as IBM's REXX language, and a database system, such as IBM's DB2, is sufficient for a programmer of ordinary skill in the art to write the required code to implement the query system. With specific reference to FIG. 6, the process begins by setting l=1 at block 220, where l is the product or component level. Then, at function block 222 the user of the system is prompted for the product name. In the example given, the name would be "LAWNMOWER". The system waits for a user input at decision block 224, and when the product name has been input, the system opens a file in the database with the product name and displays the product name on a computer screen in function block 226. In block 228, l is set to l+1 indicating the next level of components, and the system then prompts the user in function block 230 for the components of the product at this level. Each time the user inputs a component as detected by decision block 232, the inputted component is stored in the database for that level in function block 234, and the system displays the inputted component on the computer screen at a node of the tree structure in function block 236. The system will continue to prompt the user for components after each component is entered by the user until the user enters "END" or presses the END key which signals an end to the list of components for this level. Thus, the system tests the user input in decision block 238 for the entry of "END" or the pressing of the END key. If that input is not detected, then the system waits for the next user input in decision block 232, and when an input is received, the component is stored in the database table in function block 234 and so forth.

Once all the components have been input by the user for a given level as indicated by entering "END" or pressing the END key, the system then determines in decision block 240 if the last component in the current level has had components input by the user. If not, the next component in the current level is highlighted in the displayed tree structure, and the system loops back to function block 230 where the user is again prompted for components of this component. On the other hand, if the last component of the current level has had components inputted by the user as detected in decision block 240, the system tests for a user input in decision block 244 to determine if components are to be entered for the next level. This is accomplished by the user pressing a Y key or an N key when prompted for the next level. If the Y key is pressed indicating that the user now wants to input the next level of components, the system loops back to block 228 to index to the next level. If on the other hand, the N key is pressed indicating that the user does not at this time wish to input the next level of components or that there is no next level of components to enter, the query process ends.

Product costing using the conceptual design tool according to the invention is illustrated by the flow chart shown in FIG. 7. The process begins at a point where both the functional structure (FIG. 6) and the manufacturing details (FIG. 5) have been input. In function block 124, the user is prompted to input product assembly time and percent contingency for estimating purposes. When this data has been input by the user, the system decomposes the structure into a parts list in function block 126. The manner in which this is done is detailed in FIG. 8. The system then generates the quantity and cost of the part from the manufacturing details in function block 128 and repeats this process for each part in block 130. When all parts have been processed for quantity and cost, the cost and quantity for each part are multiplied in function blocks 132 and 134 to arrive at a series of cost figures for all parts in the product. These cost figures are summed in function block 136 together with a cost figure which is the product of assembly time multiplied by the sum of the labor and burden rates. This estimated cost figure is then output to the user by printing, for example, in function block 138, and the process ends. The printout of the cost data includes not only the final estimated product cost but also the data from which that estimated cost is derived.

Turning now to the flow chart of FIG. 8, the parts list in function block 126 is automatically generated as an indented bill of materials from the table in the database which was built during the query session. Again, this flow chart shows the logic of the automatic generation of an indented bill of materials, and any programmer skilled in the art with an understanding of database systems, such as the IBM DB2 database, can write code to implement the invention from the logic of the flow chart. The process begins in FIG. 8 by setting l=1 and i=0 in block 246, where is the component level as before and i is the indentation of the bill of materials. Next, item 1 of level l is accessed in function block 248. In the example given, this item is the product name "LAWNMOWER". Item 1 is then printed in function block 250, and l and i are then indexed by adding 1 to each. A test is then made in decision block 254 to determine if any level l is left in the tree. If so, the system accesses the next left-most item in the tree of the current level in function block 256. The accessed item is then printed in function block 258 with indentation i. A search is then made of the database in function block 260 for antecendents. If any are found in decision block 262, the system loops back to block 252 where the level and indentation are indexed by one. Otherwise, a test is made in decision block 264 to determine if the last item of the current level has been connected. If so, the level and the indentation are indexed backward in block 266 by subtracting one from each. The process then returns to decision block 254 to continue the process of accessing and printing items in order. When the test in decision block 254 becomes negative, that is there are no levels l left in the tree structure, the level and indentation are again indexed backward by subtracting one in block 268. A test is then made in decision block 270 to determine if the indentation i is less than or equal to zero. If not, the process loops back to decision block 254; otherwise, the indented bill of materials is complete and the process ends.

From the foregoing, it will be appreciated that the conceptual design tool according to the invention provides an easy to use system which implements a top-down functional approach to hardware product design. The system encourages early manufacturing involvement to develop the information needed to aid and improve the total design and manufacturing effort needed to produce the final product.

While the invention has been described in terms of a preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification and alteration within the spirit and scope of the appended claims.