ACKNOWLEDGEMENTS

I would like to sincerely thank my teacher Professor Arun K. Lal for giving me an opportunity to present my project report on Concurrent Engineering. I would like to sincerely thank him for the guidance and support which he lended to me during the formation and completion of my Project.

Ashish Sodhi 4th Year Mechanical

SID : BE08107087

CONCURRENT ENGINEERING

1. INTRODUCTION

Concurrent engineering is a work methodology based on the parallelization of tasks (i.e. performing tasks concurrently). Its definition can be summarized as: Systematic approach to integrated product development that emphasizes response to customer expectations and embodies team values of cooperation, trust and sharing in such a manner that decision making proceeds with large intervals of parallel working by all life-cycle perspectives, synchronized by comparatively brief exchanges to produce consensus. By Foster S. Thomas

Managing Quality: A Integrative Approach Upper Saddle New Jersey, Prentice Hall,2001 It refers to an approach used in product development in which functions of design engineering, manufacturing engineering and other functions are integrated to reduce the elapsed time required to bring a new product to the market. The concurrent engineering method is still a relatively new design management system, but has had the opportunity to mature in recent years to become a well-defined systems approach towards optimizing engineering design cycles. Because of this, concurrent engineering has gathered much attention from industry and has been implemented in a multitude of companies, organizations and universities, most notably in the aerospace industry. The basic premise for concurrent engineering revolves around two concepts. The first is the idea that all elements of a products life-cycle, from functionality, reducibility, assembly, testability, maintenance issues, environmental impact and finally disposal and recycling, should be taken into careful consideration in the early design phases. The second concept is that the preceding design activities should all be occurring at the same time, or concurrently. The overall goal being that the concurrent nature of these processes significantly increases productivity and product quality, aspects that are obviously important

in today's fast-paced market. This philosophy is key to the success of concurrent engineering because it allows for errors and redesigns to be discovered early in the design process when the project is still in a more abstract and possibly digital realm. By locating and fixing these issues early, the design team can avoid what often become costly errors as the project moves to more complicated computational models and eventually into the physical realm. As mentioned above, part of the design process is to ensure that the entire product's life cycle is taken into consideration. This includes establishing user requirements, propagating early conceptual designs, running computational models, creating physical prototypes and eventually manufacturing the product. Included in the process is taking into full account funding, work force capability and time, subject areas that are extremely important factors in the success of a concurrent engineering system. As before, the extensive use of forward planning allows for unforeseen design problems to be caught early so that the basic conceptual design can be altered before actual physical production commences. The amount of money that can be saved by doing this correctly has proven to be significant and is generally the deciding factor for companies moving to a concurrent design framework.

1.1 Improvements

One of the most important reasons for the huge success of concurrent engineering is that by definition it redefines the basic design process structure that was common place for decades. This was a structure based on a sequential design flow, sometimes called the Waterfall Model. Concurrent engineering significantly modifies this outdated method and instead opts to use what has been termed an iterative or integrated development method. The difference between these two methods is that the Waterfall method moves in a completely linear fashion by starting with user requirements and sequentially moving forward to design, implementation and additional steps until you have a finished product. The problem here is that the design system does not look backwards or forwards from the step it is on to fix possible problems. In the case that something does go wrong, the design usually must be scrapped or heavily altered. On the other hand, the iterative design process is more cyclic in that, as mentioned before, all aspects of the life cycle of the product are taken into account, allowing for a more evolutionary approach to design.The difference between the two design processes can be seen graphically in Figure 1.

