Propagating Engineering Changes To Manufacturing Process Planning Does Plm Meet The Need

1,449 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Propagating Engineering Changes To Manufacturing Process Planning Does Plm Meet The Need

  1. 1. International Conference on Product Lifecycle Management 1 Propagating Engineering Changes to Manufacturing Process Planning: Does PLM meet the need? M.A.EL HANI*, M.Ing., Prof. L.RIVEST*,Ph.D., Prof. C.FORTIN**, Ph.D. * Ecole de technologie superieure, 1100 Notre-Dame West, Montreal (Quebec), Canada, H3C 1K3 mohamed-ali.el-hani.1@ens.etsmtl.ca, louis.rivest@etsmtl.ca ** Ecole Polytechnique de Montreal, 2500, chemin de Polytechnique, Montreal (Quebec), Canada, H3T 1J4 clement.fortin@polymtl.ca Abstract: Manufacturing process planning is mainly based on information coming from engineering, on manufacturing data, and on the know-how of the process planner. When an engineering change is brought to the part, the process planner has to propagate its impact to the manufacturing work instructions (MWI). In spite of the increasing interest in the PLM (Product Lifecycle Management) approach and tools, propagation of engineering changes to the MWI has received very limited support from existing applications. The research presented in this paper builds on a case study conducted within the process planning department of a manufacturing company operating in the aerospace sector. First, the detailed investigation conducted to document the change propagation process from engineering to the MWI is described. Next, an activities model (IDEF0) of the MWI development process is presented. The IDEF0 model contains 201 activities and 120 «informational object-information repository» couples. Lastly, an overview of an information management tool required to support MWI development process is presented. The number of informational objects without any information system as repository and the proposed Dashboard solution confirm the long road ahead for PLM systems in order to meet the real-world needs of propagating engineering changes to the manufacturing process planning. Keywords: information management, manufacturing process planning, product development, process modeling, dashboard, IDEF0, PLM, engineering change, informational object. Introduction PLM is often presented by CIMdata Inc. as "a business approach to solving the problem of managing the complete set of product and plant definition information and the processes through which it passes. The PLM process includes creating and changing that information, managing it through its life and disseminating and using it throughout the lifecycle of the product". From such a definition, we could expect PLM tools to Copyright © 2007 Inderscience Enterprises Ltd.
  2. 2. 2 M.A.EL HANI, L.RIVEST, C.FORTIN efficiently support the work of propagating a change from an element of information that defines a product, to other elements of information that define the Manufacturing Work Instruction (MWI) of this product. Ideally, the process planner would want the following to be true: «Greatly improved knowledge management occurs because all types of product definition information become associatively linked to the manufacturing processes and tooling designs when Digital Manufacturing is used within a broad-based PLM initiative. This preserves, in fact increases, the value of data. The result is that, as the product design changes, process and resource plans can be more quickly and accurately updated». [CIMdata Inc.] However, what is observed in practice differs from this ideal. Managing and propagating an engineering change from the design definition to the process plan remains basically a manual operation. Here, we distinguish Change Management and Change Propagation. «Engineering Change Management (ECM) is an important component of PLM. ECM modules in current PLM solutions conform to the industry-standard CMII closed- loop change model. They provide customised forms and pre-defined work-flows for creating and processing change requests, change orders, etc. » [1]. Engineering Change Propagation differs from ECM. It consists of the action of integrating an engineering change into the impacted pieces of information. Propagating changes between geometrical data are managed and facilitated, to some extent, by CAD systems through constraints previously established between elements of the involved models. In industrial practice, when an engineering change is brought to a part, for example to a tolerance, managing and propagating its impact through the different organizations involved in the product development to the relevant portion of the process plan, tooling, inspection document, etc., is highly complex and basically reliant on human expertise. This paper examines some issues involved in propagating engineering change to the process plan and identifies limitations of current PLM solutions involved in the engineering change propagation process. An in-depth study of the challenge related to engineering change propagation to the manufacturing process plan is presented first. Some results of a case study are described; an IDEF0 model for a manufacturing process planning department is presented, as well as an overview of a proposed dashboard solution. Challenge and approach 2.1 Challenge During the development of complex products such as those found in aeronautics, the Manufacturing Work Instruction (MWI) development constitutes a complex process that uses a significant number of stakeholders, documents, and applications. The task of the manufacturing process planners is initiated from engineering drawings to lead to the MWI. A large portion of this work is based on the process planner’s know-how. The development process of the MWI could be schematized as shown in figure 1, where Fi F’i and Oi are defined as follows. Fi: Feature of the engineering drawing: it can be a dimension, a surface quality, a tolerance, a special treatment, etc.
  3. 3. Propagating Engineering Changes to Manufacturing Process Planning 3 F’i: Feature of the MWI: it can be a dimension, a tolerance, an adjustment, a tooling, etc. Oi: Informational object: it can be a piece of data, a unit of information, a formal or abstract knowledge, a document, a set of documents, an electronic file, etc. By analogy, using Maurino’s [2] description of a technical object, the concept of informational object was introduced within this work to have a common representation of all the product information. Figure 1 Engineering change impact on the MWI development process As figure 1 illustrates, our basic MWI development process model relies on the assumption that the features defined by the Engineering drawings are transformed into MWI features via links that involve some process planning knowledge. One of our global scientific objectives is to identify the various links that exist between the informational objects, understanding their types and formalizing them. The identification of these various links offers a potential for connecting engineering drawings features and MWI features. Conceptually, this model is similar to the situation observed today between the CAD model objects that define the product (as is done, for example, with Catia V5), but expands it to a much wider application domain. If this model was to work, it would offer a means to quickly identify the informational objects impacted by the change when an engineering change impact study is required. This goal is not easy to reach since a great number of these links are based on human know-how. Moreover, the identification of the informational objects involved in the MWI development process requires a great effort since several of them are non-formal. In the case of complex product development, the MWI development process involves a great volume of information and actors, and it is difficult for manufacturing process planners to determine the informational objects impacted by a change. Engineering change impact study is still a difficult task based essentially on experience and knowledge. The case study conducted, in the context of this research work, within the process planning department of a manufacturing company operating in the aerospace sector, confirms that even in the presence of CAD, PDM, MES, ERP and other applications, it remains very difficult for the manufacturing process planner to quickly identify which Copyright © 2007 Inderscience Enterprises Ltd. Sub-process Engineering Drawing (?) F1 F2 F3 F4 Fi F.. Fn M.W.I. F’1 F’2 F’3 F’4 F’i F’.. F’n L1 L3 L2 Oi Zoom ENG. CHG. Impacted by the engineering change
  4. 4. 4 M.A.EL HANI, L.RIVEST, C.FORTIN informational objects of complex MWI documents are impacted by an engineering change and in which way. The lack of an information structure to support the propagation of an engineering change seems to be the principal reason for this problem. This structure of information is composed by informational objects and their links. However, if the granularity of the considered informational objects is established at the feature level, the multiple links that relate an engineering feature to a MWI feature are from being completely documented and formalized. 2.2 Approach An interesting approach to solve the engineering change propagation problem consists in managing the various links between technical objects (Maurino [2]) involved in the MWI development process. Giguère [3] successfully used this approach to propagate changes within geometric models belonging to the engineering domain. Michaud [4] used it to cross the Engineering domain boundary, and propagated changes up to the tooling but considered only the geometrical aspects. In both cases, the approach was used to solve some well circumscribed and formalized problems (a limited number of less complex links were controlled and formalized1 ), but was not generalized. In a general context involving multiple domains, where the level of abstraction is high and the process is more complex, it is difficult to identify all the informational objects involved and their links, as is the case with the MWI development process. In order to help solve this problem, taking as a starting point the principal ideas of the approach based on links management (Michaud [4] and Giguère [3]) and that proposed by Eversheim [5], an approach with two components was proposed within the context of this work. Component A) Documentation of the MWI development processes: This component aims at studying in great detail the MWI development processes and the Engineering-to-MWI change propagation process. This component’s objective is to identify the principal informational objects involved and their links. The links between the informational objects are based on the activities model and methods model co- ordinately with the reference model suggested by Eversheim [5]. The IDEF (Integrated DEFinition) was used to apply this approach, mainly IDEF0 (activities model). Before building the IDEF0 model, two business maps describing the MWI development and the MWI modification processes were elaborated. Component B) Gathering and analysis of business requirements for change impact analysis: This component aims at identifying the business requirements of the manufacturing process planners related to the study of the engineering change impact. Based on interviews, this component also aims at proposing the ideal solution that facilitates the engineering change impact study and its integration. The approach described above was applied and validated with the manufacturing process planning department of an aeronautic company. The results are presented below. 1 The informational objects are known and the task-specific knowledge conveyed by each link is formalized.
  5. 5. Propagating Engineering Changes to Manufacturing Process Planning 5 Case Study 3.1 Manufacturing Process Planning Business Map The MPP map documented in this study describes the work performed by the manufacturing process planning department, or MPP department, and is described with more details in reference [6]. This department’s main task is to prepare and coordinate the development of the process plan folder, named MWI, in accordance with the requirements of the engineering department. The MWI is a folder composed of several operations sheets. This case study focuses on new parts being developed. New parts are developed simultaneously by Engineering and MPP departments in order to allow early detection of potential manufacturing problems and to accelerate the development cycle. These parts are subjected to a great number of changes while being developed, and these changes do impact the MWI [6]. Starting with an engineering drawing in preliminary release, the MPP engineers study, prepare and coordinate the realization of all the documentation required to manufacture a part and to pilot the prototype manufacturing process. Manufacturing process planners also study and manage the integration of the engineering changes to the MWI during the product development cycle. MPP team leaders manage and follow the MWI projects developed by MPP engineers; they contribute their expertise when needed and ensure that established deadlines are respected. The MPP department interacts with representatives of multiple departments involved in the development of the MWI [6]. Two main processes were identified and targeted in this research project. The reference process is used to develop the MWI for a new part. It is the development process used to create an initial version of the MWI; this reference process does not involve any engineering change integration. Due to the important number of tasks and disciplines involved (80 tasks and 14 disciplines), it is clear that even though we conducted an in-depth documentation and analysis, details are omitted here for concision and confidentiality reasons [6]. The engineering change propagation process is used to integrate a change to a MWI being developed. This process describes a change which affects the MWI. There are several types of changes. Engineering changes are the only changes considered here. In a majority of cases, engineering changes are communicated through modifications on the engineering drawings (or, in certain cases, are communicated verbally). It should be noted that the process described applies to new parts development; hence the level of formalism observed differs from the one that would have been observed for production parts [6]. 3.2 Activity model (IDEF0) for manufacturing process planning Based on the abstraction level offered by the two business processes introduced above, it was decided to conduct a more detailed study of the MWI development process in order to build a deeper understanding of the process planners’ information needs. Thus we chose to use IDEF modeling techniques to build an activity (IDEF0) model that would offer a thorough documentation of the manufacturing process planning activity. The model IDEF0 developed describes in a hierarchical way all the tasks done by the Copyright © 2007 Inderscience Enterprises Ltd.
  6. 6. 6 M.A.EL HANI, L.RIVEST, C.FORTIN manufacturing process planner during the MWI development process (the reference process and the change propagation process). The model begins on the level "A0" (Develop the MWI of a part), which is the principal activity (figure 2). Then, this activity is broken up into three activities (figure 3): A1) Elaborate the MWI folder (equivalent to the reference process of the MWI development); A2) Modify the MWI folder (equivalent to the change propagation process of the MWI development); A3) Validate the MWI (to start part production). Due to the IDEF0 model size (201 activities) the activity "A21" describing the engineering change impact study was selected to be described below. This activity was decomposed into two levels and three diagrams are shown below (figures 4, 5 and 6). The IDEF0 model shows that the manufacturing process planner has to take many decisions to propagate engineering change on the MWI. These decisions could be to cancel a request for tooling, which involves notifying a specific stakeholder involved in the MWI development process. Actually, the PLM and workflow solutions offer many capabilities to easily send information, to follow up deliverables and to notify stakeholders but they can’t help manufacturing process planners to take decision in case of propagating engineering change. The lack is essentially due to the fact that a great part of the knowledge and information involved in the MWI development process is still non- captured by PLM systems. 3.3 Analysis Analysis of the business maps reveals that the MPP, which leads to the development of an MWI folder, is a very complex process that heavily relies on the process planner‘s expertise, who needs to act on multiple pieces of information provided by various sources. This complexity, coupled with the vast amount of engineering and manufacturing features involved in MWI development, leads us to consider that capturing the links that associate these features was not within our reach. However, understanding the organization of the activities involved in MWI development, as per the IDEF model, also leads to another important conclusion: due to this complexity, the process planners must have a clear vision of all the ongoing and coming tasks performed by all the actors involved in order to better carry out the change’s impact study. Thus, even without being able to capture and manipulate the links that exist between the involved pieces of information, there is still a need for a solution that offers a centralized vision of all the process planning tasks and deliverables. This target appears as a viable alternative that would still bring improvements to the change impact study and integration to the MWI. The various actors involved in the process have validated this conclusion. A quantitative analysis of the ‘informational objects’ contained in the IDEF0 model demonstrates that a significant part of the informational objects of the MPP is contained on paper (mark-ups on the drawings, check-lists of deliverables, approval sheets, etc.), which leads to conclude that an important portion of the MWI development process is still not covered by a software application. An analysis of the information included on the IDEF0 model revealed that at least 35 % of the ‘informational objects’ manipulated by the manufacturing process planners are not located in PLM software [6]. Hence, the importance of paper, the significant number of software tools, the large number of tasks and actors involved in the MWI development process, are multiple factors that confirm the process planners’ needs towards a solution enabling visibility into the process. The
  7. 7. Propagating Engineering Changes to Manufacturing Process Planning 7 proposed Dashboard is a solution that offers a centralized location for the process planner to retrieve all data relevant to his work [6]. 3.4 Requirements for an information management tool to support manufacturing process planning: Dashboard The business maps as well as the IDEF0 model provided us with an adequate understanding of the process planning process. To further refine our comprehension of the process planners’ needs, and to define the dashboard solution profile, questionnaires and interviews were used to obtain information from all participants of the MWI development process, including the process planners. The anticipated users of the dashboard solution are manufacturing process planners, their team leaders, the engineering department and the actors participating in the MWI development process. On top of the needs expressed by the users, and after documenting the manufacturing process planning work as well as its software environment, we added other requirements to the dashboard specifications regarding the traceability of a MWI development project. Generally, a dashboard solution is defined as a user interface that filters, organizes and presents information in a way that is easy to read. It can be considered too, as a small, defined set of key metrics used to provide a quick evaluation of a project or process status. In our case, the dashboard solution is exceeds this basic definition. In addition of capturing and centralizing information coming from different systems (CAD, ERP, MES…), it allows manufacturing process planners to access those systems from a unique interface. The main interface of the dashboard solution is divided in five areas: • Project identification: it includes basic information about the project and the list of resources involved in the MWI development process. Figure 2 A-0 diagram: Develop the MWI of a part (context) Copyright © 2007 Inderscience Enterprises Ltd.
  8. 8. 8 M.A.EL HANI, L.RIVEST, C.FORTIN Figure 3 A-0 diagram: Develop the MWI of a part Figure 4 A21 Diagram: Study the engineering change impact and notify stakeholders (context)
  9. 9. Propagating Engineering Changes to Manufacturing Process Planning 9 Figure 5 A21 Diagram: Study the engineering change impact and notify the stakeholders Figure 6 A211 Diagram: Study the engineering change impact on the project deliverables Copyright © 2007 Inderscience Enterprises Ltd.
  10. 10. 10 M.A.EL HANI, L.RIVEST, C.FORTIN • Manufacturing process planner’s deliverables list and status. • Manufacturing process planner’s tasks list: it contains a list of the main tasks to be performed by the process planner and is linked to the status of the deliverables. When a deliverable is released, the associated task is displayed as completed. • Project deliverables overview: For each actor involved in the MWI development process, it gives an overview of his deliverables status. It also allows the manufacturing process planners to dig through them using direct links to others systems (CAD, ERP, MES, …). • Communication window: it allows the manufacturing process planners to chat with the different actors involved in a project. Moreover, it captures all the communications related to a specific project. The dashboard solution requirements are illustrated in [6], it provides a global idea of the proposed interface and functionalities. It will be used as a guide for a future development of the solution or for the acquisition of an off-the shelf solution. Conclusion From a scientific point of view, the maps and the IDEF0 model enabled us to make an inventory of the informational objects involved in the MWI development process. This allows us to progress towards the control of change propagation, by the identification of these informational objects as well as some associations between them. The maps and the IDEF0 model also made it possible to document, in detail, the activities of manufacturing process planning to improve the understanding of the study of a change impact; such a study often relies on the process planners' expertise. Although many editors of PLM software promise to offer a global canvas of the product development domain, a long journey remains ahead by the PLM systems. The study presented in this paper confirms that there is a major area of the product development process that requires more attention in order to achieve the PLM goals; it is the manufacturing process planning for complex products. References 1 Nlkhil, Farhad & Debasish (2005) ‘Systematic decision support for engineering change management in PLM’, Proc. of the ASME, DETC2005: 25th Computers and Information in Engineering Conf., p 827-838. 2 M.Maurino (1993) La gestion des données techniques, Masson, Paris, ISBN: 2-225-84518-2. 3 F.Giguère (2002) ’Application des liens multi-modèles à la conception mécanique’, Master thesis, Sherbrooke University, Quebec, Canada. 4 M.Michaud (2004) ‘Méthodologie de modélisation unifiée pièce-outillage en CAO aéronautique : Application aux tôles et gabarits de découpe’, Master thesis, École de technologie supérieure, Quebec, Canada, N. 18279412. 5 Eversheim, W.; Bochtler, W.; Graessler, R.; Koelscheid, W. (1997) ‘Simultaneous engineering approach to an integrated design and process planning’, European Journal of Operational Research, v 100, n 2, Jul 16, p 327-337. 6 M.A.El Hani, L.Rivest, C.Fortin (2006) ‘On specifying an information management tool to support manufacturing process planning in aerospace: A case study’, Proc. of the ASME, 26th Computers and Information in Engineering Conf., 2006, DETC2006-99231.

×