A Guideline to Facilitate the Implementation of Collaborative Mdo in Conceptual Analysis of a Complex Product

doi:10.21203/rs.3.rs-3248170/v1

Download PDF

Research Article

A Guideline to Facilitate the Implementation of Collaborative Mdo in Conceptual Analysis of a Complex Product

https://doi.org/10.21203/rs.3.rs-3248170/v1

This work is licensed under a CC BY 4.0 License

Version 1

posted

You are reading this latest preprint version

This study provides a method to construct a collaborative multidisciplinary design optimization (CMDO) framework to be used in conceptual analysis of a complex engineering product. As its named implies, the CMDO framework, should be developed through the joint efforts of a team. Both technical and collaborative aspects should therefore be taken into account to provide a generic guideline.

The proposed guideline to facilitate CMDO implementation in conceptual design is based on information gathered from a course project that included 40 students at Linköping University. An exploratory approach is used to clarify the technical/collaboration challenges, including questionnaires and extensive interviews with students.

The guideline has been established to handle the challenges and difficulties of MDO implementation. It provides a handbook (step-by-step) approach to realize a CMDO framework in conceptual design. Preliminary results include an ontology to enable the use of CMDO, the collaboration strategy and a generic guideline.

Multidisciplinary design optimization (MDO) is currently an appropriate approach to optimize complex products involving many disciplines. Designing a new complex product requires additional resources, novel models and design process and an approach to manage the associated complexities. In order to manage these efficiently, the design process needs to be updated with regard to the new requirements. Reduction in time and cost of the design are two examples of such requirements that can be achieved by optimizing the concepts before detail analysis and production planning. Obtaining more information, e.g., by employing higher fidelity models, early in conceptual design phases can lead to more mature concepts. The trend in conceptual analysis in industry is therefore towards employing higher fidelity models. The Boeing 787 aircraft is a suitable example that benefits from using high fidelity analysis, e.g., CFD and FE analysis, in the conceptual design process (Agte et al., 2009), (Hwang et al., 2014) and (Girsing et al., 1998).

Integrating higher fidelity models in conceptual design requires new resources, e.g. domain experts who are the ones who develop the models. Collaborative design therefore seems an appropriate method to integrate domain experts into conceptual analysis. On the other hand, higher fidelity models are complex and typically include many design parameters. An MDO framework is therefore required to manage the complexity of dealing with a number of design parameters. Grouping the collaborative design and MDO leads to the introduction of a collaborative multidisciplinary design optimization (CMDO) framework to optimize such complex products through the joint efforts of several engineers. CMDO in this work is positioned at the intersection between the multidisciplinary design and design optimization, where they are carried out collaboratively in the conceptual design phase, see Fig. 1.

1.1 Motivation

Although MDO has been undergoing development for many years in research studies and industrial application, its industrial implementation is still very limited. MDO is a complex process that includes many tasks, processes, and data sources that interact both directly and indirectly (Sobieszczanski-Sobieski et al., 2015). The MDO implementation thus seems rather hard and sometimes impossible due to the lack of a structured way to manage the complexity. In addition to technical challenges in the implementation of MDO, e.g., mathematical formulation, model development and integration, there are still some non-technical barriers to MDO such as required organization, engineers and MDO knowledge, data and data management (Belie, 2002). Belie (2002) also mentions that engineers’ confidence in using MDO and trusting its results to modify the product is vital to expanding MDO implementation in industry. Managing the complexity of MDO requires an expert team to understand and solve the technical and non-technical problems of implementation. Forming a design team that includes various domain experts is key to successfully implementing MDO in industry (Sobieszczanski-Sobieski et al., 2015). Agte et al. (2009) summarize the results of an MDO symposium with seventy professionals in the field from academia, industry and the public sector. They conclude that the barriers to successful implementation of MDO in industry consist of technical, organizational, cultural, and educational barriers. Simpson and Martins (2011) present the opinions of MDO experts about non-technical barriers to MDO reported from a national science foundation workshop in 2011. Surprisingly, the obstacles mentioned intersect with the MDO barriers identified many years ago by Giesing, J. and Barthelemy (1998) and Agte et al. (2009). They also state that the MDO implementation suffers from a lack of engineers in industry who understand the concepts and methods and believe in the results. People who can contribute to develop MDO frameworks, increase the fidelity of analysis and use the results in product development. This is considered the main barrier to successful implementation of MDO in industry, alongside other obstacles such as modelling and design space, metrics, objectives and requirements, coupling in complex engineering systems and dealing with uncertainties.