Fig. 1 Waterfall or Sequential Development Method vs. Iterative Development Method A significant part of this new method is that the individual engineer is given much more say in the overall design process due to the collaborative nature of concurrent engineering. Giving the designer ownership plays a large role in the productivity of the employee and quality of the product that is being produced. This stems from the fact that people given a sense of gratification and ownership over their work tend to work harder and design a more robust product, as opposed to an employee that is assigned a task with little say in the general process. By making this sweeping change, many organizational and managerial challenges arise that must be taken into special consideration when companies and organizations move towards such a system. From this standpoint, issues such as the implementation of early design reviews, enabling communication between engineers, software compatibility and opening the design process up to allow for concurrency creates problems of its own. Similarly, there must be a strong basis for teamwork since the overall success of the method relies on the ability of engineers to effectively work together. Often this can be a difficult obstacle, but is something that must be tackled early to avoid later problems. Similarly, now more than ever, software is playing a huge role in the engineering design process. Be it from CAD packages to finite element analysis tools, the ability to quickly and easily modify digital models to predict future design problems is hugely important no matter what design process you are using. However, in concurrent engineering softwares role becomes much more significant as the collaborative nature must take into the account that each engineer's design models must be able to talk to each other in order to successfully utilize the concepts of concurrent engineering.

2.Problems solved The last few years have witnessed a resurgence of interest in complex systems. Complex systems theory is concerned with the understanding of intrinsic interactions and nonlinear dynamics of systems with many parts. Complex systems theory is a suitable framework that accounts for the complex interactions among the various functions of a manufacturing enterprise, which give rise to a complex behavior that cannot be attributed to a single separate subfunction but it is rather a collective effect. Understanding CE as complex systems may suggest ways for improving the decisionmaking process, and the search for innovative solutions. It may also lead to the development of guidelines for coping with complexity.

Decision-making during the design activity deals with highly complex situations. The traditional methods of decision-making are based on the classical model of pure rationality, which assumes full and exact knowledge about the decision situation being considered. In design, assumptions about the exact knowledge are almost never true. At least to a large measure, the requirements are not comparable andtherefore, the preference ordering among them is incomplete. The departure from pure-rationality based models to bounded-rationality based models is needed in design because of the fact that the designer has a limited information-processing capacity and the information is uncertain, vague, or imprecise. Such limitations may arise in several ways: the designer may not know all the alternative sequence of decisions; or even assuming all the conditions are known, the designer may be unable to decide the best sequence of decisions; or finally, the time and cost of computing the best possible choices may be beyond the bounds of the available resources. Thus the main CE principles are. Iteration principle: First, designers are only human and have a bounded rationality. They cannot simultaneously consider every relevant aspect of any given design. As the design process progresses, new information, ideas, and technologies become available that require modifying the design. Second, design systems are limited; there is no known system that can directly input a set of requirements and yield the optimum design. Rather, the designer must iteratively break down the set of requirements into dimensions, constraints, and features and then test the resulting design to see if the remaining

requirements were satisfied. Finally, the real world often responds differently than is imagined. The real world is full of chaotic reactions that are only superficially modelled in any design system. All this points to the seemingly undeniable truth that there is an inherent, iterative nature to the design process. Each iteration results in changes that must propagate through the design stages, requiring upstream rework. Consequently, late feedback and excessive upstream rework should be minimized; e.g. by utilizing multifunctional teams and early involvement of downstream activities in upstream stages. Parallelism principle: Scalable and complex systems must be highly parallelizable if short development times are required; otherwise valuable development times and resources are wasted. According to Amdahls law the systems performance (i.e., achievable speed-up) of a parallel system can be significantly limited by the existence of a small fraction of inherently sequential tasks, which cannot be parallelized. Consequently, multiple development stages have to be performed in parallel or with some overlap by sharing early preliminary upstream information with downstream stages. . Decomposition principle: Complex systems are often decomposed into a number of simpler subsystems that can be controlled independently, and whose individual behaviours yield the performance of the original complex system. Decomposition is also intended to exploit opportunities for parallel execution. The decomposition of a complex system into nearly independent subsystems is an inevitable consequence of bounded rationality; i.e., the limitations on the cognitive and information-processing capabilities of processors (e.g. the designers decision-making). In complex product development, processes are generally divided up into tasks and subtasks. Proper decomposition of design development tasks is concerned with assigning into the same team tasks that are anticipated to require high problem-solving interaction, while assigning to different (independent) teams tasks that require low problem-solving interaction. Minimizing the need for problem-solving across teams can have important consequences on product development performance, particularly since much of the activity of innovative product development projects involves problem solving and the creation of new knowledge Thus, the problem becomes the proper decomposition of the overall system into smaller manageable pieces (which are assigned to multiple development teams) by considering the constraints imposed by bounded rationality. . Stability principle: At a macroscopic level, complex systems show a coexistence of multiple ground states or, equivalently, multiple equilibria which are robust against

