Development of control mechanisms to support coherency of product model during cooperative design process

J Intell Manuf (2010) 21:539–554 DOI 10.1007/s10845-009-0237-2

Development of control mechanisms to support coherency of product model during cooperative design process Mohsen Sadeghi · Frédéric Noel · Khaled Hadj-Hamou

Received: 9 January 2008 / Accepted: 2 January 2009 / Published online: 20 January 2009 © Springer Science+Business Media, LLC 2009

Abstract Product development became an increasingly collaborative and distributed activity. Collaborative design process gathers experts from different backgrounds and areas for a common objective about product development. An effective exchange support is expected to share and integrate design knowledge avoiding conflicts between designers. The management of heterogeneous product representation is a major step to integrate expert activities. To successfully manage this process, this paper proposes: (1) A research experimental platform for cooperative design in product development processes. (2) A new constraint based model to maintain complex relationships in multi-disciplinary cooperative design. (3) A model differentiation technique, which identifies differences and conflicts between models. (4) A Meta-rule concept, which controls the constraint network in design process, leading to a new notification mechanism to present conflict to all corresponding actors.

objective for product development. Cooperation between experts requires a detailed study of integration and collaboration of their viewpoint. Advances in design modelling, computer networks and information technologies (IT) provide new opportunities to support and optimise this activity. Several solutions are provided to achieve this goal; integrated design model (Tichkiewitch 1996) is defined to organize a multi-view access to the product definition. It assists multiple tools, and multi-view editing which in turn allows experts to work with design components at different levels of abstraction, around a unique model, avoiding the necessity to translate information at every design analysis. There are two major approaches for designers to share and to exchange integrated design information:

Introduction

• With the direct exchange approach (Okada and Tanaka 1998) heterogeneous tools exchange different representations through standards such as STEP (2008) • With the indirect approach, generally involving a shared model server (Krause et al. 1993; Noel and Brissaud 2003), in which every designer application is integrated into a single system in order to provide a common understanding of design.

Collaborative design is a distributed activity that gathers experts from different viewpoints to realize a common

Two types of frameworks provide the support for shared model server collaboration:

Keywords Cooperative design · Integrated model based design · Design constraints · Comparison of models · Conflict notification · Synchronization

M. Sadeghi (B) · F. Noel · K. Hadj-Hamou Laboratory G-SCOP, INPGrenoble, UJF, CNRS, 46, ave. felix viallet, 38031 Grenoble Cedex 1, France e-mail: [email protected] F. Noel e-mail: [email protected] K. Hadj-Hamou e-mail: [email protected]

• Synchronous control framework (Zha and Du 2006) allows concurrent manipulation of a unique shared model by several designers. Changes made by one developer in his view of the shared model are immediately reflected in the view of other related developers. • Asynchronous versioning control framework (Hicks 2004) allows the creation of alternative designs as different

123

540

copies of shared model, and requires tools to merge alternative versions. In an asynchronous access framework, designers copy a part of the shared model into a private space in order to get a stable version of information. Synchronization systems should be developed to detect, monitor and to resolve conflicts between experts while modifying the shared model (Habtemariam and Marwala 2005). In this framework, a first approach to avoid the creation of conflicts in concurrent access to the shared model is to serialise model changes with respect to arrival time. The last request imposes its choice without argued rational. A second approach forbids concurrent accesses by a reservation process. A check-out/check-in procedure is then applied. In this paper we study the methods to provide assistance for asynchronous version framework, already used in software development for supporting design activities. The synchronization tasks propagate a design change in the current models into alternative models (versions).

Research background One of the actual issues in organization and optimization of collaborative design activities is development of way that allows to control and to evaluate the consequences of changes in the design environment. The engineering change management (ECM) (Hong and Hyung 2006; Horvath and Rudas 2007) is carried out to ensure the change awareness (Tam and Greenberg 2006) and the convergence of design activities, which are spread over multiple actors, multiple locations, and multiple technological and social cultures. Early studies of computer tools for ECM have focused on (a) change tracking (Xie 2001) and configuration management (Huang and Mak 1998) systems which determine, how products are configured and changed throughout a product’s lifecycle (b) Conflict detection (Klein 1991) or consistency maintenance (Bronsvoort and Noort 2004) systems that implements control processes associated to design environment for monitoring ongoing conflicts. The purpose of these studies is to ensure coherency between experts by providing rich change information, which is communicated to the affected experts. To handle ECM two types of approaches can be differentiated (Do and Choi 2002): (1) The structure-oriented approach, which uses internal structural changes between different versions of a design document to understand its evolution during the development process. There exist a number of algorithms for detecting structural differences between two documents, the chosen differences algorithm depends

123

J Intell Manuf (2010) 21:539–554

