A process model for the design analysis clarification task

http://www.diva-portal.org This is the published version of a paper presented at 9th International NordDesign Conference NordDesign 2012, Aalborg, Denmark, August 22-24, 2012. Citation for the original published paper: Petersson, H., Eriksson, M., Motte, D., Bjärnemo, R. (2012) A process model for the design analysis clarification task. In: Kyvsgaard Hansen, P.; Rasmussen, J.; Jörgensen, K.; Tollestrup, C. (ed.), Proceedings of 9th NordDesign Conference (pp. 494-501). Aalborg & Glasgow: Aalborg University & University of Strathclyde N.B. When citing this work, cite the original published paper. Permanent link to this version: http://urn.kb.se/resolve?urn=urn:nbn:se:hh:diva-19608 NordDesign 2012 August 22 – 24, 2012 Aalborg, Denmark A process model for the design analysis clarification task Håkan Petersson School of Business and Engineering Halmstad University P.O. Box 823, SE-301 18 HALMSTAD SWEDEN [email protected] Martin Eriksson Damien Motte Robert Bjärnemo Division of Machine Design, Department of Design Sciences, LTH, Lund University P.O. Box 118, SE-221 00 LUND SWEDEN [email protected] [email protected] [email protected] Abstract Many product development projects nowadays use computer-aided engineering systems in the analysis of product proposals. It is therefore important to appropriately integrate the analyses activities in the product development process. One important aspect of this integration is how to handle the initiation of the task: identifying the need, planning the task and its monitoring, and communicating it to the analyst. To that end, this paper proposes and illustrates a product development process model that aims to efficiently and effectively prepare a design analysis task. Keywords: design analysis, specifications, requirements, product development. 1. Introduction In the large majority of product development projects, computer-based design analyses of the product-to-be and its components are performed to assess the feasibility of potential solutions. Often, the analysis activity is performed by a specialist, employed by either the company or a consulting agency. Several iterations usually take place: the engineering designer submits a concept proposal to the analyst and uses the results to correct and improve the concept, which in turn becomes the object of new analyses. The number of iterations can be quite large for high-technological products. For example, in Haldex, a Swedish company specialized in brake products and brake components for heavy trucks, trailers and buses, the largest part of the disc brake, the caliper, can undergo 70-100 iterations between various departments, most of them between the design analysis department and the design department [1]. Since the analysts and designers work with, and are responsible for different areas, they do not necessarily have full insight into each other’s work. This can lead to misunderstandings, delays and even worse, less robust and efficient designs. It is thus important to appropriately integrate the analysis activities into the product development process to obtain a significant decrease in lead time and increased effectiveness in the development process. Effective integration can be tackled in different ways. King et al. [2] have presented a framework (or ‘good practice model’) for the implementation of FEA and related computer-aided engineering (CAE) into the product development process. They state that an effective integration is dependent upon: 1) the organization of the product development process, 2) software, 3) hardware, 4) support structures for effective use of CAE in the product development process, 5) product data management. At the organizational level, one particularly important aspect of this integration is how to handle the initiation of the task: identifying the need, planning the task and its monitoring, and communicating it to relevant parties in the project. Indeed, many elements need to be taken into account and the design specifications need to be accurately transferred into analysis requirements. With the right information about the analysis objectives and requirements, the number of iterations between synthesis and analysis can be decreased significantly. Likewise, a formalized process can avoid possible shortcomings at that stage, and lead to more effective product development activity. This integration aspect of the analysis task into product development has neither been prioritized in the Finite-Element Analysis (FEA) community nor in the engineering design literature. The former have mainly focused on the analysis task itself (see e.g. [3; 4]), in which the implementation of and managing of the FEA technology in enterprises is discussed with the purpose of providing means for supervising and increasing its effectiveness. The engineering design literature focuses mainly on synthesis aspect of the design activity, not on analysis (see e.g. [5; 6]). The purpose of this paper is therefore to propose a process model that aims at efficiently and effectively preparing a design analysis task in a product development project. The methodology used to establish the design analysis task clarification process model (hereafter called ‘process model’ for short) is presented next. Section 3 presents the context of the design analysis activity, illuminating its specificities and the elements that must be taken into account in the process model. Section 4 presents the model and Section 5 an illustration of it. 2. Methodology The elements that constitute the process model have been derived from different sources. Some elements have been extracted in part from a series of interviews with Swedish manufacturing and consulting companies, where best practices could be observed. The results of this survey will be published elsewhere. Although the literature on engineering design and analysis scarcely addresses the integration issue as a whole as already mentioned, several disparate elements and recommendations could be incorporated in the process model. Finally, several authors of this paper have long experience in FEA, both from industry and academia. 3. The context of design analysis 3.1. Concept of analysis in the scope of the paper Analysis can take a multitude of forms, from verifying some properties according to a defined standard, to hand calculations, to very advanced computer-based analyses. In the scope of this paper, the term ‘design analysis’ only covers quantitative analysis activities requiring the use of advanced CAE design analysis tools. Moreover, this paper mainly concerns cases where the analysis is turned over to and performed by an analyst in the design analysis department of the company or by a consulting firm, although we think that the proposed process model can advantageously be used independently of the person who performs the analysis. The main objectives of design analysis in the current context are: - To assess feasibility studies and requirement quantification supporting identification and preparation activities - To carry out explorative investigations supporting the synthesis activities - To evaluate product characteristics during given product life cycle conditions - To elaborate methods for verification and validation of the analyses performed 3.2. Design analysis activities in the product development process Design analysis can be utilized throughout the entire product development process. Traditionally, the engineering design process in product development is divided into conceptual design, embodiment design and detail design or similar phases (e.g. [5; 6]). The conceptual design phase deals more with a search for suitable solutions, the embodiment design and detail design phases deal more with refinement of the chosen concept. Thus, different design analysis methods and tools are used during the different phases and with different levels of detail in the analysis. For example, during conceptual design the analysis can be coupled with topology optimization, while in the later phases the focus may be on sensitivity analysis / robust design. An illustration of the use of CAE analysis during the whole product development can be found in [7], where the full potential and usefulness of design analyses is illustrated. Nevertheless, the form of the analysis process follows some general steps of: - Initiation / task clarification - Pre-processing - Execution of analysis task and tracking of progress - Post processing and interpretation of established results - Communication of established conclusions and recommendations Moreover, regarding more specifically the clarification step, the same issues are present whatever the level of advance of the product development project. They are discussed in the next section and section 4. 3.3. Specific issues for the design analysis clarification task Several issues arise when a design analysis activity is initiated. They can be project-related, enterprise-related, or design analysis-related, as illustrated below. Project-related aspects. In most high-technology projects, analysis has an important place in the project by providing the team with efficient tools and means, if utilized properly, to analyze and evaluate the given requirements. However, if not properly planned and executed, an analysis can result in high cost, delays in deliveries and even worse, in false conclusions regarding the requirements studied. General requirements are also subject to changes during the analysis process. When the task is turned over from the engineering designer to the analyst, the latter has less knowledge about the concept to be analyzed, and needs a clear description of the problem and what he or she is expected to investigate. Reciprocally, the analysis of results must be communicated in a way that is understandable to the engineering designer and other project stakeholders. It is necessary to have the proper specifications from the beginning to provide the best possible assumptions for success of the planned analysis activities. Other stakeholders (production, purchase, other analysts) may be waiting for the results to make another type of assessment in the project; this requires careful planning. Enterprise-related aspects. The company may also have some limitations in terms of human resources, hardware, software and expert knowledge; they may require some specific standards and methods to be followed. In most industrial product development projects, traceability of the results is required (this is compulsory for any ISO certified company). Analysis-related aspects. There are many different analysis methods relevant and applicable to the same kind of problem that, however, give results with different confidence levels. This is also more or less time and resource consuming. Thus, it is important for the analyst to have adequate information presented in an organized manner before initiating any analysis activities. A process model taking into account these issues should facilitate the analysis task initiation, execution and reporting. 4. Process model for the design analysis clarification task 4.1. Overall process model The following steps have been adopted for the design analysis clarification task: - Identification of the task: the different stakeholders discuss the relevance of the task - Preparation of the task content brief - Planning and agreement on the brief This process is presented in Figure 1. Although the core of the clarification task is the second step, the first and third steps are very important in the chosen context of advanced design analysis tasks that are not performed by the engineering designer. If neglected, they can lead to misunderstandings, false conclusions and delays that all have a large impact on the overall project success. Figure 1. The design analysis clarification task process 4.2. Identification of an analysis task There are several possible origins to the initiation of the task, as described Figure 1. The design analysis clarification task is tackled slightly differently depending on whether it is planned or unplanned. In large projects, whatever the outcome of the concept searches, it is known in advance that the proposals will be analyzed and what type of analysis should be performed. For instance, in [8], the implementation and use of a design analysis system for high-cycle fatigue analysis was possible in the early design stages of turbo machinery blade design. In planned cases, discussions take place between the different stakeholders, which consist mainly of the project leader, the engineering design department, and analysis department or consulting firm – given that the consulting firm has already been chosen. A pre-analysis assessment is often performed to decide on what software and hardware should be used, expected input, output, other resources, duration. A preliminary mission statement is written on which the relevance of the task is emphasized. The task can also be unplanned: project team members identify the need for a more in depth analysis of some aspects of the product-to-be. In this case, it is also important to go through this step, although less thoroughly, to assess the relevance of the task and to get approval from the project leader. 4.3. Preparation of the task content brief. Once the relevance of the task has been agreed upon, the analysis task brief is devised. Different parts are written by different stakeholders, including the analysts. The vital content of the task brief is listed in Figure 1. The list can be expanded with aspects related to the specific enterprise, project or product aspects relevant for the particular development situation. The author(s) of the brief must be aware of the following points. - The analyst may have little overview of the project as a whole and an overall description of the project is necessary for an improved holistic view of the task at hand. - The analyst needs to know not only the goal(s) of the analysis (e.g. structural analysis), but how the data will be used (verification, further improvement, etc.). For example, the designer may want the analyst to make a fatigue analysis of a component. If the results are not satisfactory, the analyst may offer suggestions on design improvement – but this needs to be stated in advance (in planning the analysis task): the task may be undertaken differently if the analysis results are to be used for further design of the component or as a basis for material selection of this component. - Requirements: one goal of the design analysis activity is to determine whether the product specifications are fulfilled. These specifications generally need to be further elaborated and divided into systems, sub-systems and components specifications that are to be satisfied. The engineering designer may not be aware of all that needs to be investigated at the analysis level, and therefore the analyst also has to be involved in writing the requirements. - Analysis methods: In sensitive areas, such as the automotive, aeronautical or defense industries, certain analysis methods are dictated by the company, by standards, regulations or by specific organizations. The analyst needs to know if specific methods should be used, and if a specific organization (or third party) will be verifying the analysis and results. Analyses in the offshore industry are often quality checked by a third party independent evaluation by, for example, Det Norske Veritas (DNV) or Lloyd. - The deliverables must also be specified. They can be in the form of data but the engineering designer may also want to have a more elaborated interpretation and conclusion. - In the brief, it is important to establish the modalities of task monitoring, results communication and follow-up of the task activity. - Beyond the brief, it is necessary to prepare miscellaneous documentation as well as product-related data and the form in which this data should be. 4.3.1. More on the role of the task content brief The analyst’s role is not to be neglected during task content brief. The analyst possesses important knowledge that the designer / project leader does not. This means that in general, the brief will not be complete or will be incorrect unless the analysts are given the opportunity to comment on the brief. As in any project [9], the brief needs to be questioned by the analyst, and the project workers need to be open for discussion. This inquiry of the brief should at least consist of the following questions: - Origin of the brief (Who?) - Goal of the task (Why?) - Environment of the brief - Designers’ knowledge about analysis - Tasks (What? i.e. are any other tasks necessary?) - How is the analysis to be performed (i.e. if the analysis method is stipulated, if the company has a determined protocol, etc.)? 4.4. Planning and agreement of the task. This is an important step in the process model to reach a mutual understanding and agreement of the task ahead. It should consist of detailed planning of the analysis task brief that has been established. Often it is a negotiation between the various stakeholders due to the simple fact that enterprise and project constraints in terms of resources, knowledge and time frames all effect what is possible to achieve in the assessment of the requirements under evaluation. The requirements are often categorized as wishes or demands. However, in the case of demands, it is necessary to discuss whether these are absolute or not. For instance, if a structural component is only allowed to locally experience plasticity, then the term ‘locally’ needs to be further elaborated to explain how it should actually be interpreted as with the selected choice of resources, software and level of detail in the current analysis. Sometimes during negotiations, it is possible to give an interval instead of a specific number of a requirement if that is agreed to be more efficient and if it would still give relevant information at that point in the project. Once all items in the brief are planned, a contract or formal documentation should be prepared and mutually agreed on that forms the basis for the analysis execution. 4.5. Analysis execution The execution of the analysis is not considered here. However, it is very important not to execute it without a proper description and agreed monitoring activities, intermediate milestones or checkpoints. 4.6. Communication of the results and interpretation It is often only at this point, if not planned and monitored correctly, that the recipient of the results notices that the analysis did not answer all his or her questions, or brings up new questions that it was not designed to answer. Although it is impossible to predict everything in the clarification stage, it is extremely important to at least think of the possibility of these aspects at this point. Similarly, it is important to plan how the analysis activities will be followed up and communicated to the other stakeholders after completion. 5. Illustration The process model is illustrated in this section. In the frame of an industrial project, a computer-based design and analysis system for grippers had to be developed for production engineers with little knowledge in synthesis or analysis. The grippers, attached to a robot arm, grip the sheet metal part of the product, transport it and fix it to a main frame where it can be welded to the other sheet metal parts. When placed in the main frame, the robot is disconnected and the gripper is attached to the main frame by using the 4-6 locks on the gripper’s outside, depending on the size of the sheet metal. See Figure 2 for an illustration of the procedure. The system needed to take several aspects into account and therefore the different elements of the process model presented above needed to be considered carefully before developing an adequate system. Figure 2. Illustration of the sequence of handling gripper operations Step 1. Identification of the analysis task One difficulty was to properly automate the analysis tasks, as it was necessary: 1) to be able to handle different types of analyses, 2) for production engineers with little knowledge in synthesis or analysis to use the system. Step 2. Preparation of the analysis task content brief Objectives: The objectives of the analysis task were multipurpose with both the analysis of possible solution concepts followed by optimization. Requirements: The study of the problem resulted in the following requirements: lightweight, low deformation and high tolerance. The tolerance is x mm (company proprietary information) when the gripper is attached to the main frame and the piece of sheet metal is in place for welding. There are different tolerances in the case where the gripper is attached to the main frame and the sheet metal is in place for welding, and in the case where the sheet metal is carried by the robot connected to the center of the gripper. When placed in the main frame, the robot is disconnected and the gripper is attached to the main frame by using the locks. As the gripper is built up of several different parts, it is vital that tolerances are decomposed to all parts as sub-requirements. The grippers are optimized for lightweight under the constraints of low deformation and optimized for each gripper part. Stresses are very low so fatigue is not a requirement to check. Resources, time: The time and resources needed for each analysis were not important factors for this particular project. Decisions about follow-up, traceability: As we are using design analysis as a concept evaluation, it is not necessary to write reports on each analysis. We are able to get automatically generated reports from the software template, the analysis and from the optimization. Documents are saved in .html and .xls formats. This also gives us traceability as to whether or not optimization has ‘missed’ a better solution. The analysis is followed up by an analyst verifying both the analysis methodology and the analysis results. Standards: The analysis needs to follow the companies’ standards for methods, calculation model, welding points, materials and reference points. Confidence level: Because the users of the systems have limited knowledge about CAE and analysis, it is necessary to have a high confidence level in the results. Furthermore, the utilized design analysis system needs to be constructed so that it provides the high confidence level within its given parametric design value. An analyst has to make the final decisions regarding acceptance of the model, and for that has a checklist to follow. Type and communication of the results: All results can be saved inside the CAD software but it is important that people without CAD experience are able to verify the results. Reports and results have to be saved in a format accessible to other stakeholders in the company. The results and knowledge gained during the execution of the tasks need to be communicated to the project team by appropriate means. Step 3. Planning and agreement of the analysis task In this particular case, the analyst was performed in step 2; thus, it was the people concerned with the systems who needed to be critical of the design brief. The two grippers generated and optimized by the computer-based design and analysis system are presented Figure 3. To be able to check the established models as well as the results, there are many quality controls available, for example, mesh quality and the estimated local error on the meshed model. As for the geometry, there is an automatic optimization were it is possible to change the cross section of the beams, change the dimensions and thickness of the tubes. Figure 3 shows a gripper with two different cross sections, round and rectangular. Figure 3. Two grippers generated and optimized by the computer-based design and analysis system 6. Conclusion and future research This paper has proposed a process model for the design analysis clarification task. It is essential that the analysis task is appropriately integrated into the product development process in order to gain efficiency and effectiveness. One of the important points of this model is that the analyst must be completely integrated into this stage. Although the presented process model needs to be tested and developed further, the illustration highlights that it can serve as a basis not only for a single analysis but also as a foundation for the development of a complete design and analysis system. The analysis task itself has not been touched upon. It is also possible here to develop guidelines for the analysis depending on the design stage (conceptual design, embodiment design or detail design). This is currently being developed. 7. References [1] Hofvendahl M. and Nilsson P., "Analysis and Improvement of Haldex Brakes' Innovation Processes", Master Thesis, Division of Machine Design, Department of Design Sciences LTH, Lund University, Lund, 2012. [2] King G.S., Jones R.P. and Simner D., "A good practice model for implementation of computeraided engineering analysis in product development", Journal of Engineering Design, Vol. 14, 2003, pp. 315-331. [3] Baguley D., Hose D.R. and NAFEMS, "How to Plan a Finite Element Analysis", NAFEMS, 1994. [4] Adams V., "How to Manage Finite Element Analysis in the Design Process", NAFEMS, 2006. [5] Pahl G., Beitz W., Feldhusen J. and Grote K.-H., "Engineering Design – A Systematic Approach", 3rd Edition, Springer, 2007. [6] Ulrich K.T. and Eppinger S.D., "Product Design and Development", 5th Edition, McGraw-Hill, 2012. [7] Eriksson M. and Burman Å., "Improving the design process by integrating design analysis", 15th International Conference on Engineering Design - ICED'05, DS 35, Melbourne, 2005. [8] Mårtensson H., Forsman J. and Eriksson M., "Simplified forced response HCF assessment of turbomachinery blades", Proceedings of ASME Turbo Expo 2009: Power for Land, Sea and Air GT2009, Orlando, FL, 2009. [9] Yannou B. and Zimmer B., "Design and Innovation of Products and Services (In French. Original title: "Conception et innovation de produits et services")", École Centrale Paris, 2011.