changes in the internal structure of the system. The system is said to be stable if the state of the system converges to one of the equilibrium states for any initial conditions. A product development process is said to be stable if the total number of design problems being solved remains bounded as the project evolves over time, and eventually falls below an acceptable threshold within a specified time frame. As implied by the iteration principle, design iterations result in changes that must propagate through the design stages, requiring upstream rework. This additional rework might slow down the PD convergence or have a destabilizing effect on the systems behavior. Several strategies may be utilized in order to mitigate the slow convergence or divergence of PD processes. As a general rule, the rate of problem solving has to be measured and controlled such that the total number of design problems being created is smaller than the total number of design problems being solved. The above principles are transformed into four fundamental problems. The first principle is concerned with iteration management and control and as such we refer to it as the Iteration problem. The second principle deals with overlapping practices in CE and we refer to the counterpart problem as The Overlapping problem. The third principle is concerned with decomposing a large project (or system) into smaller pieces (or subsystems), solving these pieces, and then reassembling them into an overall system solution. We refer to it as the Decomposition and Integration problem. Finally, the fourth principle is concerned with the understanding of the intrinsic interactions and dynamics of decomposed product development, and the circumstances under which projects exhibit persistent problems or reach satisfactory performance levels. The corresponding problem is referred to as the Convergence problem. The Iteration, Overlapping, and Decomposition and Integration problems address no temporal (structural or static) issues of product development such as team and product architecture formation, while the Convergence problem is concerned with temporal (dynamic) aspects such as understanding the complex behavior of product development tasks over time. The above principles and related problems are addressed within a flexible methodology called the Design Structure Matrix (DSM). The DSM is shown to share several common methodological themes with complex systems theory including the connectivity effect on product development performance, dynamics of complex product development interaction, and classification of complex collaborative design

3. Overview of DSM Design Structure Matrix Many of the traditional project management tools (Gantt, CPM, PERT, and IDEF methods e.g. see [20,21]) do not address problems stemming from project complexity. They allow project and engineering managers to model sequential and parallel tasks but not interdependent tasks, where a set of tasks is dependent on one another. The DSM method provides this representation capability in a simple and elegant manner. The DSM approach to managing complex development projects is an information exchange model which allows the project or engineering manager to represent important task relationships in order to determine a sensible sequence for the tasks being modeled. In this section, we describe the basic DSM method and how it can be used to model projects, determine the information needed by each task from other tasks, and to more accurately isolate and plan for problem areas taking place in the project. A DSM is a matrix representation of a directed graph that represents a complex system.2 The nodes of the graph correspond to the column and row headings in the matrix, and the arrows correspond to the C marks inside the matrix.3 For example, if there is an arrow from Node C to Node A, then a C mark is placed in Row A and Column C (see Figure 1). Diagonal elements have no significance and are normally blacked-out. If the DSM elements represent tasks to be performed, then inspecting the row and column of a task, reveals the inputs and outputs, respectively, for that task. For example, in Figure 1, B feeds C, F, G, J, and K, while D is fed by E, F, and L. If there is a time sequence associated with the position of the elements in the matrix, then all marks above the diagonal are considered feedback marks. Feedback marks correspond required inputs that are not available at the time of executing a task. In this case, the execution of the dependent task will be based on assumptions regarding the status of the input tasks. As the project unfolds these assumptions are revised in light of new information, and the dependent task is executed if needed. It is worth noting how easy it is to determine feedback relationships in the DSM compared to the graph, which makes the DSMa powerful, but simple, graphic representation of a complex system or project. The matrix can be manipulated in order to eliminate or reduce the feedback marks. This process is called partitioning. When this is done, a transparent structure for the network starts to emerge, which allows better planning of the PD project. We can see which tasks