on the kind of data: (1) the algorithms which compare unstructured data (Myers 1986) which do either not have a data structure, such as audio, video and unstructured text documents (2) the algorithms which compare the structured data (Chawathe and Rajaraman 1996) which comes from a relational database (UML class diagrams, XML documents, data in CAD databases). Engineering data are often represented as trees or graphs structured documents. The tools, which compare engineering data, try to find a sequence of operations (insert, delete, modify a node or a relation) which transform one document (tree or graphs) into other. For example, with Pro/ENGINEER Wildfire and Pro/INTRALINK (PTC 2008), expert can achieve even better part comparison and difference reporting to highlight and detail the differences between two parts. They can accurately track changes to Pro/ENGINEER files including the version, revision, and lifecycle, but cannot capture the types of changes within the Pro/ENGINEER model files. Change representation and analysis in this approach are limited to comparing algorithms, which exploit same type of data structure. They are not supported by knowledge-based assistance to highlight the technical conflicts between experts. Obviously, integration of design specific constraints can help at this task. (2) The process-oriented approach, which focuses on implementing, standardised processes to manage EC and its data. It usually uses electronic document management systems to process engineering change requests and to keep the consistency of the documentation that are affected by the EC. Then constrained processes are organised to forbid the parallel edition of a same model with some well known “check-in/checkout” like processes. Recently, Product Data Management (PDM) and Product Lifecycle Management (PLM) systems based on workflow systems have been proposed to provide a wide set of functionalities for sharing files issued from various expertises for supporting the entire engineering change process. They typically support the concept of versions (or sequences) and revisions (Liu and Xu 2001). A new version is typically created each time a CAD design file is modified and checked-in to the PDM/PLM system. Revisions, renames, save as, etc is typical features that the CAD integration supports so that the CAD data files are fully controlled, managed, and product structure integrity is maintained in file level. Change management in such systems are unsecured respect to model coherency that should be edited simultaneously by several designers. These systems facilitate and organise the exchange of information but does not support change awareness respect to represent the internal structural changes between different versions of a design document.

J Intell Manuf (2010) 21:539–554

In this scope modelling methods proposed in this paper are aimed to bridge the structure-oriented (operational level) and process-oriented (organizational level) aspects of change management in collaborative engineering design. Most process-oriented of design systems are not able to automatically track all the impacts of a design change. It requires functions to model and to link design objects but also to handle design constraints as design specification. In this paper a generic process is used to integrate design constraints, which are applied in technical objects represented in product model. To illustrate our approach we present a scenario for collaborative design of an electromechanical relay in section “An collaborative design case study”. The experts try to organise solutions to these issues around a unique language for product definition to support collaboration. The chosen language is then imported in a common platform is defined in the section “An environment for cooperative design”. This platform provides an object-level multi-versioning approach to support the asynchronous collaborative design activities. The experts use this platform to store and exchange the information finally to create the relay product model (Section “Relay product model”). In section “Constraint model”, we discuss constraint management (Lottaz and Sam-Haroud 1998) as a knowledge-based assistance to achieve a dynamic model providing functionalities to support change management issue. We will use this assistant to highlight the technical conflicts between experts in change management process. We analyse a range of existing constraints in collaborative product development process, which can be used to address inconsistency measurement issues. Section “Product and constraint models evolution” gives an overview of the model evolution and the change management concept in design process. In section “Comparing models”, a methodology for structure-oriented aspect of change management is explained. It includes a model differentiation technique, which provides the capability to identify differences then to extract conflicts between models. This allows the consistency maintenance for collaborative design to be addressed in section “Incoherency detection”. Subsequently, the model differentiation technique is implemented in a relay example in section “Implementation”. This will be the base to prepare the synchronization phase, which is not focus of this paper. To determine a control mechanism for models evolutions, a concept of meta-rules is proposed in section “Meta-rules and meta-constraints concept in delta control mechanism”. It indicates the cost of changes and their impacts in models evolutions to determine how and when change processes take place (time of models synchronization). The paper concludes with summary of the results and presents further research steps in section “Conclusions and perspectives”.

541

An collaborative design case study To illustrate the proposal, we present a scenario for design of an electromechanical relay. The study of this example allows us to better understand which kinds of tools and methods could be required for an effective cooperative design, which in turn requires several steps (Fig. 1). In fact, an important step of the relay design process consists in the exchange between electrical and mechanical experts. They have a different point of view to solve design problems and different simulation tools that do not manipulate the same concepts, information or parameters. To manage the collaboration between experts a product model is proposed as a unique language for collaboration around product definition (Krause et al. 1994; Tichkiewitch 1996; Liang and Guodong 2006). A first step provides a product model generic enough to support collaboration for any technical expertise. Many product models have already been defined in the literature. They are more or less complex and specific to some design area. We currently use the PPO shared model (Noël and Roucoules 2007) issued from IPPOP project (Robin et al. 2007; IPPOP 2008) to implement the proposed framework. The PPO model integrates product, process and organization concepts to deal with every design views. It is dedicated to collaboration purpose as multiple representations, shared attributes setting, etc. The product model (Fig. 2) proposed in this project will be used to declare and to check the constraint network, defined on a collaborative design shared model. In PPO, entities selected to product definition are: • Components: a component is a partition of the product. It is divided into a set of sub-component. There are three kinds of components (1) Common Components (CC) define the concrete components (2) Alternative Components (AC) are decomposed into optional sub-components (3) View Components (VC) are decomposed into several points of view to represent a specific view by a sub-set of designers.

Fig. 1 Collaborative product design situation

123

542

J Intell Manuf (2010) 21:539–554

Fig. 2 Representation of PPO Product meta-model

• Interface: an interface is a handler of a component and a property by which the component may be linked to an interface of another component. A component may have mechanical, electrical, etc. handlers. Like components there are three kinds of interfaces: (1) Common Interface (CI) (2) Alternative Interface (AC) (3) View Interface (VI). Interfaces can also be subdivided into sub-interfaces to detail their definition. • Function: a function links at least two components through interfaces. It is a relation between the components. The function defines an objective to be achieved. Functions could also be divided in three kinds: (1) Common Function (CF) (2) Alternative Function (AF) (3) View Function (VF). For the definition of detail, functions are subdivided into sub-functions. • Behaviour: Behaviour defines a model state inside the product lifecycle. Behaviour is defined by a set of components, interfaces, and functions. The corresponding structure attributes should be jointly determined by all the related experts to determine the product definition. All these concepts define the main characteristic of the product model. As a technical issue, the product model is a database storing definition of these features and their relationships.

Fig. 3 GAM environment snapshot

