Taking Ideas from Paper to Practice: A Case Study of Improving Design Processes through Detailed Modeling and Systematic Analysis

Proceedigs of the 15th IFAC Symposium on Information of Control Problems in Manufacturing Proceedigs the IFAC on Submitted Proceedigs of the 15th 15th IFAC Symposium Symposium on to INCOM15 Conference, Ottawa, Canada, Available at www.sciencedirect.com Proceedigs of theOttawa, 15th IFAC Symposium on to online May 11-13, 2015. Canada Information Submitted INCOM15 Conference, Ottawa, Ottawa, Canada, Information Control Control Problems Problems in in Manufacturing Manufacturing Submitted Information Control Problems in Manufacturing Submitted to to INCOM15 INCOM15 Conference, Conference, Ottawa, Canada, Canada, May 11-13, 11-13, 2015. 2015. Ottawa, Canada May Ottawa, Canada May 11-13, 2015. Ottawa, Canada

ScienceDirect

May 2015 May 2015 May May 2015 2015

IFAC-PapersOnLine 48-3 (2015) 1043–1048

Taking Ideas from Paper to Practice: a Case Study of Improving Design Processes Taking Ideas from Paper to Practice: aa Case Study of Improving Design Processes Taking Paper to Study of Design through Detailed Modeling and Systematic Analysis Taking Ideas Ideas from from Paper to Practice: Practice: a Case Case Study of Improving Improving Design Processes Processes through Detailed Modeling and Systematic Analysis through Detailed Modeling and Systematic Analysis through Detailed Modeling Systematic Analysis Xiaoqi Zhang, Yu Hao,and Vince Thomson

 Xiaoqi Zhang, Yu Yu Hao, Vince Thomson Xiaoqi Vince Xiaoqi Zhang, Zhang, Yu Hao, Hao, Vince Thomson Thomson   Mechanical Engineering, McGill University, Mechanical Engineering, McGill University, Montreal, Quebec, Canada Mechanical Engineering, McGill University, Mechanical Engineering, McGill University, Montreal, Quebec, Canada Montreal, Quebec, Canada Montreal, Quebec, Canada Abstract: This paper presents a project conducted at Bombardier Aerospace aimed at shortening span Abstract: This paper presents aa project at Bombardier Aerospace shortening time and reducing duplicated effort duringconducted design. The current design processesaimed were at modeled at a span high Abstract: This paper presents project conducted at Aerospace aimed at shortening span Abstract: Thisand paper presents a opportunities project conducted at Bombardier Bombardier Aerospace aimed at shortening span time and reducing duplicated effort during design. The current design processes were modeled at a high level of detail analyzed for for improvement. After investigation of the critical paths time and reducing duplicated effort during design. The current design processes were modeled at high time duplicated and reducing duplicated effort duringproposed design. The current design processes modeled at aapaths high level of detail and analyzed for opportunities for improvement. After investigation of the critical and tasks, suggestions were to add resources to critical were tasks and to eliminate level of detail and analyzed for opportunities for improvement. After investigation of the critical paths level of detail and analyzed for opportunities for improvement. After investigation of the critical paths and duplicated suggestions proposed to to tasks to eliminate duplicated tasks tasks, by having only onewere department do them forresources all departments. Simulation of the and duplicated tasks, suggestions were proposed to add add resources to critical critical tasks and and to suggested eliminate and duplicated tasks, suggestions were proposed tomore add resources to critical tasks and eliminate duplicated tasks by having only department do for all departments. Simulation of the suggested scenarios showed that span time one could be reduced bythem than 20% with almost no change intoeffort. duplicated tasks by having only one department do them for all departments. Simulation of the suggested duplicated tasks by having only one department do them for all departments. Simulation of the suggested scenarios showed that span time could be reduced by more than 20% with almost no change in effort. scenarios showed that span could be reduced by more than 20% with almost no change effort. Keywords: process improvement, critical path analysis, Carlo simulation, resource allocation, © 2015, IFAC (International Federation of Automatic Hosting by Elsevier rightsin scenarios showed that span time time could be reduced byControl) more Monte than 20% with almostLtd. no All change inreserved. effort. Keywords: process improvement, critical path analysis, Monte Carlo simulation, resource aerospace. process improvement, critical path analysis, Monte Carlo simulation, resource allocation, Keywords: allocation, Keywords: process improvement, critical path analysis, Monte Carlo simulation, resource allocation, aerospace. aerospace.  aerospace. completion and entail additional cost. Besides tight deadlines  1. INTRODUCTION  completion additional cost. Besides deadlines for Loads, itand wasentail also observed Loads and tight Dynamics use completion and entail additionalthat cost. Besides tight deadlines 1. INTRODUCTION and entail additional cost. Besides tight deadlines 1. for Loads, it was also observed that Loads Dynamics use similar inputs, tools and processes to and perform certain Bombardier Aerospace designs, manufactures and supports completion 1. INTRODUCTION INTRODUCTION for Loads, it was also observed that Loads and Dynamics use for Loads, itItwas alsopossible observed that Loads and Dynamics use similar inputs, tools and processes perform activities. was then thatto some effortcertain was Bombardier Aerospace manufactures supports aviation products for thedesigns, business, commercial,and specialized similar inputs, tools and processes to perform certain Bombardier Aerospace designs, manufactures and supports similar inputs, tools and processes to perform certain Bombardier Aerospace designs, manufactures and supports activities. It was possible then that some effort was duplicated between the two departments. Therefore, the dual aviation products for the business, commercial, specialized and amphibious aircraft markets. In order to gain competitive activities. It was possible then some was aviation products for business, commercial, specialized activities. It time was the possible then that that were someset effort effort was aviation products for the the business, commercial, specialized goal duplicated between two Therefore, of cycle and costdepartments. reduction outthe asdual the and amphibious aircraft markets. In order to gain competitive advantage, Bombardier Aerospace continuously endeavours duplicated between the two departments. Therefore, the dual and amphibious aircraft markets. In order to gain competitive duplicated between the two departments. Therefore, the dual and amphibious aircraft markets. In order to gain competitive goal of cycle time and cost reduction were set out as the following specific objectives: advantage, Bombardier Aerospace continuously endeavours to improve processes for better quality, faster development goal of time and cost were set the advantage, Bombardier Aerospace continuously endeavours goal of cycle cycle timeobjectives: and costinreduction reduction were processes set out out as as and the advantage, Bombardier Aerospace continuously endeavours following specific 1. identify critical paths the Loads to improve processes for better quality, faster development and lower cost. Design activities are performed in the Core following specific objectives: to improve processes for better quality, faster development following specific objectives: to improve processes for better quality, faster development 1. identify paths in Loads solutions to shorten them; and lower cost. Design activities performed in the from Core Engineering Department, where are many professionals 1. investigate identify critical critical paths in the the Loads processes processes and and and lower cost. Design activities are performed in Core identify critical paths in the Loads processes and and lower cost. Design activities performed in the the Core 1. find solutions to shorten them; common tasks between Engineering Department, where many professionals from various disciplines execute a largeare number of tasks to make investigate solutions to shorten Loads them; and Dynamics and Engineering Department, where many professionals from 2. investigate investigate solutions to shorten them; Engineering Department, where manyWith professionals from find common tasks between Loads Dynamics and determine the possibility of only oneand department doing various aa analyses. large tasks to aircraft models andexecute perform various disciplines disciplines execute large number number of ofever tasksincreasing to make make 2. 2. find common tasks between Loads and Dynamics and 2. find common tasks between Loads and Dynamicsdoing and various disciplines execute a large number of tasks to make determine the possibility of only one department them to reduce duplicated effort; aircraft and perform analyses. With ever increasing product models complexity, the Core Engineering Department is determine the possibility of only one department doing aircraft models and perform analyses. With ever increasing determine the possibility of only one department doing aircraft models and perform analyses. With ever increasing them to reduce duplicated effort; 3. them determine the duplicated effect ofeffort; the proposed solutions on product complexity, Core Engineering Department is under greater pressurethe to deliver within schedule and budget. to product complexity, the Core Department is to reduce reduce effort; productgreater the Core Engineering Engineering Department is 3. them determine the effect of the solutions on performance as duplicated measured by spanproposed time and effort. under pressure to deliver within and Thus, a complexity, project was proposed to schedule improve thebudget. Core 3. determine the effect of proposed solutions under greater pressure to deliver within schedule and budget. 3. determine the effect ofbythe the proposed solutions on on under greater pressure to deliver within schedule and budget. performance as measured span time and effort. Thus, a project was proposed to improve the Core Engineering development process such that span time would performance measured by span time and effort. Thus, aa project was proposed to improve the Core Although processas improvement has been the cynosure in the performance as measured by span time and effort. Thus, project was proposed to improve the Core Engineering such that span time would be shortened development and duplicatedprocess effort reduced. Engineering development process such Although process process improvement has been the the cynosure cynosure in put the researchimprovement of product has development, how toin Engineering development process such that that span span time time would would academic Although been the be shortened and duplicated effort reduced. Althoughinto process improvement has been the especially cynosure in the be shortened and duplicated effort reduced. research of development, how to put theories practice hasproduct been challenging, when Core Engineering is a project centered department structured academic be shortened and duplicated effort reduced. academic research of product development, how to put academic research ofhas product development, howaretowhen put theories into practice been challenging, especially the process is complex. Whereas theoretical studies often Core Engineering is a project centered department structured into more than 20 design departments. Each department is theories into practice has been challenging, especially when Core Engineering is aa project centered structured theories practice has been challenging, especially when Core Engineering isdesign project centered department department structured the process is complex. Whereas theoretical studies are often based oninto assumptions and simplifications, actually executing into more than 20 department is responsible for designing ordepartments. validating a Each particular aspect of the process is complex. Whereas theoretical studies are often into more than 20 design departments. Each department is the process is complex. Whereas theoretical studies are often into more than 20 design departments. Each department is based on assumptions and simplifications, actually executing processes requires being specific and detailed. Therefore, in responsible for designing or validating a particular aspect of aircraft design. The research project focused on two of these based on assumptions and simplifications, actually executing responsible for designing or validating a particular aspect of based on assumptions and simplifications, actually executing responsible for designing or validating a particular aspect of processes requires being specific and detailed. Therefore, in order to give practical suggestions for process improvement, aircraft design. The research project focused on two of these departments, Loads and Dynamics, which are the most processes requires being specific and detailed. Therefore, in aircraft design. The project focused on two of processes requires being specific and Therefore, aircraft The research research project focused twothe of these these order to give give practical suggestions for process improvement, suggestions should precisely address thedetailed. following factors: in departments, Loads and Dynamics, Dynamics, which are most order involveddesign. in creating aeroelastic models. TheonLoads to practical suggestions for process improvement, departments, Loads and which are theprocess most to give practical suggestions improvement, departments, Loads toaeroelastic and Dynamics, which arecases. theprocess most suggestions should precisely addressfor theprocess following factors: involved inanalyses creating models. The Loads performs in determine critical load The order  who which engineer is affected; involved creating aeroelastic models. The Loads process suggestions should precisely address the following factors: suggestions should precisely address the following factors: involved in creating aeroelastic models. The Loads process performs analyses to determine determine critical aircraft load cases. cases. The Dynamics analyses process creates an aeroelastic modelThe to  what who which task engineer is affected; affected; is affected; who engineer is performs to critical load performs analyses to determine critical load cases. The  who which engineer is affected; Dynamics process creates an aeroelastic aircraft model to to  what validate aircraft design and an to aeroelastic demonstrateaircraft that certification what task is affected; affected; when which at whattask point of the process does the suggested Dynamics process creates model is Dynamics process creates an aeroelastic aircraft model are to  what which is affected; validate aircraft and to demonstrate that certification requirements are design met. The Loads and Dynamics processes  when when which at what whattask point of and the process process does does the the suggested suggested change happen; validate aircraft design and to demonstrate that certification  at point of the validate aircraft design andLoads to demonstrate certification when change at what point of and the process does the suggested requirements are met. The and Dynamics processes are complex. They receive multiple inputs that from 6 other happen;  how how do happen; the affected tasks change. requirements are met. The Loads and Dynamics processes are change and requirements are The Loads and suppliers. Dynamics processes are and tasks change. complex. They receive multiple inputs from 6 other departments andmet. several outside In addition, how change how do do happen; the affected affected complex. They receive multiple inputs from 6 other Featuring how how the tasks change.requirements, the complex. They receive multiple inputs from 6 other complex processes and precise  how how do the affected tasks change. departments and several outside suppliers. In addition, continuous updates of input data trigger iteration of data departments and several outside suppliers. In addition, departments and several outside suppliers. In addition, Featuring and precise requirements, the project hadcomplex a scope processes ranging from the “trees” to the “forest”: complex processes and precise requirements, the continuous of trigger verification, model generation, and analysis. continuous updates updates of input input data data trigger iteration iteration of of data data Featuring Featuring complex processes and the precise requirements, the continuous updates of input data trigger iteration of data project had a scope ranging from “trees” to the “forest”: every single task was mapped and validated; process project had a scope ranging from the “trees” to the “forest”: verification, model generation, and analysis. verification, model generation, and analysis. project had a scope ranging from the “trees” to the “forest”: The Loads process is central to aircraft development as it is verification, model generation, and analysis. every task was validated; process performance from theand system level; and root every single single was taskanalyzed was mapped mapped and validated; process every single taskanalyzed wastraced mapped and validated; process The Loads process central to aircraft development as it is on the critical pathis for all project management activities. performance was from the level; and root causes of problems were back tosystem single tasks. The Loads process is central to aircraft development as it is performance was analyzed from the system level; and Thethe Loads process central to aircraft development as it is performance was analyzed from the system level; and root root on critical for all management activities. Even when therepath is ais delay inproject inputs, the deadlines for Loads causes of problems were traced back to single tasks. on the critical path for all project management activities. causes of problems were traced back to single tasks. on thewhen critical path for allinproject management activities. 2. METHODOLOGY causes of problems were traced back to single tasks. Even there is deadlines for Loads are usually postponed. Loads department is Even when not there is aa delay delayTherefore, in inputs, inputs, the deadlines for Loads the Even when there is a pressure delayTherefore, in to inputs, the Loads deadlines for which Loads 2. METHODOLOGY 2. are usually not postponed. the department is The project consisted normally under time perform its activities, are usually not postponed. Therefore, the Loads department is of two major parts: analysis of the 2. METHODOLOGY METHODOLOGY are usually not postponed. Therefore, the Loads department is normally under time time pressure to perform perform its activities, which puts the quality of work at risk. Data of its inferior quality can The normally under pressure to activities, which project consisted of parts: of current situation, and exploration of possible improvements of two two major major parts: analysis analysis of the the The project consisted normally under time pressure towhich perform its activities, which The project consisted of two major parts: analysis of the puts quality of work at risk. Data of inferior quality can causethe unplanned iterations, further delay project current situation, and exploration of possible improvements puts the quality of work at risk. Data of inferior quality can (Fig. 1). To analyze the current situation, development current situation, and exploration of possible improvements puts theunplanned quality of iterations, work at risk. Data further of inferior quality can current situation, and exploration of possible improvements cause which delay project (Fig. 1). 1). To To analyze analyze the the current current situation, situation, development development cause cause unplanned unplanned iterations, iterations, which which further further delay delay project project (Fig. (Fig. 1). To analyze the current situation, development

Copyright 2015 IFAC 1093Hosting by Elsevier Ltd. All rights reserved. 2405-8963 © 2015, IFAC (International Federation of Automatic Control) Peer review© of International Federation of Automatic Copyright 2015 IFAC 1093 Copyright ©under 2015 responsibility IFAC 1093Control. Copyright © 2015 IFAC 1093 10.1016/j.ifacol.2015.06.221

INCOM 2015 Xiaoqi Zhang et al. / IFAC-PapersOnLine 48-3 (2015) 1043–1048 May 11-13, 2015. Ottawa, Canada

1044

processes were mapped, and Monte-Carlo simulation was performed for critical path analysis. During the study of process improvement, solutions such as fast tracking, crashing and sharing tasks were proposed. Solution feasibility was examined with Loads and Dynamics engineers. Then, the effect of possible solutions was found through simulation. Analysis of current situation Determine critical tasks Explore possible solutions

Exploration of possible improvement

Develop “as-is” models

Critical path analysis

Determine common tasks Explore sharing feasibility

Task sharing

Scenarios of possible improvement Develop “to-be” models Do simulations to examine effect

development progress and quality were modelled as decision points which controlled iterations of upstream tasks. 2.2 Model Validation Models were validated through three approaches: (a) discussions with engineers, (b) comparison of simulation results and actual processes, and (c) a robustness test. (a) The information of each individual task and dependencies between tasks were validated through one-on-one meetings with task owners. (b) The model was setup for Monte-Carlo simulation of the “as-is” scenario where CAM generated the expected range of process durations (Fig. 2) and Gantt charts of all tasks (Fig. 3). After consultation with development engineers, it was agreed that the project span time from the simulation properly reflected the actual situation. (c) Since people might be optimistic in estimating duration, a robustness test to examine the sensitivity of models to data variation was done. The result was that a 10% increase in the most probable task duration for all tasks only caused a 6% increase in span time. This meant that outcomes were not very sensitive to input data and that the models were robust.

Fig. 1 Project methodology 2.1 Process Modelling Models of the Loads and Dynamics processes served as the mainstay for analysis and simulation. Since design processes can naturally be described as a sequence of operations, the project adopted the discrete event paradigm for process modelling. The discrete event paradigm considers the operation of a system as a sequence of events which occur under certain conditions and change the system state. In the case of the design processes, events were individual tasks which started when required information arrived and triggered other tasks when completed. The Cambridge Advance Modeller (CAM) developed by Wynn et al. (2010) was selected to build the model. CAM is a research tool that models, simulates and analyzes the dependency and information flow in a complex system. Since CAM has features to add variable task duration, to capture rework iteration, and to continue the process with fewer available inputs, it is possible to simulate the behaviour of a process very realistically. In a preceding project by Hisarciklilar et al. (2013), much effort was spent on building detailed models of the Loads and Dynamics processes. The follow-on project described in this paper updated the process models that were a series of individual tasks connected by the pieces of information that were exchanged among tasks. The model was stochastic with task durations following a triangular probability distribution function (PDF) and with the outcome of decision points determined by probability. The triangular PDF for task duration was characterized by three time points: optimistic, likely and pessimistic. Optimistic was the minimum time to complete a task when everything went well; likely was the most probable time to complete a task; pessimistic was the maximum time a task could take. Tasks that checked

Fig. 2 Histogram of process duration from the Monte-Carlo simulation for the “as-is” scenario 2.3 Critical Path Analysis The critical path is the longest path in a process comprising a series of interdependent activities that together determine the duration of a project (Santiago and Magallon, 2009). A critical task is an activity on the critical path. Delay or prolongation of any critical task delays the completion of the whole project. Therefore, shortening project span time means compression of the critical path. Fast tracking and crashing are the main approaches for improvement. Fast tracking is about performing sequential activities in parallel. It has the advantage of not incurring extra effort while shortening span time. However, it may put task quality at risk and cause rework if overlapping parts of two parallel tasks are highly interdependent. Crashing is about expediting critical tasks by adding more resources. It usually requires extra effort due to coordination, learning curve, etc.; so, trade-offs between span time and effort are often made. It should also be noted that compression of a critical path does not necessarily shorten span time to the same extent, as

1094

INCOM 2015 Xiaoqi Zhang et al. / IFAC-PapersOnLine 48-3 (2015) 1043–1048 May 11-13, 2015. Ottawa, Canada



the critical path may switch to another sequence of activities. Thus, it is important to track the change in the critical path.

1045

project span time was calculated from a large number of simulations. A parametric experiment was conducted to find out how many simulations were adequate to generate an unbiased average value with small deviation. Different numbers of Monte Carlo simulation runs, including cases of 50, 100, 200, 500, and 1,000, were tested. Each case was executed 10 times and the coefficient of variation (CV) was calculated. CV decreased with an increasing number of runs (Fig. 5) and reached 0.12% at 1,000 runs. Thus, 1000 Monte Carlo runs produced sufficiently accurate results. For each scenario of possible improvement, Monte Carlo simulations were done to compare the average span time and effort. Start with “asis” model

Identify critical path and tasks

Fig. 3 Task duration Gantt chart for one case of “as-is” scenario Determine tasks to be fast tracked or crashed

The steps of the critical path analysis are summarized in Fig. 4. With the “as-is” model as a basis, critical tasks were identified from simulation results. Then, “one-on-one” interviews with task owners were conducted to determine the possibilities of fast tracking and crashing each critical task. As a result, possible solutions to shorten the critical path were obtained. Scenarios of these solutions were made into “to-be” models, and simulations were conducted to check whether the critical path switched to another sequence of tasks. If the critical path switched, the possibility of fast tracking or crashing the new set of critical tasks was discussed with task owners. Simulations of “to-be” scenarios and interviews with engineers were conducted until the set of critical tasks stayed stable and no more fast tracking or crashing could be done.

Possible solutions

Model scenarios with fast tracking and crashing

Yes

Critical path changed? No End

2.4 Sharing Tasks Loads and Dynamics are relatively independent design groups. Although it was realized that they used the same inputs and similar design processes, there had been no thorough investigation of which exact tasks could be shared. In order to reduce duplicated effort, several meetings involving both departments were conducted to explore the possibility of having one department do the work and share results with the other. Process models of both departments were examined so that engineers could understand each department’s work. Possible sharing opportunities were explored and the feasibility was discussed with task owners. 2.5 Simulation To investigate the effect of possible solutions, which included fast tracking, crashing and task sharing, Monte-Carlo simulations were done on “to-be” models. A Monte Carlo analysis is composed of multiple simulation runs, where a simulation run randomly picks a value from the triangular PDF for the duration of each task, which results in different process span times for each run. Hence, the average

Fig. 4 Steps of critical path analysis 3. ANALYSIS OF CURRENT SITUATION 3.1 Process Models and Task Characteristics The Engineering Process at Bombardier Aerospace is divided into 7 phases: conceptual definition, launch preparation, preliminary definition, detail design, product definition release, product certification and program completion. A complete cycle of analysis performed by a department was known as a loop. Loops by Loads and Dynamics were done during the whole product development cycle. At the early phases, Loads and Dynamics did not communicate much as they had different needs. Increasing communication occurred at phase six, product certification, when Dynamics delivered a validated aeroelastic model to Loads. The models were based on early phases of the Global aircraft program; so, the “as-is” models of Loads and Dynamics were separate and had no information exchange. The Loads process model was comprised of about 90 tasks with 18 inputs from 6 other departments and 11 inputs from

1095

INCOM 2015 Xiaoqi Zhang et al. / IFAC-PapersOnLine 48-3 (2015) 1043–1048 May 11-13, 2015. Ottawa, Canada

1046

Coefficient of variation

engine manufacturers and landing gear suppliers. The Loads process was further divided into 10 design groups, each in charge of the calculation of aircraft loads under a certain condition such as landing, lift, etc. There were three major phases: pre-processing, distributed loads calculation and discretized loads calculation. The preprocessing phase included activities such as converting file formats, data verification, and running test runs to rate the quality of inputs. Then, design groups used the preprocessed data to develop aircraft models. A series of flight cases were tested on aircraft models during the distributed loads calculation. Then, critical cases selected from all these cases were further analysed during the discretized loads calculation, which generated reports for other departments. Most design groups did frequent validation checks which could cause rework. 0.60% 0.50% 0.40% 0.30% 0.20% 0.10% 0.00% 0

200

400 600 800 1000 1200 Number of runs

Fig. 5 Coefficient of variation vs. number of runs The Dynamics process model consisted of about 40 tasks with 6 inputs from 5 other departments. Activities in the Dynamics process were pre-processing, model generation, and analysis. Although Dynamics had much fewer tasks than Loads, it involved extensive iteration to refine the analysis and also used more complex aircraft models. Tasks had different types of interdependency including pooled, sequential and reciprocal. Tasks between different design groups had pooled dependency, as they were almost independent, but together contributed to the final results. Tasks in the same design group had sequential dependency, as each task relied on the inputs from prior tasks. Reciprocal dependency happened at checking activities, which validated inputs from prior tasks and gave feedback about whether iteration was necessary. In the process models, task dependency was captured by connecting links representing information exchanges. 3.2 Critical Tasks to be Compressed From the Gantt charts of simulation results for the Loads process, it was found that critical tasks were mainly done by four design groups: (1) Aeroelasticity Effect, which derived incremental elastic distributions, (2) High Lift Loads, which calculated aircraft loads in the manoeuvres of high lift, high speed and maximum operation, (3) Flight Manoeuvre, which calculated the aircraft loads for different manoeuvres such as roll, pitch, etc., and (4) Dynamic Gust, which calculated the distribution of aircraft surface loads in airflows.

The Aeroelasticity Effect group had a task with long duration located on the critical path. Interviews with engineers indicated that the task required intensive knowledge and experience, meaning qualified additional resources were difficult to find or train. Also, it was indivisible; so, additional resources could not expedite it. Thus, it was decided that the calculation of Aeroelasticity Effect could not be compressed for the moment. Tasks in the High Lift Loads group were on the critical path during the phases involving both distributed loads and discretized loads. The group was comprised of three subprocesses: High Lift Manoeuvre, High Speed Manoeuvre and Maximum Operation Manoeuvre. These subprocesses were relatively independent, i.e., they had little information exchange with most tasks, and were executed in sequence due to limited resources instead of interdependence. Interviews with engineers indicated that, although training was necessary to do tasks in this group, it was not necessary to have highly experienced engineers to perform the tasks efficiently. Thus, a possible solution to compress High Lift Loads was to add more resources such that subprocesses could be performed in parallel. Since High Speed Manoeuvre was more complex than the other two subprocesses, one scenario was to keep the original experienced resource in High Speed Manoeuvre while adding one resource to perform tasks in the High Lift Manoeuvre and Maximum Operation Manoeuvre groups. Another possible scenario was adding two resources such that each resource was in charge of one subprocess. The Flight Manoeuvre group had several tasks on the critical path during the distributed loads phase. Similar to High Lift Loads, multiple tasks were done in sequence due to limited resources. A possible solution was to add resources such that tasks could be done in parallel. In the discretized loads phase, the Dynamic Gust group had a checking task with a long duration located on the critical path. According to discussions with engineers, the task was long due to the great number of cases to be checked, and more resources performing the work would make it faster. It was also decided that one or two additional resources were reasonable. Since the Flight Manoeuvre process was only critical during the distributed loads phase, and the Dynamic Gust process was critical during the discretized loads phase, it was decided that a more feasible solution was to have one or two additional resources perform the critical tasks for the Flight Manoeuvre process during the earlier phase and then switch to the Dynamic Gust process during the latter phase. To summarize, we had the following possible solutions to compress critical paths: (a) add one resource to the High Lift Loads process to work on two subprocesses; (b) add two resources to the High Lift Loads process, each working on one subprocess; (c) add one resource to the Flight Manoeuvre process to work on tasks during the distributed loads phase and then switch to the Dynamic Gust process to work on the checking task; (d) add two resources to the Flight Manoeuvre process to work on tasks during the distributed loads phase and then

1096

INCOM 2015 Xiaoqi Zhang et al. / IFAC-PapersOnLine 48-3 (2015) 1043–1048 May 11-13, 2015. Ottawa, Canada



switch to the Dynamic Gust process to work on the checking task. The scenarios were developed as “to-be” models based on the assumption that additional resources were as efficient as the original resources.

Dynamic Gust (FD) respectively. The fourth column shows the corresponding increase of average span time compared to the “as-is” scenario, and the last column indicates the increase in effort compared to the “as-is” scenario. Table 1. Simulation results of compressing tasks

3.3 Common Tasks to be Shared After exploration of sharing opportunities and discussion of feasibility, it was agreed that three tasks could be shared: weight pre-processing, aero-panelling and aero-factoring. Both the Loads and Dynamics Departments received weight data from the Mass Department and pre-processed it by checking data quality and converting the data to a usable format. The methods that the two groups used were the same. Since Loads could process the data automatically, it did the task much faster than Dynamics. So, the proposal was to have Loads do the task and deliver the processed data to Dynamics. Both departments used geometry data from the Masterlines Department to do aero-panelling and used the same CFD data to do aero-factoring. Aero-panelling extracted data from aircraft geometry to build aero-panels. Aero-factoring used CFD and wind tunnel data to tune the aerodynamic model to refine the loads distribution calculation. The duration of the tasks did not vary much between the two departments; so, it was determined that either department could do the tasks and deliver results to the other. To summarize, we had the following possible scenarios for sharing common tasks: (e) Loads department preprocesses weight data and delivers the results to the Dynamics department; (f) Loads department does aero-panelling and delivers the results to the Dynamics department; (g) Dynamics department does aero-panelling and delivers the results to the Loads department; (h) Loads department does aero-factoring and delivers the results to the Dynamics department; (i) Dynamics department does aero-factoring and delivers the results to the Loads department. Scenarios (a) through (i) were developed as “to-be” models. Estimation of coordination effort due to extra resources was obtained from engineers and put into the models. 4. SIMULATION RESULTS OF POSSIBLE SOLUTIONS Each possible solution proposed in section 3 was simulated 1000 times and the average span time and effort were calculated. 4.1 Compression of Critical Tasks After all simulation results for the four solutions and their combinations were gathered, whether a “to-be” scenario was beneficial was apparent by comparing the project span time and effort with the “as-is” scenario. The simulation results of the solutions to compress the critical path are shown in Table 1. In the table, the second and third columns indicate the number of extra resources added to High Lift Loads (HL) and to Flight Manoeuvre and

1047

Solutions

HL

FD

Increase in span time (%)

Increase in effort (%)

a b c d a+c a+d b+c b+d

1 2 0 0 1 1 2 2

0 0 1 2 1 2 1 2

-0.33 -0.17 -2.81 -2.48 -21.34 -21.84 -21.84 -23.57

1.38 1.93 0.00 0.41 1.38 1.79 1.93 2.34

It was noticed that, compared to adding resources to both HL and FD (solutions a + c, a + d, b + c and b + d), adding resources to one position (solutions a, b, c or d) made little difference to span time. This was because the critical path switched between the two positions. Compressing one single position made the critical path switch to another position. Thus, an optimal solution should have extra resources added to both HL and FD. Among the scenarios with both positions having extra resources, we would like to know whether a third resource adds value. By comparing scenarios a + c (add one extra resource to each position) to a + d and b + c (add one extra resource to one position and two to the other), it was observed that adding a third resource to either position did not shorten the span time much (0.50%), while the effort was increased by 0.41%~0.55%. This can be explained by critical path switching between HL and FD. Therefore, we assert that a third resource does not add value and two resources should be added to HL and FD to minimize span time. Finally, scenarios a + c (add one extra resource to each position) and b +d (add two extra resources to each positions) were compared. The span time was shortened by 2.23% while the effort was increased by 0.96%. Which scenario is best depends on which aspect managers value more: shorter span time or less effort. Since the objective of adding extra resources was to reduce span time, it was recommended to choose scenario b + d since it had the shortest span time. If a trade-off has to be made between span time and effort, scenario a + c (adding one resource to each position) performs best since it has a relatively short span time and does not require much more effort. 4.2 Sharing Common Tasks The simulation results for sharing weight preprocessing are shown in Table 2. The span time in the Loads Department does not change in this scenario, since the shared task is not located on the critical path and minor changes in its duration do not influence total span time. It can be seen that the weight sharing scenario is beneficial as the total effort is reduced, although the span time is not affected.

1097

INCOM 2015 Xiaoqi Zhang et al. / IFAC-PapersOnLine 48-3 (2015) 1043–1048 May 11-13, 2015. Ottawa, Canada

1048

5. CONCLUSIONS

Table 2. Results for sharing weight preprocessing Scenario e

Increase in span time (%) 0.00

Weight preprocessing Yes

Increase in effort (%) -0.48

Since it is always beneficial to share weight data between Loads and Dynamics, we only compared simulation results for sharing aero-factoring and aero-panelling. The results are shown in Table 3. The second and the third columns indicate whether aero-paneling (AP) or aero-factoring (AF) is shared and which department does the work. L means Loads does the work and delivers results to Dynamics; D means Dynamics does the work and delivers results to Loads. The scenario with the least effort is the best choice, as the purpose of sharing design tasks is to reduce duplicated effort and the average span time for each of the scenarios does not vary a lot. It can be observed that scenario g + h (Dynamics does aero-panelling and Loads does aero-factoring) has the shortest span time and the least effort compared with the other scenarios. Hence, it was suggested to have the Loads Department do aero-factoring and the Dynamics Department do aero-panelling. Table 3. Results for sharing aero-factoring and aeropanelling Scenarios

AP

AF

f g h i f+h f+i g+h g+i

L D No No L L D D

No No L D L D L D

Increase in span time (%) 0.50 -1.24 0.17 -0.83 1.24 -0.25 -1.40 -1.65

Increase in effort (%) -0.14 -0.14 -1.24 -0.48 -1.38 -0.62 -1.38 -0.62

#1 #2

FD

WP

AP

AF

2 1

2 1

L L

D D

L L

Increase in span time (%) -24.97 -22.74

Although the utilization of modelling and simulation to improve processes has been discussed in many papers, few have considered detailed analysis of processes. The project at Bombardier Aerospace provided an opportunity to take ideas from paper to practice. The key to practical solutions is precision. As the foundation for analysis, the process model had a high level of detail to represent reality well. Systematic analysis enabled the tracing of root causes to individual tasks. Final solutions precisely addressed which tasks would change and what their effect would be. The main challenge at Bombardier Aerospace is the coordination among departments. Core Engineering has many outside suppliers and eight departments that exchange input and output data. Processes trigger or constrain each other due to information dependencies among them. The project presented in this paper only studied the Loads and Dynamics Departments. How the suggested changes could impact other departments and suppliers is unknown.

Table 4. Optimal solutions HL

A case study was presented in which process simulation and critical path analysis were applied to find solutions for reducing the span time and duplicated effort for product development at Bombardier Aerospace. The output of the Loads department drives aircraft sizing; thus, the Loads process is on the critical path of most projects and under great time pressure. Besides, Loads and Dynamics have common tasks that incur duplicated effort. From the critical path analysis, it was suggested to put additional resources on certain tasks, which could reduce span time by more than 20%, but require some extra effort. Moreover, common tasks between Loads and Dynamics were investigated. It was suggested to share three tasks, which resulted in a reduction of effort. Combining the solutions of adding resources and sharing tasks gave a span time reduction of more than 20% with almost no change in effort. The case study provides an example of using process simulation to explore solutions for shortening span time.

Increase in effort (%) +0.48 -0.48

A future study should be the investigation of the coordination among all departments in Core Engineering. A holistic picture of all processes could help to determine how other departments should change to provide further synergies. REFERENCES

4.3 Optimal Solutions Combining optimal solutions obtained from simulations of critical path compression and task sharing gives two choices as shown in Table 4. In both cases, weight preprocessing is shared and to be done by Loads; aero-panelling is shared and to be done by Dynamics; aero-factoring is shared and to be done by Loads. Two extra resources are added to High Lift Loads (HL) and Flight Manoeuvre and Dynamic Gust (FD) respectively in the first case, whereas one more resource is added to each position in the second case. The first case reduces the span time more, but requires more effort, whereas the second case reduces the span time slightly less, but reduces effort at the same time. Considering the feasibility of training resources transferred from other departments or processes, we recommended the second case.

HISARCIKLILAR, O., SHEIKH, O. K. B., YADAV, H. A. and THOMSON, V. (2013) Improving Coordination Between Aircraft Development Processes Through Process Mapping and Simulation, SAE Aerotech Congress, Montreal, Canada SANTIAGO, J. and MAGALLON, D. (2009) Critical Path Method, Stanford CEE 320 Seminar, http://web.stanford.edu/class/cee320/CEE320B/CP M.pdf WYNN, D. C., WYATT, D. F., NAIR, S. M. T. and CLARKSON, P. J. (2010) An Introduction to the Cambridge Advanced Modeller. Proceedings of MMEP, Cambridge, UK.

1098