are sequential, which ones can be done in parallel, and which ones are coupled or iterative (see Figure 1c). Implementing the CE principles proposed in this paper will facilitate the proper management of coupled tasks, which in turn can have important consequences on product development efficiency, effectiveness, and performance. This is especially important in innovative

product development projects, which involve many coupled tasks due to high problem solving and the creation of new knowledge. Once the DSM is partitioned, tasks in series are identified and executed sequentially. Parallel tasks are also exposed and can be executed concurrently. For the coupled ones, upfront planning is necessary. For example, we would be able to develop an iteration plan by determining what tasks should start the iteration process based on an initial guess or estimate of a missing piece of information. In Figure 1(c), block E-D-Hcan be

executed as follows: Task E starts with an initial guess on Hs output, Es output is fed to Task D, then Ds output is fed to Task H, and finally H output is fed to Task E. At this point, Task E compares Hs output to the initial guess made and decides if an extra iteration is required or not depending on how far the initial estimate deviated from the latest information received from H. This iterative process proceeds until convergence occurs (modelling the convergence process is described in Section 6). In partitioning, we have seen that the main objective was to move the feedback marks from the above the diagonal to below the diagonal, given that the DSM elements were tasks to be executed. However, when the DSM elements are people in charge of these tasks or are subsystems and components of a larger system, then we have a different objective for arranging the DSM. The new goal becomes finding subsets of DSM elements (i.e., clusters or modules) that are mutually exclusive or minimally interacting. This process is referred to as clustering. In other words, clusters contain most, if not all, of the interactions (i.e., DSM marks) internally and the interactions or links between separate clusters is eliminated or minimized [1,4,5]. In which case, the blocks become analogous to team formations or independent modules of a system (i.e., product architecture). Furthermore, in this setting, marks below the diagonal are synonymous to marks above the diagonal and they represent interactions between the teams or interfaces between the modules.

As an example, consider the DSM in Figure 2. The entries in the matrix represent the frequency and/or intensity of communication exchanged between the different development participants, represented by person A, person B, . . .etc

As can be seen in Figure 2(b), the original DSM was rearranged to contain most of the interactions within two separate blocks: EF and EDBCG. However, three interactions are still outside any block (i.e., team) and constitute the points of interactioncollaboration between the two teams. An alterative team arrangement is suggested in Figure 2(c). This arrangement suggests the forming of two overlapping teams (i.e., AFE and EDBCG) where one person (i.e., E) belongs to both teams and may act as a liaison person.6 The proper decision about how the elements of the product are assigned to chunks is affected by several technical and nontechnical factors. Several computational clustering techniques that search for optimal solutions based on tradeoffs

between the importance of capturing intra block dependencies versus inter block dependencies may be able to arrive to optimal solutions under certain assumptions

We close this section by exposing four different types of DSM models and their application to various levels of abstraction The Task-basedDSMmodel has been discussed earlier (see Figure 1). A variation of the Taskbased. DSM is the Parameter-based DSM, which takes a deeper look into the tasks by decomposing them further into the design parameters that are delivered by each task. Consequently, a parameter-based DSM describes how does the parameters influence each other and in what order they should be determined to minimize guessing and feedback. Thus, partitioning is also used to streamline the sequence of parameter calculations. The third DSM type is called Team-based DSM. This DSM model is used for organizational analysis and team formations based on the intensity and frequency of information flow among various organizational entities (i.e., development participants). Finally, the Componentbased DSM documents interactions between elements in a complex system architecture. For the latter two DSM models, clustering is used to rearrange the DSM and identify improved team formations or improved product architecture.

