Product Functionality Information Model for Managing the Product Development Process

214

Product Functionality Information Model for Managing the Product Development Process

Sam Albert¹, Devi Thirupathi²

1 24/7 Customer Pvt Ltd, Bangalore, India [email protected]

2 Bharathiar University, Coimbatore, India [email protected]

Abstract

—

Index Terms

—

I. INTRODUCTION

A product can be looked upon as a technical system, which can be defined as a set of interrelated subsystems or machine elements comprising a whole that is intended to achieve a particular function [Andersson and Sellgren, 2003]. A product’s functionality is the consequence of the combination of features required by customers, and generally is used as a basis for the product development [Albert and Thirupathi, 2004]. These features are the specification of functional requirements and constraints that define the functionality of the product; and this can be presented as a functional representation/structure. A functional structure describes what the product is for, and how the product works and this determines the overall functionality of the product. As per Thirupathi (1998), for effective management of technical process, information on product functionality is essential.

Information on product functionalities and status of parameters (defined, pending, undefined) associated with them play vital roles in the management of the product development process.

Every element of the product has a function [Blessing, 1994]. A small percentage of the parameters called critical parameters will be the key to the product’s functional performance. By managing the critical parameters in a product the designer can have full control of the functional characteristics of the design [Fox, 1994]. The product data relevant to the critical parameters provides valuable knowledge about the failure modes that are prevalent in the mature

product and which of these creates most customer dissatisfaction. This leads the designer into an understanding of which of the functions of the mature product are least robust or most prone to failure. The model will meet the requirement to link the failure modes with the critical parameters that drive them. The critical parameters provide the basis for deciding where the design effort should be applied to enable maximum gain to be made in terms of customer satisfaction of the product.

Design teams charged with the task of improving an existing product often use only their intuition to develop the specific areas to be addressed.

This can often cause programmes to get open-ended development, which eventually has to be abandoned due to the urgency of getting the new product into the field. Introducing structure to this area by the use of critical parameter management is an effective way of managing the evolution of new product developments from existing designs [Fox, 1993]. The critical parameters are the glue between product functionality and physical structure of the product. In order to manage critical parameters, it is necessary to understand the relationship between product functionality and physical structure of the product. An effort has been made to introduce structure to this area by providing a link between product functionality and physical structure of the product and this is described using this model.

II. OBJECTIVES

Through the process of product development, ideas and needs are converted to the information from which technical systems and products can be made [Pahl and Beitz, 1984 and 1996; Hales 1987]. To be successful, a new product must offer customers better functionality, in comparison with other existing products. The product development is characterised as

“the process of devising artefacts to attain goals i.e.

product functionalities”. The main objectives of this research have been to:

• study and analyse the product functionality in detail and its association with the physical structure of the product in the context of product development

215

• design the concepts to represent the product functionality, physical structure and the association between them.

• design and develop a software prototype to prove the above concepts .

III. LITERATUREREVIEW

Baxter (1994a and 1994b) proposed a functional data model capable of representing the functional description of a product that can be used by engineering applications and defined it using EXPRESS, an information modelling language. A prototype framework for capturing information related to product function has been defined using the attributes: name, inputs (set of measures), outputs (set of measures), has_need_of and performed_by (assembly, component or feature). The functional data model stands on its own and is not linked with the applications that it can support. The model represents the input and output values, but do not have any mechanism to supply information to the applications that need this information. Thus, the link between the functional data model and its usage by an application is missing [Thirupathi, 1998]. Thirupathi’s critical review of the functional data model of Baxter is from the process point of view. But the functional data model, if analysed from the product functionality point of view, does not represent any reasonable link between product functionality and physical structure in terms of the parameters that are involved in determining the functionality of the part. The critical parameters are also responsible in determining the design parameters of the respective part related to the functionality. The critical parameters do not find a place in Baxter’s functional data model at all. The integrated information model of Thirupathi (1998) represents product functionality but critical parameters are not extensively addressed and the association between product functionality and physical structure is also not present.

Reed (1993), Gui and Mantyla (1994) have proposed and developed representation of product functionality as a functional model. Even though it is identified that common goals (product functionalities) are to be shared among the Concurrent Engineering team members, there is no mention of the representation of the link between the product functionality and the process that generates the product with the required product functionalities, and, product functionality and the Product Introduction (PI) resources [Thirupathi, 1998]. In line with Thirupathi’s review, further analysis proves that the above model has no representation of links between the physical parts of the product and functionality and there is no means of indicating the attributes of the part, which may include critical parameters of the functionality.

IV. REQUIREMENTS OF THE MODEL

An information model for Product Functionality is the conceptual description of ideas, facts and relationships that together represent the end product. The requirements of the Product Functionality Information Model are such that it has to:

i. represent product functionality in terms of critical parameters, noise factors, response and failure modes.