Training engineers could help solve the barriers listed. However, Maurice and La Rocca (2015) believe that direct MDO education for engineers in industry would be difficult, time-consuming and therefore infeasible. They suggest that a learning by doing approach is a practical way for engineers in industry to not just improve their theoretical MDO knowledge but also experience the implementation challenges within their organizations with respect to technical and organizational barriers.

An MDO guideline is one of the most appropriate solutions to facilitate the process of learning by doing. It can be followed by non-MDO experts in industry to easily develop the required MDO framework. To the authors’ knowledge, there are currently few guidelines for MDO implementation and unfortunately no handbook on MDO. The MDO advisory system (guideline) suggested by Maurice and La Rocca (2012) is one of the examples that are very dependent on direct use of knowledge-based engineering (KBE) in the process. On one hand, however, KBE makes the implementation process more complex and on the other hand many MDO implementations are carried out without using KBE. Sobieszczanski-Sobieski et al. (2015) try to separate the MDO and KBE and propose a guideline but the solution is still vague and not easy to follow, which makes it impractical.

This paper outlines a guideline for engineers with limited prior MDO knowledge to develop their own MDO framework. The guideline is proposed based on conclusions from several students’ feedback on MDO challenges and barriers that they faced during a course called CMDO at Linköping University and which has been taught over a period of three years.

1.2 Scope of the paper

The focus of the paper is on the student survey, where challenges and shortcomings in the method proposed by Safavi et al. (2016) to students to facilitate the implementation of MDO within their projects are listed and will be addressed in the proposed guideline. This information is generated from a Master-level course at Linköping University. The students are teamed as MDO practitioners to develop an MDO framework to solve a specific problem.

This work concentrates on collaborative MDO, where tasks are performed through the joint efforts of various roles, namely conceptual design expert, domain expert, interface expert and optimization expert. They are briefly defined as:

Conceptual engineer (CE): can decide about the features of a new concept in order to fulfil costumer requirements and preferences.
Domain expert (DE): is a domain specialist who can develop or modify the disciplinary models.
Interface experts (IE): have experience from various disciplines within the company and have worked on both higher and lower hierarchy levels.
Optimization expert (OE): is able to formulate the problem, set up the framework, run the optimization, and analyse the results.

The first task is therefore to form the group and assign the roles. The person responsible for each task should manage the team for the tasks to be performed effectively. Figure 2 shows the guideline presented by Safavi et al. (2016), which was delivered to the team members during the course. The group should then follow the guideline to develop an MDO framework. As illustrated in Fig. 2, the guideline has 3 main elements: design process including MDO tasks, collaboration required to perform the tasks, responsibility for each task to deliver the outcome. For more information regarding the guideline, see (Safavi et al., 2014) and (Safavi et al.,2016).

Information gathered from both technical implementation and collaborative challenges is considered in order to modify and detail the guideline. This information is used to propose a more generic MDO guideline for ease of implementation in industry. Although the students’ application seems considerably different from the industrial applications, the work processes and individuals’ expertise can be correlated to a large extent. This will be discussed extensively in the discussion section. On the other hand, the work is faced with many limitations and assumptions that need to be clearly indicated to increase the functionality of the proposed guideline in industry.

The projects concentrate on multi-objective and multidisciplinary problems where multiple and conflicting objectives are achieved from interaction of multiple disciplines. The result is therefore a compromise between the solutions.

The presented academic project has the following general specifications:

Focus on complex products
Focus on conceptual analysis
Work as a team (5-6 members in each team)
MDO in a closed collaborative environment (engineers can meet and discuss often and unlimitedly)

This research is classified as exploratory research with the aim of investigating the following research topics:

Explore the collaborative and technical challenges of a CMDO implementation
Produce a more generic CMDO guideline to be used by engineering teams.