PRINCIPLES OF CONCURRENT ENGINEERING

A. PEOPLE The main aim of the approach of concurrent engineering in people is the management design matrix.

4. Concurrent Engineering in Process We have basically few tools to carry out CE process in process - QFD (Quality Function Deployment) - DFA (Design for Assembly) - DFM (Design for Manufacturing) - DFE (Design for Environment) - FMEA (Failure Mode and Effect Analysis) From the tools listed, the following two methods: * quality functions deployment (QFD) method and * failure models and effects analysis (FMEA) method

Present the methods which take care of transfer and fulfilment of customer wishes and requirements in all product development phases. Concurrent and sequential engineering usually consist of seven stages of product development process

In concurrent product development there are interactions among individual stages of product development process, while there are no interactions in sequential product development. Track-and-loop technology was developed for implementation of these interactions. Type of loop defines the type of cooperation between the overlapping process stages. Winner proposes the use of 3-T loops, where interactions exist between three stages of product development process. When 3-T loops are used (Fig. 3) new product development process consists of five 3-T loops. When developing a new product it is first necessary to determine its field of use, which corresponds directly to the target market. It is necessary to make a feasibility study which is the foundation for definition of the product development process.

Feasibility study consists of:

* concept of development and design, * definition of commercial conditions for product development, * definition of financial conditions for successful project

implementation, * definition of approximate organisation model for * definition of teams for product development process.

Results of this study are the foundations for definition of the basic plan of the new product development process. In the product development process, it is necessary to ensure dynamic execution of activities as additions to the concept. If these additions reach such an extent that it is difficult or even impossible

5. Design for manufacturing

Design for manufacturability (DFM) is the process of proactively designing products to: a) optimize all the manufacturing functions: fabrication, assembly test, procurement, shipping, service, and repair; b) assure the best cost, quality, reliability, regulatory compliance, safety, time to market, and customer satisfaction; and c) ensure that lack of manufacturability doesnt compromise functionality,

styling, new product introductions, product delivery, improvement programs, strategic initiatives, and unexpected surges in product demand [5]. Concurrent engineering (CE) is the practice of concurrently developing products and their design and manufacturing processes. If existing processes are to be utilized, then the product must be design for these processes. If new processes are to be utilized, then the product and the process must be developed concurrently. This requires knowing a lot about manufacturing processes and one of the best ways to do this is to develop products in multifunctional teams. DFM and CE are proven design methodologies that work for any size company.Early consideration of manufacturing issues shortens product development time, minimizes development cost, and ensures a smooth transition into production for quick time to market.

Fig. 1 shows that by the time a product is designed, 80% of the cost has been determined. And by the time a product goes into production, 95% of its cost is determined, so it will be very difficult to remove cost at that late a date. The most profound implication for product development is that 60% of a products cumulative lifetime cost is committed by the concept/architecture phase! This is why it is important to fully optimize this phase. The Toyota philosophy confirms this. The cost of a [product] is largely determined at the planning and design stage. Not much in the way of cost improvement can be expected once full-scale production begins. Skillful improvements at the planning and design stage are ten times more effective that at the manufacturing stage.

Time-to-Market: Time-to-market is a major source of competitive advantage. In fast moving markets, being first to market can have major market share implications. Fig. 2 shows the effect of an early product release on the revenue profile. The shaded area represents the extra sales due to the early introduction. But, since the product development and tooling costs were paid for by the base line sales profile, the shaded area is really extra profit.

Time to market is heavily affected by early optimization of the early concept/architecture phase as shown by the Lexmark model in the following Fig. 3. The projected 40% savings in the real time-to-market comes from thorough concept/architecture optimization that