candidate meta-model. It is an integrative environment that provides the ability to connect new expertise viewpoint without modifying GAM environment. The framework could be used to compare them and to modify them with respect to the practical point of view. GAM is based on three-layered architecture, the lowest layer, Model, contains particular model developed by final user, and consists of a set of linked entities in the design information layer. The Meta-model layer determines the structure of a particular model. Finally, the Meta-meta-model layer describes the structure of the meta-models, and provides some application protocol interfaces in several computer languages. Instantiating the GAM meta-meta-model provides either new meta-model description or conformed models. It is a shared database and a bundle of compatible modules dedicated to collaborative engineering design support. Simultaneous evolution of models and meta-models should be traced, versioned and managed to seek the analysis of designer actions. GAM also takes in charge the distribution of meta-models and models through Internet connection between server and client side applications.

An environment for cooperative design

Relay product model

To validate our study we use the GAM framework (GAM 2008). The GAM framework is developed at G-SCOP laboratory to experiment such model and their dynamic evolution (Fig. 3). It provides tools to manage information used along the product life cycle. Many research works (Baïna et al. 2007; Krause and Kaufmann 2007; Cechticky et al. 2004) are already interested to define integrated meta-models with a similar goal as GAM. The intention in GAM is to build a very generic modelling framework enabling the easy management of every

Figure 4 shows a simple instantiation of product Meta-model for the electromechanical relay example in GAM environment. In the tree, the main component named assembly conforms to a component type of PPO meta-model. It is decomposed in sub-components tree, the cylinder head, the body, the plunger, etc. As shown in Fig. 5a, the coil component is decomposed in sub-component, the iron core and coil winding. The iron core has an attribute h9 with value equal to 4. The coil winding

123

J Intell Manuf (2010) 21:539–554

543

Fig. 4 a Product meta-model. b Electromechanical relay model

has two interfaces, coil winding electric interface and coil winding material interface. The main function is decomposed in sub-functions, the positioning and fixturing, and the movement function (Fig. 5b). Movement function contains the attributes, which are represented in the equations of physical phenomena acquired during the movement of plunger. The structure features are linked to their interfaces while interfaces are associated to the functions. At last, functions are linked with components fulfilling the function. The multiple view of experts are realized by inheriting the attributes of components or functions and adding the own attributes of the view. To maintain consistency among multiple views is the key for cooperative design. As stated above, product model consists of some design entities. Therefore maintaining the consistency among different views implies mainly to maintain the consistencies among these entities in different views. In multiple view collaborative design, experts work independently. They are not able to respect interdisciplinary constraints and rules, so conflicts are generated. In a collaborative design system, experts remain misinformed of the creation or existence of such conflicts. We assume that the management of inconsistencies and conflicts could be improved if the integrated design system uses a real time conflict detection system in order to detect syntactic

conflicts between different views (Habtemariam and Marwala 2005). A key aspect is to analyze the impact of one entity modification on other entities. Explicit relations are directly deduced from the entity relationships, integrated in the shared model. Nevertheless more complex links should be undertaken. Many models formalize these links through identification of constraints as design specifications. If we consider design representation as a network of design entities and designer knowledge as a set of constraints applied on the previews network, conflicts are then seen as violated constraints in the design problem, to be solved in a collaborative approach. When an expert edits his design view, changes are propagated to a shared-reference model. The propagation generates constraints among design entities. Thus conflicts are detected when constraints are violated in some way. Experts will require facilities to configure when and how conflicts should be detected, monitored, stored, presented, and possibly automatically resolved (Gates and Mondragon 2002). Methods are needed to check violated constraints, to represent the relative importance of conflicts and to record them for monitoring and later resolution. The system selects notification strategy (Cao et al. 2005; Strom and Banavar 1998) according to detected conflict. Experts also require support to negotiate the resolution of conflicts. For example, in relay design, the electrical, mechanical and manufacturing experts have different constraints to size the body

123

544

J Intell Manuf (2010) 21:539–554

Fig. 5 Example of component and function representations

and define the air gap dimension among the body and the plunger. As a result, to maintain consistency among multiple views is a key point for collaborative design. The collaboration model is based on design objects and associated constraints across various nodes of the design network. Practical ways to represent design constraint in cooperative design environments must be considered. Constraint model In engineering design, constraints may formalize: (1) special design requirements that must be satisfied; (2) logic reasoning activity of experts; (3) dependency between design functional requirements, (4) design parameters and components in shared model and (5) flow of information between experts to support interdisciplinary cooperation. Many cooperative design frameworks have been developed to represent multiple view of product development. However, none of them support every design constraint definition and the range of inconsistency management requirement outlined in the previous section. Ram (1997) proposes an object-oriented model for collaborative design based on objects and constraint metaobjects. In his proposal, each design object has an associated constraint space consisting of one or more constraint metaobjects. Any internal state of design object is controlled by

123

constraints in its constraint meta-objects. This model provides a flexible environment separating constraints from the class definition in which it can be inserted, deleted and modified without modification of the application program. The approach proposed requires the manual programming in C++ for capturing the objects and constraint meta-objects. Goonetillake (2002) describes the framework based on the concept of the Constraint Version Object (CVO) to provide an integrity mechanism among object versions. Each CVO contains a set of integrity constraints that must be satisfied for a version of a particular object. The components of the object and associated CVOs are distributed across the system. The CVOs have been categorized as local for sub-components for objects in local workspace and global for configurations of complex objects in global workspace. The separation makes it easier to check data consistency and to manage constraint changes. Roller (2002) proposes the Active Semantic Network (ASN). ASN is an active, distributed, and object oriented database system that supports the definition of constraints that are evaluated by a rule-based system. Constraints are used to model any kind of dependency between product data. ECA rules linked to a constraint object specify the active behaviour of the constraint and are evaluated at run-time. According to ECA rules, a constraint object consists of three components: an event, a condition and an action. As soon as an event occurs over an entity under certain conditions,