ii. allow the representation of all the functions of the product as a function structure.

iii. represent the parameters that are associated with the function link the failure modes with the critical parameters that drive them.

iv. provide the means to review each of the critical parameters and evaluate the latitude gained and eliminate failure modes by enhancing control over the critical parameters.

v. identify the functions that are most prone to failure.

vi. the parameters that are associated with a the function are used to represent the relationship between function and parts as attributes of physical parts.

vii. support applications that use information about product functionality, physical part and their relationships for the related activities.

V. THEPRODUCTFUNCTIONALITY INFORMATIONMODEL

Figure 1 represents the object model of PFIM.

Functionality captures product functions, translated from engineering requirements. Part has the details about the product components and their attributes. Parameter is represented by the inputs that control the function and the response expected from the function. In case of new product development, and product or process modification, the PFIM can be used as a support tool to find out the effect of change in functionality/part. This would lead to an effective way of managing the evolution of new product developments from existing design. (Figure 1)

Figure 1. Object model for Product Functionality

216

Product development process management involves information on product physical structure, product functionality, project and resources. Crucial for the management of the product development process is the availability of a suitable and formally defined technique for the representation of the product functionality and physical structure of the product. The development of the PFIM starts with choosing the information modelling approach: Entity Relationship, Functional, or Object Oriented; and the object-oriented approach has been chosen here. Then PFIM proceeds to selecting the right combination of modelling languages. Once these tools for setting up the environment are chosen, then the scope of applications is defined, the information requirements are determined, and the conceptual data model using a formal data definition language is written down. The PFIM provides a sharable, stable, and organized structure of information requirements. It is developed to preserve independence from both usage and implementation by providing an integrated environment. Integrated engineering databases built using information models of product description have many advantages. Using them, engineers can store product data, shorten design time, and reduce the cost of designing.

V.A Product Functionality Schema

The Product Functionality Schema maintains the following types of information on identification of function, design intent, functional analysis, function diagram and information maps associated with the product functionality. Information maps are discussed in detail below. The product functionality schema represents the functional structure of the product. As achieving a product that provides the required product functionality is the goal of the product development process and that goal has to be shared by the teams working on it, product functionality is represented separately from the physical structure of the product.

The schema corresponding to the product functionality is named ProductFunctionality_Schema and it includes a data structure named Functionality that would represent the product functionality data (Table 1).

Table 1. Definition of the data structure for product functionality

Schema name PFIM_Schema

Sub-schema name ProductFunctionality_Schema Data structure name Functionality

Attribute Domain FunctionCode Numeric FunctionName String Description String

CriticalParameter Set_of Functionality_InformationMap NoiseFactor Set_of Functionality_InformationMap Response Set_of Functionality_InformationMap FailureMode Set_of FailureMode

Table 1 represents the data structure Functionality with the attributes such as FunctionCode that uniquely identifies the function. A name and description can be added to describe the function in detail for better understanding using the attributes FunctionName and Description. The definition of the data structure Functionality makes use of the other data structures such as Functionality_InformationMap, which establishes the link between different sets of parameters and the functionality. The critical parameters, noise factors and response can be used to enter the relevant information as a set of parameter information map schema. The information map schema is discussed in detail below. FailureMode is the attribute for representing the failure modes with the functionality using the Failure Mode data structure.

The attributes of the parameter contribute to the functionality of the product. The parameters linked with the functionality are also the attributes of the product. The information about every parameter is stored in the model. Parameters play the role of input as critical parameters and noise factors, and output as responses with respect to product functionality. The relationships between product functionality and parameters are represented in the functionality schema by the data structure Parameter. These parameters are the attributes of the product and they evolve during the product development process. Other data structures that are under the functionality schema are Functioanlity_Functionality, FailureMode and Functionality_InformationMap.

V.B Physical Part Schema

Modeling to support product design is largely based on physical structure of the product too apart from the product's producibility or its intended use.

The physical part schema captures the following types of product information on the physical structure of the product, functionality of the product and technical information of the product. Product information on the physical structure of the product used by the product introduction process is represented in the PhysicalPart_Schema.

The physical part schema makes use of the associations between product and its functionality.

Functional and physical integration of the product is very essential in order to have an integrated control over the diverse targets of the product introduction process. Against each product functionality, a list of physical parts of the product that contribute to that functionality need to be generated. A physical part of the product may play a role in many functionalities, on the other hand a single functionality may require many different physical parts of the product. In either case this relationship is captured by the data structures Part and Part_Part defined under this schema. Apart from these, the idea of attribute mapping as proposed by

217

Thirupathi (1998) is made use of in representing the parameters of the physical part. The parameters typified as attributes of the physical part may be derived from more than one parameter of a functionality and also from the parameters of other functionalities.

V.C Information Map Schema