This research is intended to tackle new problems that may be faced during implementation of MDO and that have not been explored clearly in previous research. It is also worth highlighting the fact that this research does not aim to deliver the final and conclusive answer to all challenges regarding technical implementation of a CMDO framework but it could be used as an initiative to form the basis of more conclusive research to explore the topics.

As illustrated in Fig. 3, the research starts by providing a preliminary guideline proposed by Safavi et al. (2016) to the team members, who are to investigate the pros and cons of the guideline by using it in the various technical projects. The team members’ individual feedback is collected by means of observation of each team’s performance, a questionnaire and semi-structured interviews. The results of the interviews are then restructured in order to facilitate the process of drawing general conclusions. The result of this study is thus an improved generic guideline.

2.1 Gathering information

The information used in this study was gathered with the help of a survey from the students participating in a course project designed for one academic quarter (8 weeks) to obtain 6 credit points in the European Credit Transfer System (ECTS). This means that each student spends approximately 160 hours in the course sessions that include lectures, lab work and seminars. The learning method used on the course is classified as experiential learning and problem-based learning (Kolb, 1984) and (Edström & Kolmos, 2014). This basically means that the students spend more than 80% of their time in the lab to follow the provided tutorials and work on their projects. The students are in their last semester of their master program (considered soon to graduate as engineers) from two different fields of engineering: mechanical engineering and design and product development. They work in groups of 5 to 6. The projects are chosen by the groups based on their interest and expertise.

This study is based on a survey that includes a questionnaire and semi-structured in-depth interviews with students to collect their feedback. The information is classified into two groups, namely collaborative design implementation and CMDO technical implementation. The questionnaire is designed primarily to clarify the collaboration required during different phases of the design process (for more information, please see Appendix I):

Product understanding and objective identification.
Definition of roles and responsibilities and the technical tasks to perform
Development of the models, integration and optimization
Obtaining of results, interpretation and documentation

As illustrated in Fig. 4, two questionnaires are presented to the students during the course in order to benchmark the students’ feedback before and after the course. The first questionnaire is presented to students personally before they join their groups and begin the actual collaborative design. This is intended to clarify how the students are to collaborate. The second questionnaire is presented during the last week of the course, when the project has been completed, to clarify the required collaboration in practice. This shows how the students have collaborated in reality with respect to the nature of multidisciplinary design optimization.

Semi-structured interviews with students help give insight into students’ difficulties and challenges and the technical details of the CMDO implementation in their project. The questions are of both qualitative and quantitative character. Because of the exploratory orientation of the study, most questions are open-ended. The questions are grouped into five categories:

General MDO understanding
Team formation and collaboration
MDO set-up, model development and integration
Optimization and efficient computing
Illustration of the results and post-processing and documentation

2.2 Collaboration design

The collaborative design concept is used as a foundation to develop a CMDO framework. Pisano & Verganti (2008) present a novel classification of collaboration. This classification helps the students understand which method is most suitable to maximize the benefit of collaboration with respect to the objectives. Based on this theory, collaboration is classified into four groups, namely open, closed, flat, and hierarchical.

Open collaboration means that taking part in the collaborative work is open to everyone. In contrast, closed collaboration presents a situation where participants are chosen by a group leader and the subject area is well-defined. Flat collaboration is defined as when all the collaborators contribute to solve the challenges equally and make decisions together. In hierarchical collaboration however, participants can have their own objectives but do not take any role in decision-making and decisions are made higher in the organization’s hierarchy.

As illustrated in Fig. 7, there are four hybrid areas:

Flat-Open: anyone can contribute to the development and decision-making processes
Flat-Closed: organization chooses the participants but they take a role in decision-making
Open-Hierarchical: anyone can contribute to the development process but final decisions are made by organization
Closed-Hierarchical: both choosing participants and decision-making are done by organization

The above method is used to create the questionnaires explained in Section 2.1. The selected method and structure of the questionnaire have been adapted from research conducted by Salonen E. T. (2016) regarding design collaboration. In this research, the collaborative design study contains four elements: discovering the problem, defining the solution, developing the analysis, and delivering the result. These elements are used as the basis for this study. The questions are therefore designed to evaluate each element with respect to the collaboration theories explained above. The elements are then evaluated and placed in 4 hybrid areas (see figure. 5).