J Intell Manuf (2010) 21:539–554

545

mathematics rules could be applied. They are expressed declaratively in some specific languages. Various constraints can be implemented by specialising the simple and complex constraint classes. Simple constrains

Fig. 6 Constraint meta-model

an action is automatically executed propagating new events. In some cases agent policies may be used to automatically answer to events. Since some actions are not automated, human may be involved in the constraint propagation by notification procedures. In Wang’s work (2004), a “Universal Linkage Model”, is developed to represent design related information for mechanical products in a distributed form. It incorporates geometric constraints with traditional geometry and topology elements. It provides a unified constraint representation for detailed design and design optimization. Corresponding interval constraint solving methods are studied. However, these researches only consider value-based constraint and do not involve other type constraint. There is no mechanism to control constraint network and to track the design changes during the modification of other expert’s version. Figure 6 shows an extension of a constraint meta-model that addresses some special requirements to be considered in engineering design constraint representation. A constraint is defined by: • The list of design entities concerned by constraints: An Objects_ppo attribute is used to link constraints to the associated design attributes. • A type attribute is a logic representation of constraint type in design. • An info attribute provides some information about constrain definition and modifications history. • An activation attribute is a Boolean type. The value ‘true’ indicates that constraint is active in verification process and the value ‘false’ indicates that constraint should not be verified. • A constraint expression has a type and belongs to a simple or complex structure: Constraints are either implicit and require to be evaluated on a fuzzy mode by designers; or they are explicit when

• Value control can have continuous or discrete range: One value control: a continuous variable have been implemented as a range of numerical values specified by a Min, Max and an operator attribute which can be an interval to be used from Min value to the Max value. In the relay example relay Opening_Time must be between 0s and 4s (Min = 0, Max = 4, operator = Min: ]; Max: ]), Opening_Time ∈ ] 0; 4 ]. Discrete value list: discrete variables have been implemented as a list of possible (∈ list) or impossible (∈ / list) symbolic, numeric or interval values. For example Body_Material ∈ {steel, aluminium, iron}. • A mathematical constraint is an equality expression of numeric variables. For example:   E(Hmax ) = 1/2k (L0 − L1)2 − (L0 − L2)2 + mg(L1 − L2) where E(Hmax) is the energy of spring at the upper position of the plunger which depends to the spring constant (K), the length of the relaxed spring (L0), the length of spring at the lower position of the plunger (L1), the length of spring at the upper position of the plunger (L2), the mass of plunger (m), and the standard gravity (g), • Two-value constraint describes a relationship between two numeric variable values, which are associated by equality or inequality operators. For example F (Hmax) > F (res), where F (Hmax) is the force of spring at the upper position of the plunger and F(res)is the residual force of the relay at the upper position of the plunger. • R-implicit constraint: is an implicit representation of relation between to design object that cannot be expressed as a mathematical or logical form. It must be considered during constraint verification process. For example the relation between screwing function (sub-function of positioning) and thermal analysis attribute (attribute of cylinder-head component). • Object-Importance constraint describes the importance of design object in design process. When the modifications affected to this object property, the constraint must be considered during constraint verification process. In relay example, the air gap constraint, which defines dimension among the body and the plunger.

123

546

Complex constraints • Compatibility constraint defines a set of compatible values among symbolic, numeric and/or interval variables: for example the list of compatible values between Spring_ Material (symbolic variable) and Spring_k (interval list variable). • Production rule constraint defines an IF…THEN…ELSE expression. With the definition of constraint categories, the system provides the suitable constraint verification methods. It allows specifying which constraint representation approach is possible for each design view. Figure 7a presents the Constraint modelling architecture. The information can be captured

Fig. 7 a Constraint modelling architecture. b Example of constraint representation in GAM environment

Fig. 8 Example of the constraint model

123

J Intell Manuf (2010) 21:539–554

through a graphic user interface and operated by a specific processor, which retrieves the product model and constraint meta-model information for the user. The objective of a constraint-modelling tool is to generate constraint model (Fig. 7b) as output that can be used in constraint verification engine. The examples for relay design are given in Fig. 8. CM-(E(Hmax)) is a mathematical constraint between E(Hmax) attribute in movement function (it is represented in the sub-functions tree of product model) and related spring component’s attributes (k, l0, l1, l2 and m.) which presented by MathExpression. C-(opening time) is a one-value control constraint, which present the maximum and minimum value of opening time attribute of movement function.

J Intell Manuf (2010) 21:539–554

547

The aim of the proposed approach is to allow experts to express all technical and non-technical constraints through a collaborative phase of the product design. Each constraint must be satisfied throughout all design phase or at the beginning of some particular phase of the design. Expert holds specific view of design that allows him to track the evolution of the product and to determine whether some constraints, in relation with his own view or design requirement have been violated. Product and constraint models evolution The design process is evolutive and therefore models/ constraints are created, removed or changed frequently (Fig. 9). It is important to find out how product based model evolves during design process and how and when change processes take place (time of models review and check). The product and constraint model are used to store and exchange data. An extension of the based model is the versioned model of Fig. 9. Designers produce versions of the based model during an extended phase of evolution. Detection of changes between model base and modified version is an important function. Designer is interested to know how each model has changed since the last visit of the base model. The models changes introduce new requirements into an existing based model, or modify the based model if the requirements were not correctly implemented. All considerable changes in each designer’s version will be implemented in the future new base version during synchronization process. The difference between the base model and the modified models () increases gradually (Fig. 10); the control mechanism is required to evaluate  at defined time intervals. Differences must be measured to obtain the effects of models evolution for different versions. The most general goal of a model evolution is to reveal what exactly happens during the design process, to find out when designers should synchronize the models. The final difference is unimportant for the system until a certain limit. At this limit, the control system informs the experts that it is time

