Any electromechanical or electronics design stems from a functional model which satisfies the requirements of a product. The functional model is typically an h ierarchical top-down structure which illustrates the decomposition of higher level functions to lower level functions and also captures the functionality of the product. A designer at this point conceptually designs functional blocks to perform a set of functions for a give n design. It is possible that there can be many alternate designs possible to satisfy the sam e requirements of a given product. We propose a functional data model (FDM) whi ch embraces this methodology.
A generic FDM is shown in Figure 3, and can be further described as follows. Ea ch block in the FDM is a unique functional block element (FBE) which realizes a par ticular function of a design. For example, a power amplifier function in a microwave mod ule is realized by the power amplifier FBE. Each FBE is associated with a functional bill of material (FBOM) which is a list of parts and material required for implementing this function. After the function is designed then it goes to manufacturing, and duri ng this stage it is routed through many sequence of processes before it becomes a prod uct. The designer can associate each FBE with a set of planned processes that are requir ed for manufacturing. This set of processes are called functional list of processes (F LOP). For example, an amplifier function may require parts such as transistors, capacitors , resistors, and materials such as solder, cleaning solvent, and q-tips. The FBOM for an FBE thus consists of a list of parts and material and also the number of parts and materi al for each type. The Figure 4 shows the FDM for the power module example. The FBOM and FLOP are not shown in details to keep clarity of the figure.
The designer starts a conceptual design through a FDM. In order to produce an en d product, the FDM has to be mapped to an assembly data model (ADM), where each assembly can be considered as a manufacturable unit. The assembly captures desig n aspects of a product and is also subjected to the manufacturing operations. Ea ch assembly may consist of one or more FBEs thus constituting a manufacturable unit . The mapping of FDM to ADM data models depend upon the physical characteristics of an assembly including: number of parts that can fit in a given assembly, the size o f the assembly (dimensions of board, card, module, etc..), the packaging capacity on t he assembly (how densely parts can be placed), and the manufacturability of the ass embly (cost, yield, manufacturing rating).
The ADM is an hierarchical structure starts with a parent assembly and decompose s into children or subassemblies, similar to FDM. An abstract ADM is shown in Figure 5. The association between the parent and children assemblies is a containment relation ship, that is, subassemblies are part of the parent assembly. When an assembly is manufactu red, the sub-level assemblies are built first, and then they are integrated with their pa rent assembly. Each assembly is a manufacturable unit, either it can be manufactured internally in an enterprise, or it can be purchased from a vendor, or it may be available as an off-the shelf product. In all these cases, each assembly has manufacturing at tributes which are very crucial for its production and also for its success in the market place.
The FDM can be mapped into ADM based on the FBE characteristics. One or more FBEs can be grouped and mapped onto a single assembly. Figure 6 shows such mappi ng for a Power Module example. The mapping process involves merging FBOMs into BOM when two or more FBEs are mapped into a single assembly, and also merging FLOPs into LOP. We need to develop mapping algorithms to map FDM to ADM. Currently, t his mapping is done manually by the designer.
Each assembly is associated with a Bill of Material (BOM) which is a material a nd parts list for the entire assembly including the subassemblies. However, the subassem blies have their own part numbers and this part number is included in the BOM of the p arent assembly. For example, a1, a2 are part numbers for the subassembly of a parent assembly, they are included in the BOM for the parent assembly. Thus, the BOM includes parts, material needed for this particular assembly, and also part numb ers of the subassemblies. Each individual part or material has a part number by which it c an be referenced in the database.
Each assembly is also associated with a List of Processes (LOP) or a router. A router describes the manufacturing steps required and also necessary information needed for the operator to put together the whole assembly. In particular, the router consists of a sequence of processes, setup time and runtime for each process, and a list of ma terials or parts that are involved with each process. For example, a router may consist o f sequence of processes p1, p2, p3, ..., pn, where, a process p1 is related to material o r parts c1, c2, ..,cp. To illustrate this further, a soldering process (ps) may be associated wi th a capacitor (c1), a resistor (c2), and a transistor (c3). The parts list (c1, c2, c3) is a process BOM (PBOM) for the soldering process (ps).
There are always alternate choices available to perform a design, select a part or material, and to select a process. Thus, these alternate choices at product and process d esign phases offer variety of choices for the designer to pick and choose from and pos es a critical decision making problem with complex domains of information. As shown in Figure 5 an assembly may have a router or router' to choose from for assembling the assembly. A process p3 may have alternate processes p3', and p3". Similarly, a part c1 may have alternate parts c1', and c1". It is possible to have alternate FBEs available for a given FBE. In addition to alternatives, there are also other design approaches where you can add/drop new parts, material, processes, FBEs, and assemblies. Thus, we cla ssify these alternate options available in IPPD environment as follows:
alternate parts
alternate material
alternate processes
alternate functional block elements
alternate assembly block elements (assemblies)
Some of the examples for the above design observations are in order. A part suc h as transistor may have several alternatives available based on different vendors, d ifferent cost, and different quality. A process such as "soldering" may have option of c hoosing from manual soldering, preformed soldering, wave soldering, or epoxy. A functio nal block element such as amplifier 1 may be replaced with some other amplifier. An assembly a5, and a6 can be merged to a2 thus dropping a5 and a6 assemblies. A n ew design for power module may add new FBE at a preamplifier level. These examples illustrate the above point and it is evident that these options are real and sel ecting appropriate choices is vital to the product cost and quality and to the commerci al success of the product in global market place.
We captured the design options and choices available in FDM and ADM using AND/OR tree models (AOM). A typical instance of the input data for optimization prob lem is in the form of an AND/OR tree as shown in Figure 7. In the example being depicted by the figure, the main assembly consists of two subassemblies and a set of components (and associated processes) specific to the main assembly. As the tree evolves furthe r, similar structures will emanate from the subassemblies.
The nodes of this tree represent assemblies, function blocks, generic part types , specific part instances and processes. Furthermore, each node may have alternate nodes, corresponding to the alternatives specified by the input data. The arcs capture both the input specifications (such as which process acts on which process) and the hiera rchical structure of the design (such as the subassemblies and parts contained in each a ssembly).
As it can be seen from the figure, each node may have child nodes that are conne cted to it via 'AND-arcs' (all its children will need to be selected if this node is select ed to be in the design) or via 'OR-arcs' (exactly one of the child nodes must be selected). We point outthat it is always possible to construct the tree such that each node is either a n 'AND-node' (all its children are joined to it via 'AND-arcs') or as an 'OR-node' (all its c hildren are joined to it via 'OR-arcs').
Candidate designs (Pareto optimal solutions) are generated by choosing among the alternate nodes and arcs. The AND-OR tree, in addition to representing the inp ut data in a concise and intuitive form, has some useful theoretical properties. In partic ular, we show that the integer programming constraints that capture the logical structure of an AND-OR tree, form an integral polyhedron, a fact that is crucial to the efficien t solution of the multiobjective optimization problem.
We use entity relationships models (ERM) as our database models which are indepe ndent of underlying database system and data models. The Figure 8 shows the ERM for o ur manufacturing application. Attributes and other details in the figure are not s hown for clarity and also protecting the proprietary nature of our customer product.
Based on the ERM as shown in Figure 8, we have developed relational data models[ 12] and used to implement the relational database management applications in Paradox , and other relational DBMS systems. These models are not discussed in this paper due to clarity and space problems.
We used entity relation models to develop our object-oriented data models[14,18] . The object-oriented data models are used to implement the ObjectStore application. The Object Manager consists of implementation of these object data models in additio n to interfacing with optimizer, bridge, and GUI. The Figure 9 shows a brief layout of the object-oriented data model diagrams which are directly derived from the ER Diagr am shown in Figure 8.