System specifications

For the implementation of the prototype cost estimation system Microsoft Visual C++ has been used. The system consists of one executable and separate dynamic link libraries (DLLs) for every module. The executable can call all the dynamic link libraries and is mainly intended for use by a cost engineer who has to maintain the system. Other engineering tasks can call the dynamic link libraries directly, whenever they need the execution of a specific task.

Parts of a realised prototype system for Information Management as described in chapter 3 are used (Lutters, 2001). The functionalities of this prototype used are graph manipulation and database access, both implemented as dynamic link libraries as well. For the storage of information in databases, Microsoft Access databases are used. The calculation of cost functions is performed by MatLab, by means of a so-called engine; so any function can be dealt with by the system. For the creation of geometry, SolidWorks is used. SolidWorks has been extended to be able to cooperate with the Information Management software and to perform some simple process planning functions (see next section).

6.2 Cooperating systems

6.2.1 Creation of databases

A separate system was implemented to fill and edit the three information structures: the product information structure (PRIS), the resource information structure (RIS) and the order information structure (OIS). For reasons of simplicity, the system stores the contents of each of the information structures in one database. Theoretically multiple databases can be used, which are dealt with by the information management kernel. Every database consists of four tables for the storage of elements and relations for both the information structure and the corresponding ontology. A metabase is also created, which refers to the databases for the three information structures. The contents of the metabase can be characterised with a name (Figure 6.1).

Figure 6.1 The database manager.

An information structure can be filled with elements; for the elements attributes can be defined. Figure 6.2 and Figure 6.3 show the user interface for the manipulation of elements and attributes. The figures show an example of a Resource Information Structure and the corresponding ontology.

Figure 6.3 The corresponding ontology of the resource information structure.

For debugging reasons, it is possible to change and delete elements and attributes from the ontology and the information structure changes accordingly. It is possible to add elements directly to an ontology in order to be able to create types of any aggregation level. If for instance an Amada FBD3512E is of the type “Press brake” and Press brake is of the type “Machine”. The element “Press brake” of the type “Machine” has to be defined in the ontology. The remainder of the ontology arises from the information structure.

In the information structure, the elements are defined by a name, type and domain; see Figure 6.4 and Figure 6.6 for an example in the RIS. For reasons of simplicity, the view to which an element belongs is left out.

Figure 6.4 The definition of an element.

An attribute is defined by giving a name, unit, type and description (Figure 6.5 and Figure 6.6). It is also possible to assign a value; this is useful when the value of an attribute is more or less fixed. In the information structure an element is created of the type indicated by the name and with the value indicated by the number. The domain is the same as that of the element where the attribute belongs to. A relation between the element and the attribute is created as well. In the ontology an element of type parameter is created (if it does not yet exist) with the type of attribute as the name. For the description, the type and the unit of the attribute three elements are created in the ontology with the corresponding values. When an attribute is created for an element, this attribute belongs to elements of the same type as the element for which the attribute was defined.

Figure 6.5 The definition of an attribute.

The examples are from the RIS but the same can be done for the PRIS and the OIS. In the PRIS it is for instance possible to define frequently used features with their characteristics and in the OIS it is possible to define for instance orders with their characteristics. The three information structures are used to create an instantiated product information structure, which can be used to test the cost estimation system.

Figure 6.6 Graph representation of elements and attributes.

6.2.2 Design

In the manufacturing of physical products, the geometrical representations of the products are the basis for communication. Therefore it is be convenient to have a design system that can store geometric information in the element-relation format used in the context of the Information Management kernel. For this purpose, SolidWorks has been extended based on its Application Programming Interface (API). The feature tree of the design view of SolidWorks is traversed and information from this tree is transformed into elements and relations and stored in a database. The information that is stored includes: the assembly, the component, the features and the faces. No attributes, like dimensions, are stored yet.

6.2.3 Process planning

The geometry collected from SolidWorks serves, amongst others, as the basis for process planning. Because of the fact that SolidWorks offers a nice user interface and because it can be extended based on its API, a simple manual process-planning module has been added to SolidWorks.

Process planning requires at least information about the resources. So, in the process planning module, the metabase as described in section 6.2.1 has to be selected. Then the databases of the PRIS, the RIS and the OIS, which are referenced in the metabase, can be imported. From now on, all the information of the three information structures is available in the system.