Fig. 9 Model evolution in time

Fig. 10 Definition of delta limit

Fig. 11 Design process and model evolution

to synchronize the models. If divergence grows up beyond this limit, the synchronization would be difficult. The synchronization may not be automatic and requires expert negotiation. This paper is considered only conflict evaluation is under consideration; not the synchronization process. To determine this limit, a concept of meta-rules is proposed. It measures the impact of a model evolution, this measure indicates the cost of a change and if it is to be undertaken at all. Figure 11, shows the design process and model evolution dynamic. When starting the product development, few constraints introduce high degree of freedom in solution selection. During development phase the constraints increase and degree of freedom becomes poor. The whole process of design specification can be thought as specifying constraints up to the final solution. Any evolution of models, which satisfy the full range of such constraints, is an acceptable solution.

123

548

J Intell Manuf (2010) 21:539–554 Conform to Enterprise Meta-models Product Meta-model Enterprise models

Conform to GAM (Meta Meta-model)

Constraint Meta-model

Generation of

Conform to DIFF Meta-model Induces

Conform to

Added Model elements

Deleted

Model base

Fig. 12 Modifications detection

Comparing models Within GAM-PPO (the implementation of PPO under GAM), a designer copy a related part of the shared PPO and constraint model into a private space and edits the copy (Fig. 12). Once he has finished the modifications, he synchronizes the private copy with the original shared PPO and constraint model located at the shared space. Synchronization enables his modifications to be integrated with other concurrent modifications that have been made by other experts. The synchronization process requires two main steps. The first step, “ calculation” (difference between two versions, noted diffi), enables the extraction of modifications () made on a private copy. The second step, “ integration”, enables the integration of  into the shared model. If (Mb, Cb) is the shared model and related constraint model, and (Mi, Ci) is the copy of expert i (Fig. 13). The models (Mb, Cb) and (Mi, Ci) are conformed to the enterprise meta models (product and constraint meta models), their difference are conformed to the DIFF meta model that can be automatically generated by using enterprise meta-models. The DIFF meta model is provided to represent the differences between “model base” and “expert i view model” as an diffi model. The first step towards this goal is to understand the types of modifications and the ways in which they affect the model base. The types of modification can be represented as added elements, deleted elements and changed elements. The DIFF operator calculates the difference between two models version: diffi = (Mi − Mb , Ci − Cb )  diffi difftotal = Generic algorithm compares two models and returns a new model, which conforms to Diff meta-model and identifies differences between both models. The diff model provides information about insertion, deletion or property changes in design objects.

123

Expert i view Model

©b

©i

Changed

Updated element

Differences represented by

diff i model

Diff operator

Fig. 13 Difference calculation

To integrate the modifications of every expert to shared model, we define the following operator: (Mb , Cb )new ← (Mb , Cb ) + difftotal  (Mb , Cb )new ← (Mb , Cb ) + (Mi − Mb , Ci − Cb ) In practice, the implementation of this operator is complicated by the fact that the experts may have modified the same objects of the shared model. This operation can lead to incoherencies and it may not be possible to apply all modifications into the final shared model. Incoherencies must be tracked and saved to resolution. At this step, verification of coherency becomes fundamental. Incoherency detection The coherency maintenance is provided by the relationships between entities of the model and associated constraint control mechanisms. Bettaieb (2007) describes the basic conflict matrix to define an incoherency case, where a human or arbitrary decision is expected .The list of conflicts is presented and actions are decided by negotiation among experts. We use these different representations to minimize incoherency during synchronization process. For example in Fig. 10, the set of entities or attributes created in M1 are not affected by an operation in M2 because every created entity has a unique Id. So all created operations in M1 are valid. Entity and attribute deletions or modifications are a source of conflicts. Conflict occurs when an entity is deleted in M1 but not in M2 and when same attribute is modified with different values in M1 and M2. Other conflict cases occur, when modifications can become the cause of interdisciplinary constraint violation conflict. Verification of interdisciplinary constraints becomes fundamental to represent coherency state within concurrent version and base model.

J Intell Manuf (2010) 21:539–554

When an operation relates to an object, diff is used to determine which part is actually changed. If operation is relevant to an object x1, then we can find other related objects through the dependency relationship among them. The constraints related to any object in this dependency relationship must then be verified and represented. To evaluate coherency, functions such as find(x) and evaluate(x) must be provided. The function find(x) uses the diff model to find the modified entities and corresponding constraints, which were modified. The function evaluate(x) asks for a set of objects parameters to evaluate constraint. The implementation of the evaluate (x) function depends on the constraint type. For example, the find(x) function of math equation constraint finds the PPO object values for set of inputs and output parameters in the math-expression. The evaluate(x) function sets given input parameter in the math-expression to compute an output parameter corresponding to the constraint model. As result, asynchronous cooperative design must be facilitated using model evolution analysis tools. It should enable designers to compare their current model with, based model or other designer’s models. It should also provide designers with information about insertion, deletion or property changes in design objects. Designers must select modifications to keep and the modifications to reject respect to a common negotiation.

549

Fig. 14 Difference meta-model