Product Introduction process that generates and uses the product information is related to the product information through the semantic associations between them, and the information maps in the information map layer would represent these semantic associations. The concept of information map was introduced by Thirupathi(1998). The schema corresponding to the information map data model is named InformationMap_Schema as shown in Table 2.

The definition of its data structure is based on how the relationship between the product functionality information and physical part of the product information is viewed. As the product is evaluated against the optimal parameters for both functionality and physical parts of the product, the information map classes are defined dynamically.

Table 2. Definition of the data structure for information map

Schema name PFIM_Schema

Sub-schema name InformationMap_Schema Data structure name InformationMap

The information map classes are instantiated with values from the appropriate user-defined classes, which are used as parameters for the Functionality Schema. An information map may be made of other information maps. For example, an output (information map) of a higher-level functionality could be a report aggregating the outputs (information maps) of the lower level functionalities. By defining the type of the attribute of an information map as an information map, the instances of the information map become nested and form a structure.

The information map schema shows the links that represent the semantic relationships between product functionality and product parts. In order to dynamically create the data structures that represent the information maps, the definitions of the data structures of the information maps are stored first in the meta- model as instances of MetaClass. The information (or details of) on the data structure of the class that need to be created dynamically is represented using MetaClass as shown in Table 3. The MClass stores the name of the class and MCAttributes stores the list of attributes.

Using these details, a class with the name specified by MClass can be generated

Table 3. Definition of the data structure MetaClass Schema name PFIM_Schema

Sub-schema name InformationMap_Schema Data structure name MetaClass

Attribute Domain MCCode String Mclass String MCAttribute Set of MetaAttribute

The information on the functionality of the product (or physical structure) is stored in the respective schemata of the functionality database.

There are clearly defined data structures under each schema similar to the functionality data structure as shown in table 1. Each schema has a set of data structures to capture the indispensable information required for the representation of product functionality in consideration of the product development process.

The attributes defined under the respective schemata provide necessary links between the schemata establishing the relationships between them.

VI. PROTOTYPE

The prototype for PFIM was designed to provide a means to assess the model’s capability to express functionality and the relationships associated with it. The underlying structure of this prototype reflects the structure of the PFIM. The physical structure of the product and its functionality along with the relationships and other attributes can be fed into the database through the interfaces. The prototype facilitates a more thorough exploration of the precise nature of the schemata used in the PFIM. Since the structure of the software prototype is designed to reflect the architecture of the model, much of the activities and engineering solutions related to product development can be explored within the applicable technical constraints.

Data managers maintain the data relevant to the data structures used in the prototype. Here the data managers are mainly categorized into three categories namely, Product Functionality Data Manager, Physical Part Data manager and Information Map Data manager.

VI.A Product Functionality Data Manager

The prototype makes use of data structures related to product functionality, which are managed by the product functionality data manager. The data structures that store the product functionality information and other linked information are used to represent the relationships between functionalities; the product functionality data manager maintains the following types of information:

1. Information on the identification of function 2. Design intent

3. Information on functional analysis 4. Information on function diagram

5. Information on information maps associated with the product functionality

218

The figure 2 shows the graphical representation of the function diagram, which embodies the information within a functionality using EXPRESS-G notation..

Figure 2. A representation of information on function diagram

VI.B Physical Part Data Manager

The physical part data manager allows the maintenance of the data relevant to the product such as physical structure of the product and technical details of the product. Physical part data manager captures the following product information:

1. Information on the physical structure of the product

2. Functionality of the product

Figure 3 shows the relationship between a product part and its functionality.

Figure 3. A representation of the relationship between a physical part and its functionality

VI.C Information map data manager

The relationships among product functionality, its parameters and physical parts of the product are represented using information maps which

assemble sets of related information that are traditionally available at the same time but not in a consolidated form facilitating easy access and use. The structure of the information map contains pointers to the related objects that are stored in different databases, and other properties of the relationship among the related objects. Information map guarantees good and easy retrieval of information as a group and enables information flow among the activities of the product development process.

VII. CONCLUSIONS

This research is concerned with the study and analysis of product functionality and its association with the physical structure of the product and to develop a product functionality information model for effective management of the product development process. To be successful, a new product must offer customers better functionality, in comparison with other existing products. Crucial for the management of the product development process is the availability of a suitable and formally defined technique for the representation of the product functionality and physical structure of the product.

The overall PFIM model consists of a functionality schema and a physical part schema with defined relations between them represented using an information map schema. The functionality schema represents information on the functionality and the parameters related to the functionality. The physical part schema represents the physical structure of the product, i.e., the necessary information about the assembly elements used for analysis or product realization. An information map schema is used to represent the relationships between above two schemata. A software prototype that represents the concepts behind PFIM has been developed using relational database concepts.

The PFIM model can be linked to other information models of product development process.