In principle, the features used in SolidWorks are design features. For process planning manufacturing features are required. Because feature mapping is a research area in itself and because it is not the focus of this research, feature mapping is performed manually and on a one-to- one basis. In the case of sheet metal features, the one-to-one mapping of design features on

manufacturing can do the job in most cases. When the (design) feature tree of SolidWorks is traversed, as described in the previous section, the user is prompted to select the corresponding manufacturing feature. The user can select the manufacturing features defined in the product information structure (Figure 6.7). In contrast to the design features, the manufacturing features do have attributes, like dimensions. When the traversal of the (design) feature tree is finished, a new tree with manufacturing features is created (Figure 6.8). Process planning is performed, based on this (manufacturing) feature tree.

Figure 6.7 Manual one-to-one feature mapping.

Figure 6.8 The design (left) and manufacturing (right) feature tree.

Process planning is performed separately for each feature. For every feature, fabrication methods have to be selected (Figure 6.9), for every fabrication method machines have to be selected (Figure

6.10) and for every machine tools and operators have to be selected. The information about fabrication methods, machines, tools and operators is stored in the resource information structure. When a selection is made, it is possible to quantify the value of the attributes, like machining times (Figure 6.11). It is not possible to quantify attribute values with a fixed value, like cost rates (Figure 6.12). The quantification of the attribute values is not based on technological information and calculation.

Figure 6.9 Production method selection.

Figure 6.10 Machine selection.

Figure 6.12 Fixed attribute values.

The selected fabrication methods, machines, tools and operators are added to the feature tree (Figure 6.13). The feature tree and the attributes can still be edited. The new feature tree and all the attributes can be saved to a database and used by the cost estimation system. In the database, a reference to the SolidWorks file is saved as well. When in SolidWorks a database is opened, the SolidWorks file is loaded and the manufacturing feature tree and other information is added to the SolidWorks user interface.

Figure 6.13 The manufacturing feature tree and the selected fabrication methods and machines.

6.2.4 Production planning

As part of the research on a concept for concurrent manufacturing planning and control, recently a prototype of a decision support system for integrated order planning (EtoPlan) has been developed (Giebels, 2000). The prototype has also been developed based on the information structures related to the Manufacturing Engineering Model, though the prototype system for Information Management was not used in the implementation of the prototype of EtoPlan.

hierarchies of manufacturing resources. The holarchies are constructed by dynamically grouping the resources acccording to the requirements of individual orders. Within the EtoPlan concept the holarachies are referred to as Applicability Groups. A resource is considered applicable if:

• The resource is considered capable of meeting the already known technological requirements in the roughly defined process plans for executing (a part of) the order

• The resource is considered to be available during a time period that is roughly planned for executing (a part of) the order.

Therefore, an Applicability Group (AG) is a virtual group of all the resources that are considered applicable for the (partial) execution of a given order. During the product development cycle an AG will constantly be adapted by the results from executed tasks like process planning and production planning. Because AGs consist of resources, they are stored in the Resource Information Structure. An applicability view can be constructed by combining the capability and capacity view for managing the AGs. Besides AGs, it also possible to construct Method Applicability groups (MAGs). A MAG consists of a virtual group of all production methods, which are considered applicable for the (partial) execution of a given order.

In order to be able to support, for example, macro process planning, the planning system has to be able to deal with incomplete and uncertain information. Therefore, EtoPlan models uncertainty in its planning concept. The lead times and processing times of orders are modelled by a Beta- distribution, fitted on the minimum, maximum and most likely value estimation. The start times are modelled by a normal distribution. A generic order profile based on these assumptions is depicted in Figure 6.14.

Figure 6.14 A generic order profile.

By summing the resource profiles of all resources belonging to an AG, an AG availability view is constructed (Figure 6.15). The solid line represents the estimated loading profile of the group of resources (AG) that corresponds to the specific order for which the order profile is shown in the figure. The dotted lines show the loading profile if the estimations of the maximum lead times are considered instead of the Beta-distribution of the lead time.

When the order shown in Figure 6.15 has to be planned, it can be moved along the time axis. Besides the effect on the loading profile, the resulting variable costs that are a result of planning decisions can be considered. The costs can be made visible by a cost view based on the AG availability view. The costs that are relevant are (Huttinga, 2000):

• Extra payments for overtime work;

• The price for subcontracting minus the variable costs for in-house production; • Inventory costs due to excessive Work In Process (WIP);

• Lateness costs, in particular penalty costs;

• Earliness costs for short time delivery of blank materials.

Figure 6.15 An AG availability view.