Implementation Going back to the relay example, electrical and manufacturing expert copy a related part of the shared PPO and constraint models into a private space. Once they finished the modifications they must compare their private copies with the shared PPO model. Their objective is to capture models modifications as differences. We propose the diff meta-model shown in Fig. 14 to represent the differences themselves as models (Fig. 15a). The diff contains a set of modification operations, which are described by creating, deleting and modifying an entity or a constraint object in product or constraint model. As product models, must respect multidisciplinary constraints, diff mechanism detects the constraints related to entity and operation that result in violation. Given two corresponding objects in shared model and private copy model, if their property values or names are different, then a modify operation is generated. The constraints related to modified object are verified and be represented in diff model. Figure 15b present the value modification of attribute l0 (type = C-attribute). Value in side one (l0 = 10) is a value in model base and value in side 2 (l0 = 12) is value of l0 in modified model.

Fig. 15 a Diff result model. b Object value modification. c Related constraint to modification representations in diff

This modification will be affected also in three related constraint (Fig. 15c), which use the “l0” as a parameter in constraint representation. Constraint-1 is a mathematical constraint, so evaluation of this constraint will cause the value modification of output attribute (E(Hmax)) related to this constraint. Created object in a private copy has no corresponding object in shared model. Within a diff representation, the exact location of the deletion must be identified. Figure 16 present an example of new component insertion. The part2 is added to fixing part, which is also new component in modified version. The deleted objects are the ones in shared model that have no corresponding object in private copy. For example the

123

550

J Intell Manuf (2010) 21:539–554

Fig. 16 Object insert representation in diff Fig. 19 Example of diff overview result

Fig. 17 Object delete representation in diff

h2 attribute. The material attribute represents the material of relay body. The h2 attribute represents the thickness of relay body. The material used for relay body must be compatible with thickness dimensions of body. The function evaluate (x); return a “true” value, to indicate that constraint is violated (selected material is not compatible with value property of h2). • Constraint-2 is the one value list constraint, which defines a list of possible material values (Material ∈ {steel, aluminium, iron}). The verification of this constraint return a false “value” to indicate that Constraint is not violated (iron is included in list of materials) All differences are registered in diff-result-model then the differences overview is reported in model (Fig. 19). The system produces such a diff-result model for every copy. These result models are reported as models evolutions information during synchronization process.

Meta-rules and meta-constraints concept in delta control mechanism

Fig. 18 Object Value modification example in diff model

attribute G in Fig. 17 is a c-attribute, which was removed from location 8 of sub-component spring. Figure 18 shows another example of value modification in relay design. The value property of material (Component attribute) in model base is “steel” and its value property in modified model is “iron”. The find(x) function finds the modified entity (material) and corresponding two constraints which are used material attribute in their definition: • Constraint-1 is the compatibility constraint, which defines a set of compatible values between material attribute and

123

We promote a new framework that takes in count the context of the meta-rules and Meta constraints over design objects and constraints to provide the control mechanism (Fig. 20), which has been extended by a special sentence to calculate final difference. Meta-rules can easily be extended to deal with interactions as well as associations with methods used to determine the control mechanism states. Meta-constraint defines a rule on constraints and can be derived from design policies. The main issue in metaconstraints (Petit and Regin 2000) definition is the control of constraint network and conflict resolution in collaborative design environment in order to get realistic solutions. Constraint model is the set of hard and soft constraints that define the relationships among different attributes of components in shared model. The hard constraint must hold for all solutions, while the soft constraints should be satisfied if possible. Generally, soft constraints do not have the same importance in

J Intell Manuf (2010) 21:539–554

551

Fig. 20 Delta control mechanism

Fig. 22 Change impact analysis and the actions supports for informing experts

Fig. 21 Meta-constraint

a design process and sometimes there are different ways to violate a constraint in order to get realistic solutions. To support the constraint network control, it is necessary to build a rule model that controls the constraint network in collaborative design environment. In this system, there are default control mechanisms between all constraints or rules and overriding expert defined control mechanisms between particular constraints or rules. Expert-defined controls are evolutive: new control mechanisms may be added and existing control mechanisms may be modified, deleted or altered. The control mechanism determines (Fig. 21): • Priorities, given two or more violated soft constraints; a conflict resolution mechanism determines which constraints have more importance in a problem. • Degree of violation, it is important to emphasize that the design process may violate soft constraints to varying degrees in order to ensure a theoretically feasible and realistic solutions. In contrast, hard constraints cannot be violated during design process because their violation implies theoretical infeasibility. • Dependences, with a special condition, for example, it is sometimes interesting to activate new constraints to the network when certain violations appear or if some soft constraints are violated then some others soft constraints must not be violated. With the definition of meta-constraint categories, the system provides the suitable meta-constraint verification methods.

…

µ1

µ2

Operation on model/ experts

Expert 1 (diff 1)

Expert 2 (diff 2)

λλ1

nbof nb ofvalue valuemodification modification

nb11=4

nb21=3

nbn1=2

λλ2

nbof nb ofname namemodification modification

nb12=0

nb22=1

nbn2=3

λλ3

nbof nb ofinserted inserteditems items

nb13=7

nb23=0

nbn3=4

λλ4

nbof nb ofdeleted deleteditems items

nb14=1

nb24=3

nbn4=1

λλ5

nbof nb ofviolated violatedconstraint constraint

nb15=2

nb25=5

nbn5=3

λλ6

nbof nb ofnew newconstraint constraint

nb16=1

nb26=0

nbn6=2

nbof nb ofmodified modifiedconstraint constraint

nb17=2

nb27=0

nbn7=1

λλ7

f1=F(λ j, nbij, µ i)

i=1,…,n

…

µn Expert n (diff n)

j=1,…,7

Fig. 23 Calculation of syntactic delta