Each of the groups in the course uses a different case study (application project) in order to increase the generality of the proposed guideline. The projects are proposed by students with respect to the general course requirements defined by the course teachers. The cases should fulfil the following general requirements:

It should target a complex and multidisciplinary problem with at least two disciplines
The problems should have multiple objectives and multiple constraints
Students should work in groups consisting of at least four members
The project should be CAD-based (CAD-centric), where the CAD model is a master model that should communicate with other CAE tools.

The case study has certain constraints and limitations as it is performed in the context of a student course, which needs to be considered when outlining the guideline in the result chapter:

Only commercial software is used by the teams
A commercial optimization tool named modeFRONTIER is used as an integrator platform for all projects, so the MDO implementation is limited to the capabilities of modeFRONTIER such as the optimization algorithm, meta-modelling techniques, etc.
CAD plays a central role in all projects; CAD expert is therefore an essential role in each group.
The duration of the course is 8 weeks; all groups therefore have limited implementation time. This forces the groups to modify the process, e.g. by sacrificing accuracy with respect to the time available for the project.
Meta-models are used to replace heavy computational models. This helps speed up the process and also facilitates the model integration process.
Model validation and uncertainty analyses are not considered in this study.

If one considers the limitations listed above, it is clear that they originate from the course setting where this study was conducted. For a small engineering enterprise that is new to MDO, however, the limitations are also very relevant and outline how the first MDO studies at a company ought to be performed, i.e. start by using commercial software, let the CAD model be at the centre, begin with a partial problem that can be solved within a defined time span, and keep the computational time low by using meta-models.

As mentioned earlier, the course is designed to explore the technical challenges of MDO implementation integrating multiple disciplines. Therefore, the disciplinary challenges of how to create the models are not the focus in this study. Developing a model to be used in an MDO framework, however, requires special techniques, e.g. parametric design, that need to be explored and considered by members throughout the project. Figure 6 shows the common platforms of students' projects. As the figure shows, geometry (CAD) plays a central role in all projects. CAD feeds the other models directly by providing either the geometry, e.g. for CFD or FEM analysis, or mass properties for dynamic simulation. Geometry information can also be used directly in optimization of, for example, the weight of the product. Some of the CAE tools, e.g. ANSYS [Ansys, 2016] for CFD analysis, can use geometry directly in their calculation. However, integrating CAD with other CAE tools requires a direct interface between the tools, which is lacking in many design tools, e.g. between CATIA and ANSYS. An intermediate tool is therefore used to facilitate the work; CADNEXUS Capri [CADNexus Capri, 2016], for example, plays an integrator role between CATIA and ANSYS.

The project applications vary widely; from a model aircraft, a submarine, and a tower crane to a golf club. Figure 7 illustrates some of the applications, including the models used for analysis and examples of objective functions. As can be seen in the figure, the applications studied vary quite a lot, as does the software used to model the different products and domains.

The result section is split into two parts: technical implementation and collaboration activity.

4.1 Design Collaboration

The team members’ feedback on collaboration activity was investigated at different time steps in the project by means of two questionnaires. The results from the questionnaires are shown in Fig. 8. The figures in the circles correspond to the classification of the collaborative design tasks as: 1) discovering the problem, 2) defining the solution, 3) developing the analysis, and 4) delivering the result.

The figure illustrates the slight changes between the groups’ expectations and what they did in reality. This can be interpreted as the members becoming more conservative when faced with the challenges of implementation. For instance, in discovering the problem, members believe that they are able to investigate the problem and develop the models individually (number one in figure 8, left). However, in reality they expect some extra help from the group leader or organization (number one in figure 8, right). This can be seen in almost all the above tasks except delivering the result (number 4 in figure 8), where the teams believe that domain experts are chosen to deliver the results and interpret and explain them to the organization (in this study the teacher).

The results of changes in the points illustrated in figure. 8 highlight the importance of the following facts:

Assigning a leader to manage and control the MDO tasks is essential.
Groups should be preselected by the organization based on their expertise (i.e. the teacher for this study or the manager in industry).
There should be a person or authority to take the final decision on when the level of the results is satisfactory; otherwise the process could be very tedious since the results can in many cases be improve with each iteration.
The documentation of the result is moving more toward the open axis. This means that everyone in the group (domain experts) should participate in interpreting the results and documenting them. This correlates with the results from interviews.
More collaboration between domain experts is needed to better understand and formulate the problem.

4.2 Improved Guideline

The conducted survey highlights challenges in the technical implementation. It also emphasizes that the CMDO implementation requires a structured way of speeding up the process by predicting implementation difficulties and proposing a strategy to avoid or circumvent them. A revised guideline is therefore introduced in this paper to eliminate or ease the challenges summarized in Table 1. The proposed guideline is presented in Fig. 9 and consists of four blocks:

Object identification and system decomposition
Model development and evaluation
Model integration and assessment
Optimization and post-processing

The first block helps formulate the problem, forming the group and decomposing the product into multiple disciplines. IE and CE are responsible for performing the tasks in block 1 efficiently. However, to avoid poor system decomposition, as an important activity, collaboration with DEs is required. DEs are mainly responsible for the tasks in the second block regarding development and evaluation of the disciplinary models within the design space. The developed models are integrated and assessed with respect to multidisciplinary requirements, conditions, and effectiveness of design parameters regarding the design objectives. The IE plays an important role in collaborating with the CE and the DEs to realize these tasks. Finally, in block 4, the OE is responsible for the optimization and methods to compute the objectives more efficiently. The results are then further processed with the help of the CE.

Block 1: Object identification

This guideline is intended to facilitate the process of multidisciplinary design analysis at conceptual level. The conceptual engineer should therefore define the objectives and requirements of the analysis. In order to facilitate the decision-making process, it is recommended that the objectives be prioritized. It is also possible to start from simple and most important objectives but always discuss the other objectives with the interface expert and domain experts who are responsible for creating the models. This helps develop the models in an efficient way that can be seamlessly upgraded with higher fidelity in order to provide more information if needed later on in the process. The DEs are also able to accommodate an increasing degree of difficulty encountered by the optimization and data-handling tool.

Block 1: Role assignment

The interface expert, who has experience in both conceptual and detail analysis, is responsible for forming the team. Preliminary selection of team members is done based mainly on the experience of the interface expert about the expertise in an organization and with respect to the objectives. This team might be modified after doing system decomposition and mapping data flow when new requirements and perhaps new expertise are required.

Block 1: System decomposition and mapping data flow

A complex product consists of many systems and subsystems. In order to set up an MDO framework, it is crucial to understand the relationships between different systems and subsystems. Block 1 is very central in an MDO process. A minor error in this block can lead to a series of costly repetitive work. In this study, system decomposition is done in two steps:

Early system decomposition: where the interface expert and the conceptual engineer propose the most appropriate system decomposition with regard to the most crucial objectives and constraints for conceptual analysis. Based on this system decomposition, the domain experts are selected by the interface expert.
Final system decomposition: where the interface expert invites the selected domain experts to interactively evaluate the proposed early system decomposition and try to map the data flow between the disciplines. The evaluation also helps more realistic objectives and constraints to be chosen by bringing broader knowledge about the domains to the table. The result may lead to upgrading of the early system decomposition, e.g. adding or removing disciplines and the associated domain experts and modifying the team, respectively.

The overall flowchart of implementing block 1 is shown in Fig. 10.

Block 2: Model development

Mapping data flow helps clarify the inputs and outputs of each disciplinary model. Although this contributes to initiation of the model development process, in reality the models may need different sets of inputs based on the physical entity that is used inside the models. These elements of model development should be decided by domain experts bearing in mind that they should not affect the predefined outputs in the data flow. If the models do not provide the predefined outputs, the issue should be reported for further investigation by the team.

Block 2: Disciplinary feasibility analysis (DFA)

Analysis of the disciplinary model is evaluated using a method known as disciplinary feasibility analysis (DFA). DFA helps to evaluate the models within the design space prior to integrating them into the MDO framework. In DFA, the performance of each model within its design space to fulfil the predefined requirements is evaluated. The flowchart of executing DFA is illustrated in Fig. 11.

Block 3: Model integration

