ردیابی وابستگی مشخصات محصول در طراحی مشترک برای مدیریت تعارض

The main difficulty associated with a collaborative design process is understanding the product data exchanged during the design. Efficient and effective coordination of design activities relies on a thorough understanding of the dependencies between shared product specifications throughout the entire development cycle. This paper explores the linkages between the design process features and product specification dependencies, and suggests ways of identifying and managing specification dependencies to improve collaborative process performance. Using a UML (Unified Modeling Language) specification, we propose a process traceability tool to track the design process in an ongoing manner. Based on the information captured, the dependencies between specifications involved in the tracked process are identified and inserted in a dependency network, which is maintained throughout the design process. A set of mechanisms is then proposed to qualify the identified dependencies. Extracting and qualifying specification dependencies could be useful in many design situations; for example, during an engineering change management process to assess impacts and study change feasibility, or during a conflict management process to assist designers in resolving conflicts and maintaining the coherence of the design process (knowing that change management is a tool to conduct conflict management). Special attention is paid to the conflict management process. By means of a case study, we show how the solution we propose can assist designers during the conflict management process.

Although in most design processes, coordination entails clear communication between designers, the real reason for this coordination is not for communication but for resolving dependencies between product specifications [1]. Design is constraint oriented, and comprises many interdependent parts. A change in one part may have consequences for another part, and designers cannot always oversee these interdependencies and consequences. Product specifications are not always trivial and explicit. Current Product Data Technology (PDT) tools are not able to extract these dependencies from informal and textual descriptions, and hence the dependencies cannot be revealed by the currently available PDT tools. Several researchers have investigated specification dependencies, for example: Eppinger et al. [2], Kusiak and Wang [3], Dong and Agogino [4], Wang and Jin [1], Browning [5] and Yassine and Braha [6]. Most have proposed a representation of specification dependencies (with a DSM1 matrix, a network or a set of patterns) but none has shown how to obtain these representations or proposed mechanisms to identify dependencies. Moreover, these studies have addressed the specifications involved in a design process that has already been carried out, whereas the usefulness of specification dependencies knowledge is primarily during the design process, to help designers to perform their activities and resolve interdependency problems. In addition to this reported work, all studies reported to date have only investigated the case of two dependent design activities (an upstream activity feeds specifications to a downstream activity) belonging to the same decomposition level of the design process. For a complete identification of specification dependencies, it is necessary to consider the dependencies between activities carried out at various decomposition levels of a design process. In terms of dependency qualification, some researchers have provided interesting proposals on this issue. We particularly note the framework developed by Krishnan et al. [7] to measure dependency based on two dimensions: upstream specification evolution and downstream specification sensitivity. We also cite the work of Kusiak and Wang [3] dealing with qualitative dependency (the direction of the change of a product specification that is affected by another) and quantitative dependency (the rate of change of a product specification that is affected by another). However, these dependency qualifications and quantifications do not assist in identifying whether the dependency is strong and should be kept, or whether it can be removed. We should highlight that all of the previous studies have assumed the importance of qualifying product specification dependencies but none of them has proposed mechanisms to support these dependencies. We have therefore developed a solution called DEPNET,2 which explicitly captures product specification dependencies, inserts them in a dependency network that is maintained throughout the design process, and assists designers in resolving dependencies during the design process, particularly when design conflicts occur or when engineering changes are requested. The DEPNET solution differs from the previous studies [1], [2], [3], [4], [5], [6] and [7] in three major aspects, as follows. • It proposes a method to identify specification dependencies and defines concepts to qualify the discovered dependencies. • It takes into account the predefined specifications as well as the emerging specifications resulting from non-planned design activities. • It considers the design process in a more realistic way and seeks to identify product specification dependencies among sets of dependent activities belonging to various decomposition levels. In addition to the introduction, this paper consists of four more sections. Section 2 illustrates the problem definition, using the example of a turbocharger design problem. Section 3 focuses on the DEPNET solution: it describes the dependency network constructs and shows how to build this network. Section 4 illustrates, by means of a case study, the use of the DEPNET solution during conflict management, while Section 5 provides conclusions and future prospects.

Product specification dependencies are not always trivial and explicit, and current PDT tools are not able to extract these dependencies from informal and textual descriptions. As a consequence, they cannot be discovered by the current PDT tools. Many studies have focused on data dependencies, but none of them have proposed mechanisms to identify these dependencies and the methods to manage them. The DEPNET solution presented in this paper captures product specification dependencies and structures them in a network. It proposes mechanisms to qualify these dependencies and defines ways of using these dependencies during the conflict management process, first, to identify the negotiation team, and second, to assess the solution impacts. The success of the DEPNET solution depends, like any other computerised application, on the involvement of people to populate and update the network. Under time pressure, actors may not be willing to record all needed information consistently. In this case, they are asked to capture a minimum of information (the activity name, input data and generated data). In some large cases, since the use of the DEPNET solution reduces iteration, design actors should adhere to the proposed solution. Further points remain to be considered on the issue of specification dependencies management. First, since the dependency network is dynamic and evolving during the process progress, an automated tool for charting and maintaining the coherence of this network would be helpful, especially in the case of complex products. Secondly, the DEPNET solution currently addresses specifications already generated in the design process. Extending this solution to cover all product dependencies, i.e., specifications that are not yet generated, would reduce conflict occurrence and assist designers in their work by taking into account the various interactions between product specifications. Thirdly, the dependency network proposed in this paper can provide a means for representing and for reasoning about the dependencies between product specifications. It may be useful to reduce the number of specification dependencies to the necessary minimum. For this purpose, mechanisms to check specification consistency would be proposed. These mechanisms can also be used as a decision tool to control product complexity and test various product configurations by eliminating some dependency arcs and analysing the impact of the corresponding alternatives. For this purpose, a set of criteria to analyse configurations, a constraints database and a verification mechanism are proposed. In both cases, graph theory can be used to achieve this goal. On the other hand, in addition to tracing process design and generating a dependency network, the DEPNET solution can evolve into a rationale design capitalisation tool. Text mining techniques could be applied to the ‘justification’ table to extract new knowledge from stored cases. Moreover, specification dependencies can be transferred to other designs. A turbocharger for a petrol engine might differ significantly from a diesel engine turbocharger but may still feature the same specifications dependencies as a diesel engine turbocharger. Dependency network reuse is especially interesting in the case of routine design. In the case of innovative design, any transfer should be carried out gradually. When a piece of data, generated during a new design project, is identified as equivalent to another piece of data previously generated, only immediate dependencies should be transferred, i.e., arcs connected to that piece of data. The same reasoning applies to the transferred nodes. Finally, the DEPNET solution has to be integrated, first with the CO2MED tool [28] already developed within the CRAN laboratory to manage conflict resolution, and second with a Product Lifecycle Management (PLM) environment.