minimizes the need for revisions and iterations and makes the manufacturing ramp-up much faster. Note that the architecture phase, labelled conceptual design went from 3% in the old model to 33%(of the total development time) in the new model, an order of magnitude increase! The more thorough up front work decreased the post-design activities (the revisions, iterations and ramp-up) from almost threefourths to less than a half of the product development cycle. It is more efficient to incorporate a balance of design considerations early than to implement the later with changes, revisions and iterations

Case study in Mentor graphic Product innovation and speed of development are becoming increasingly important in our global economy. Although the role of the product manager in new product development will vary by company, the product manager at minimum should take care in understanding and articulating the market potential and in participating on the product development team. Note that the first step of the new product development process is idea generation. Ideas are fleshed out into a proposal and presented to top management (or a new-product review committee comprised of key executives of all the functional areas) for screening. For major product ideas/ concepts that pass screening, management assigns representatives from relevant functional areas to a multifunctional project team for this particular new product endeavour. The team members select a leader (who might or might not be the product manager) to organize and monitor the project, guiding it through the critical path schedule developed by the team. All members do as many tasks as possible in parallel (concurrently) to shorten the product development cycle. For example, product managers can conduct focus groups on concept evaluation at the same time that engineering

is conducting technical feasibility studies. The dotted line from the concept development and evaluation box to project cancellation box indicates that

Concepts testing poorly should be considered for elimination as early as possible rather than investing more resources in their development. In general, the stages of new product development can be summarized in the following table.

There is increased pressure to get products of ever-higher quality to customers in ever-shorter times. Product life cycles are decreasing as well, and product price/ performance ratios are being scrutinized more carefully. The traditional serial approach to product design and development (see Fig. 3) used by many companies today is, therefore, hampering their ability to compete effectively in what is becoming an increasingly global market place for electronic (and other) products. In serial Engineering environment, design is often done in a relative vacuum [9]. Manufacturing, test, quality and service organizations may not see a design until it is virtually completed. If they raise points during design reviews regarding the difficulty, time, and expense involved in producing the design as presented, they may cause the need for the product to be redesigned.

If a redesign is too expensive or too time consuming, no action will be taken to improve the manufacturability, testability, quality, or serviceability aspects of the product, and it will be more expensive to produce, verify and support than it could (or should) before its entire life. All of thesefactors hamper competitiveness. One solution to improving competitiveness is to change from a serial design and development process to a concurrent engineering process (see Fig. 3). The concurrent engineering process treats design for manufacturability, testability, quality, and serviceability attributes (among many others) equally and in parallel with product design for performance attributes such as speed, power consumption, size, weight and reliability. Concurrent engineering integrates the expertise from all of the various engineering disciplines during the actual design phase and the whole focus of concurrent engineering is on a right-the-first-time process, rather than on the typical redo-until-right process that is so common in the serial engineering mode of operation. The elimination of design iterations reduces product development costs and shortens time to market for new product.

CASE STUDY I

For this particular research, 15 items, which are frequently coming to AEC for the last 5 years, is selected and analyzed. By looking only number wise; out of 15 items, only four are delivered to the customers on time and the rest (11) are delayed due to different reasons, which are indicated on the fish bone diagram on the thesis. The above illustration shows most of the time Addis Engineering Center is not delivering on time for its customers

REFERENCES

Websites used:

www.wikepedia.org www.google.com www.medley.edu www.books.google.com www.elsevier.com

Research Papers used: 1.Model based approaches to manage concurrent engineering by Steven Eppinger 2. Design for Manufacturability and Concurrent Engineering for Product Development by Alemu Mogues Belay 3. Concurrent Engineering By Rober Wyant , Penn State University 4. Composite forms of Organisations as a strategy for Concurrent Engineering Effectiveness by Frank
M. Hull, Paul D. Collins, and Jeffrey K. Liker