The disciplinary models approved by means of DFA then need to be integrated into the framework. Tool integrator software such as modeFRONTIER (Esteco, 2016), iSIGHT (iSIGHT, 2016) and OpenMDAO (OpenMDAO, 2016) facilitates the integration process by providing standard interfaces between the design tools in a centralized environment.

Block 3: Multidisciplinary feasibility analysis (MFA)

The performance of the individual models may change when they are coupled together because of unexpected integration effects, mainly due to the adjustment of the constraints and the design space. The performance of coupled models is therefore evaluated through a process of multidisciplinary feasibility analysis (MFA). The analysis is made through the joint efforts of domain experts and the interface expert. However, the interface expert has the main responsibility for performing the task and domain experts are supposed to facilitate the process of integration and tracking the data flow mapped in block 1. The flow diagram of MFA is shown in figure 12.

Block 3: Sensitivity analysis

The sensitivity analysis is mainly used to determine how different values of design parameters will impact particular objectives or constraints under a given set of assumptions (Saltelli et al., 2008). The sensitivity analysis in this study is used before the optimization in order to provide an estimation regarding the influence of each design parameter on the objectives or constraints. It could also accurately determine the size and position of the design space. Since the design points have already been created for the multidisciplinary feasibility analysis, using the same design points can perform the sensitivity analysis easily and less expensively. The sensitivity analysis helps remove the less effective design points to calculate the objectives and constraints and consequently speed up the optimization process. The result of the sensitivity analysis should be reported to the CE, who is responsible for making the final decision.

The result of the sensitivity analysis also highlights the effectiveness of system decomposition for calculating the design objectives and constraints and hence system decomposition can be improved. However, this is a drastic action because it leads to a series of repetitive and time-consuming tasks, e.g. remodelling and reintegration of the systems, see Fig. 13.

Block 4: Optimization and efficient computing

Rapid concept evaluation is a central demand in conceptual analysis. MDO analysis in the presence of higher fidelity models, however, can be very time-consuming, especially when using high fidelity and computationally intensive models such as CFD or FEM analyses.

To improve the optimization process time-wise, it is suggested that computationally cheap analyses be placed as early as possible in the framework. If these analyses reveal that the suggested solution is inadequate, there is no need to perform the computationally demanding analyses. These can therefore be omitted and the solution given a penalty to its objective function value to indicate to the optimization algorithm that the design is unsatisfactory.

Another popular way to speed up analyses is to replace computationally demanding analyses with computationally efficient surrogate models (SMs), also known as meta-models (Myers, 2009). The demanding analysis needs to be performed numerous times to gather data points. An SM is then fitted to these data points and placed into the optimization framework instead of the original analysis. The simulation results created for DFA in Block 3 could be used to create the SMs. The SMs are created as the first task in Block 4, see Fig 9.

Block 4: Post-processing

The generated optimization results should be further processed for easy use by the conceptual engineer. Typically, conceptual engineers require holistic information about the design that will help them choose the best concept with respect to the requirements. The detail information regarding the concepts may therefore not be of such great interest from a conceptual perspective. However, it has been proven that detail information is sometimes vital and helpful to choose the better concept. The detail results should therefore be represented from conceptual prospect, e.g. how they can influence the product objectives and constraints. The optimization problems in this study are categorized as multi-objective problems. The results can therefore be represented as compromises, for example with a Pareto front, which is a popular method to illustrate results. Figure 14 shows the data flow of block 4 (optimization and post-processing) of the guideline.

Table 1: Results from the interviews with the students regarding the task involved in a CMDO project.

A Guideline to Facilitate the Implementation of Collaborative Mdo in Conceptual Analysis of a Complex Product

Status:

Version 1

Abstract

Figures

1. Introduction

2. Method and theory

3. CASE STUDY

4. Result

Block 1: Object identification

Block 1: Role assignment

Block 1: System decomposition and mapping data flow

Block 2: Model development

Block 2: Disciplinary feasibility analysis (DFA)

Block 3: Model integration

Block 3: Multidisciplinary feasibility analysis (MFA)

Block 3: Sensitivity analysis

Block 4: Optimization and efficient computing

Block 4: Post-processing