Usual rules and constraints addressee the technical designer knowledge formulation, while meta-rules and metaconstraints will provide a process management view of design activities. The delta evaluation focuses on characterizing, modelling, and optimizing the interaction between diff calculation and constraints and meta-constraints verifications. The system produces a differences model for every copy of “expert i model” (Fig. 22). The change impact analysis focuses on verification of meta-rules to produce the actions supports for informing experts. Based on the diff results (Fig. 23), number of inserted objects or constraints, number of deleted objects, number of value modification, number of violated constraint and etc., the change impact analyser is defined as: final = fM−R (f1 (diffi) + f2 (©i|diffi)) Where f1 is the combination of different functions and meta rules which evaluate and control the content difference value between version and based model. The f1 is the userdefined function:   f1 = F λj , nbji , μi

123

552

J Intell Manuf (2010) 21:539–554

where λj is a factor that weights the importance of a specific diff operation (insert, delete, modify, violated constraint, new constraint, and modified constraint), nbji is the number of a specific entities in diff result model for expert number i and μi is a factor that weights the importance of each expert in collaborative design. We present f1 as:  f1 = λj ∗ nbji ∗ μi Experts set weighted parameters values according to a cost of each change operation and importance of each expert in design process. For example, the deletion of an object may affect the several expert models, so the deletion operation is ranked as the most costly operation in model changes. However, future studies should be applied to determine, how to fix these factors. Where f2 is the function which takes constraint states {violated or not violated} and evaluates the meta-constraint conditions, final is the meta- rules (fM−R ) which control the models evolution state according to union of f1 and f2. If final detects a meta-rules violation that defines the delta limit, it will proceed with the violated rule resolving plan and every concerned designer should be notified about the model reviews necessity. Figure 24 shows some examples of metarules that are considered in delta evaluation. The condition part of Rule1 contains a special limit that controls the value of f1: Figure 25a shows, the concept of meta-rules to support evolution of cooperative product model design. The Meta-rules control system monitors the constraints and syntactic modification and relevant meta-constraint and

Fig. 24 Meta-rules/constraint concepts in control of final delta

123

Fig. 25 Meta-rules/constraint concepts in control of final delta

rules states in certain periods of times. If the states of metarules are violated, then system will display a notification message to every connected expert in the cooperative design process. Models must be synchronized at two periods, which occur simultaneously in the two time-series (Fig. 25b): • The fixed, models review times R, which concerns the models review during the life of project periods. • The notified, models review times T, which takes place between the two fixed review times when the meta-rules control system detects a meta-rule violation condition. Obviously, this process must be scheduled along the time. At this step we imagine several options respect to the expected time of our process. For the moment, we propose a simple solution where the periodicity of constraint/rule and metarule/meta-constraint analysis is fixed. We propose an anticipated approach: in this approach, when designer copy a dependent part of the shared model to their private space, GAM collaboration server connect also designer work space to notification management system (NC1: notification client 1) and then to notification server (NS1: notification server 1) (Fig. 26). If difference control system finds the violations of metarules, a notification message is sent to every expert connected to collaboration server (Fig. 27). We call this scheme an anticipated notification scheme (Bettaieb and Noel 2006) because the notification informs collaborators that there are conflicts between the various copies of the model before the designer request a modification (synchronisation) of the shared model.

J Intell Manuf (2010) 21:539–554

553

This multi-connection should provide a way to organize distributed collaboration, each server being on charge to survey a part of the collaboration process.

References

Fig. 26 Anticipated notification schemas

Fig. 27 Representation of the notification message

Conclusions and perspectives In this paper we presented a collaborative design framework architecture that allows the definition and verification of constraints and meta-rules to assist design conflict resolution strategy through the synchronization and negotiation process. We discussed the structure, mechanisms and implementation of the delta calculation and meta-rule concept, which allows the detection, and the management of conflicts in a shared model. The proposed approach differs from already existing works by: (1) dedicated to design and collaborative product development supports (2) granularity of information is less than computer file level. In PDM (Product Data Management) systems only states of files are checked, but users do not access to deeper information (3) all measures of conflicts level is not proposed anywhere. This research was experimented in simple scenario. More complex ones must be now undertaken to validate the approach as feasible industrial solution. The connection of a GAM-Server to other GAMServers can be imagined, but is not checked at this time.