The product development process can be managed effectively by making use of the PFIM because it can provide the necessary information on product functionality and physical structure of the product for effective management of the product development process. As the model uses the function diagram, which depicts function, responses, failure modes and the critical parameters and noise factors that control these, PFIM will enable the product development process to make good use of the existing product data and bring more control of the design to the proposed new product. The critical parameters provide the basis for deciding where the design effort should be applied to enable maximum gain to be made in terms of customer satisfaction of the product.

219

REFERENCES

[1] Akao, Y., (1990), “Quality Function Deployment: Integrating Customer Requirements into Product Design”, Productivity Press, Cambridge.

[2] Albert, S.P., Thirupathi D., (2004), “Towards an Information Model for Product Functionality”, Proceedings of the National Conference on Information Technology, DAV College of Engg., Amritsar, Punjab, India.

[3] Amalnik, M.S., (1994), “Integrated Product Development at Design and Manufacturing”, National and International level based on Computer Based System and Concurrent Engineering, Proceedings of Factory 2000 - Advanced Factory Automation Conference, (IEE, 3-5 Oct), pp. 249-256.

[4] Andersson, S., Sellgren, U., (2003),"Modular product development with a focus on modelling and simulation of interfaces", 6th Workshop on Product Structuring - application of product models, Technical University of Denmark, Dept. of Mechanical Engineering, Copenhagen, Denmark.

[5] Arthur, H.M., Hofstede, T., (1993),

“Information Modelling In Data Intensive Domains”, C-G K Bibliotheek, Den Haag.

[6] Baxter, J.E., (1994), “A functional data model for assemblies used to verify product design specifications”, Proceedings of the Institution of Mechanical Engineers, (Part B - Journal of Engineering Manufacture), 208(B4), pp. 235- 244.

[7] Blessing, L.T.M., (1993), “A process-based approach to computer supported engineering design”, Proceedings of the International Conference on Engineering Design (ICED

’93, The Hague, 17-19 August), pp. 1393- 1400.

[8] Blessing, L.T.M., (1994), “A process-based approach to computer supported engineering design”, Ph.D. thesis, (Netherlands : University of Twente), pp. 139, 140, 169.

[9] Cohen, L., (1995), “Quality Function Deployment: how to make QFD work for you”, Addison-Wesley Publishing Company, Massachusetts.

[10] Fox, J., (1993), “Quality through Design - The key to successful product delivery”, (London : Mc-Graw-Hill).

[11] Fox, J., (1994), “Designing for Function”, Engineering Designer, Jan/Feb, pp.12-13.

[12] Gui, J.K., Mantyla, M., (1994), “Functional Understanding of Assembly Modelling”, Computer-Aided Design, pp. 435-451.

[13] Hales, C., (1987), “Analysis of the Engineering Design Process in an Industrial Context”, Ph.D. thesis, (Cambridge:

University of Cambridge).

[14] Hauptman, O., Hirji, K.K., (1996), “The Influence of Process Concurrency on Project Outcomes in Product Development: An Empirical Study of Cross-Functional Teams”, IEEE Transactions on Engineering Management, 43(2), pp. 153-164.

[15] Hauser, J. R. And Clausing, D., (1988), “The House Of Quality,” Harvard Business Review, (3), 63-73.

[16] Hundal, M.S., (1993), “Engineering and Management for Rapid Product Development”, Proceedings of the International Conference on Engineering Design (ICED ’93, The Hague, 17-19 August), pp. 588-595.

[17] “Information Modelling Techniques”, http://mint.cs.man.ac.uk/Technologies/Inform ationModelling.

[18] Krause, F.L., Ulbrich, A., Woll, R., (1993),

“Methods for Quality – Driven Product Development”, Annals of the CIRP, Vol.42/1/1993.

[19] Pahl, G., Beitz, W., (1984), Engineering Design, Edited by Wallace K., (London:

Design Council).

[20] Reed, R.G., (1993), “An Application of Extended Function Logic to the Design of a Wearable Computer”, Proceedings of the International Conference on Engineering Design (ICED ’93, The Hague, 17-19 August), pp. 251-255.

[21] Rumbaugh, J., Blaha, M., Premerlani, Eddy, F., Lorensen, W., (1991), “Object-Oriented Modelling and Design”, Prentice-Hall, Inc., Englewood Cliffs, NJ.

[22] Sullivan, L.P., (1986), "Quality Function Deployment", Quality Progress, June, pp 39- 50.

[23] Thirupathi, D, (1998), “Integrated Information Model for Managing the Product Introduction Process”, Ph.D. Thesis, Coventry, U.K.

University of Warwick.

[24] Wallace, K., Bligh, T., (1996), “An Introduction to the Design Process”, Department of Engineering, University of Cambridge, Feb.

[25] Zirger, B.J., Maidique, M.A., (1990), “A Model of New Product Development: An Empirical Test”, Management Science, 36(7), pp. 867-883.