Baïna, S., Panetto, H., & Morel, G. (2007). Towards a product oriented process modelling for enterprise applications synchronisation and interoperability, part VIII. In Enterprise interoperability, pp. 461– 472. London: Springer. Bettaieb, S., & Noel, F. (2006). An anticipated notification scheme to ensure coherency of a collaborative design framework. In Proceedings of the PLM06 International Conference on Product Lifecycle Management, Bangalore, India. Bettaieb, S., & Noel, F. (2007). A generic architecture to synchronise design models issued from heterogeneous business tools: Towards more interoperability between design expertises. Journal of Engineering with Computers, Jun 15. Bronsvoort, W. F., & Noort, A. (2004). Multiple-view feature modelling for integral product development. Journal of Computer-Aided Design, 36(10), 929–946. Cao, J., Zhang, S., & Li, M. (2005). Distributed design process coordination based on a service event notification model. Concurrent Engineering, 13(4), 301–310. Cechticky, V., Pasetti, A., Rohlik, O., & Schaufelberger, W. (2004). XML-based feature modelling. In Software reuse: Methods, techniques and tools, ICSR 2004, LNCS 3107, pp. 101–114. Heidelberg: Springer. Chawathe, S., & Rajaraman, A. (1996). Change detection in hierarchically structured information. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pp. 493–504. Do, J., & Choi, I. J. (2002). A structure-oriented product data representation of engineering changes for supporting integrity constraints. The International Journal of Advanced Manufacturing Technology, 20(8), 564–570. Gates, A. Q., & Mondragon, O. (2002). FasTLInC: A constraint-based tracing approach. Journal of Systems and Software, 63(3), 241–258. Goonetillake, J. S., Carnduff, T. W., & Gray, W. A. (2002). An integrity constraint management framework in engineering design. Computers in Industry, Special Issue: CSCW in Design, 48(1), 29–44. Habtemariam, E., & Marwala, T. (2005). Artificial intelligence for conflict management. Proceedings of International Joint Conference on Neural Networks, Montreal, Canada. Hicks, D. (2004). Towards multi-granular versioning support for collaborative design applications. In Proceedings of 8th International Conference on Computer Supported Cooperative Work in Design. Hong, J. L., & Hyung, J. A. (2006). Capturing and reusing knowledge in engineering change management: A case of automobile development. Journal of Information Systems Frontiers, 8(5), 375–394. Horvath, L., & Rudas, I. J. (2007). Towards intelligent change management in product modeling. International Symposium on Computational Intelligence and Intelligent Informatics, ISCIII ‘07. Huang, G. Q., & Mak, K. L. (1998). Computer aids for engineering change control. Journal of Materials Processing Technology, 76(1), 187–191. Klein, M. (1991). Supporting conflict resolution in cooperative design systems. IEEE Transactions on Systems, Man, and Cybernetics, 21(6), 1379–1390. Krause, F.-L., & Kaufmann, U. (2007). Meta-modelling for interoperability in product design. CIRP Annals—Manufacturing Technology 56(1), 159–162. Krause, F.-L., Kieswetter, & Kramer, S. (1994). Distributed product design. Annals of the CIRP, 43(1), 149–152.

123

554 Krause, F.-L., Kimura, F., Kjellberg, T., & Lu, S. C. Y. (1993). Product modeling. Ann CIRP, 42(2). Liang, C., & Guodong, J. (2006). Product modeling for multidisciplinary collaborative design. The International Journal of Advanced Manufacturing Technology, 7–8, 589–600. Liu, D. T., & Xu, X. W. (2001). A review of web-based product data management systems. Computers in Industry, 44(3), 251–262. Lottaz, C., & Sam-Haroud, D. (1998). Constraint techniques for collaborative design. In Proceedings of Tenth IEEE International Conference on Tools with Artificial Intelligence. Myers, E. W. (1986). An O(ND) difference algorithm and its variations. Algorithmica, 1, 251–256. Noel, F., & Brissaud, D. (2003). Integrative design environment to improve collaboration between various experts. Annals of the CIRP, 109–112. Noel, F., & Roucoules, L. (2007). The PPO design model with respect to digital enterprise technologies among product life cycle. Journal: International Journal of Computer Integrated Manufacturing. Okada, Y., & Tanaka, Y. (1998). Collaborative environments of intelligent box for distributed 3D graphics applications. The Visual Computer, 14. Petit, T., & Regin, J. C. (2000). Meta-constraints on violations for over constrained problems, tools with artificial intelligence, 2000. ICTAI 2000. In Proceedings of the 12th IEEE International Conference, pp. 358–365. Poon, W. (1994). Modelling a distributed database system. In Proceedings of the Conference of the Centre for Advanced Studies on Collaborative Research, Toronto, Canada. Ram, D., & Vivekananda, N. (1997). Constraint meta-object: A new object model for distributed collaborative design. IEEE Transactions on System, Man, and Cybernetics—Part A: Systems and Humans, 27(2), 208 – 221. Riboulet, V., Marin, P., Gowers, S., & Wurtz, F. (2004). A framework supporting collaborative optimisation for multi professional design teams. In Proceedings of the Fifth International Conference on

123

J Intell Manuf (2010) 21:539–554 Integrated Design and Manufacturing in Mechanical Engineering, IDMME, Bath, UK. Robin, V., Rose, B., & Girard, P. (2007). Modelling collaborative knowledge to support engineering design project manager. International Journal of Computers in Industry, 58(2), 188–198. Roller, D., Eck, O., & Dalakakis, S. (2002). Advanced database approach for cooperative product design. Journal of Engineering Design, 13(1), 49–61. Strom, R., & Banavar, G. (1998). Concurrency control and view notification algorithms for collaborative replicated objects. IEEE Transactions on Computers, 47(4), 458–471. Tam, J., & Greenberg, S. (2006). A framework for asynchronous change awareness in collaborative documents and workspaces. International Journal of Human-Computer Studies, 64(7), 583–598 Tichkiewitch, S. (1996). Specification on integrated design methodology using a multi-view product model. In EDSA Proceeding of the 1996 ASME System Design and Analysis Conference. Wang, Y., & Nnaji, B. O. (2004). UL-PML: Constraint-enabled distributed product data model. International Journal of Production Research, 42(17), 3743–3763. Xie, H. (2001). Tracking of design changes for collaborative product development. In Proceeding of Computer Supported Cooperative Work in Design conference. Zha, X. F., & Du, H. (2006). Knowledge-intensive collaborative design modeling and support: Part II: System implementation and application. Computers in Industry, 57(1), 56–71. Zhao, G., & Deng, J. (2001). Cooperative product design process modelling. In Proceedings of the Sixth International Conference on Computer Supported Cooperative Work in Design. GAM. (2008). http://www.g-scop.inpg.fr/GAM/, visited on July 2008. IPPOP. (2008). http://projects.opencascade.org/IPPOP, visited on July 2008. STEP. (2008). http://www.steptools.com, visited on July 2008. PTC. (2008). Parametric Technology Corporation, http://www.ptc.com/ products/proengineer/, visited on Jun 2008.