228
Int. J. Product Lifecycle Management, Vol. 2, No. 3, 2007
Can C-K theory apply to Knowledge-Based Engineering systems? Alaeddine Zouari* and Michel Tollenaere G-SCOP, INP Grenoble, 46, Avenue Felix Viallet, 38031 Grenoble cedex1, France E-mail:
[email protected] E-mail:
[email protected] *Corresponding author
Habib Ben Bacha and Aref Younes Maalej LASEM, ENIS, Sfax University, Route de Soukra BP W, 3038 Sfax, Tunisia E-mail:
[email protected] E-mail:
[email protected] Abstract: The aim of this study is to provide a framework for the development of an interactive system for assistance to collaborative design. This framework provides to designers a tool to formalise design knowledge in order to share and reuse the active resources of the design. The study of domain knowledge models was based on a new theory of design known as C-K theory (Hatchuel and Weil, 2002). This theory is based on the distinction between the concept space and the knowledge space in integrated design. It stipulates that design oscillates from one space to another by co-building the product and knowledge which supports it. In this paper, we implement DeSIgn with KnOwledge VERsioning (DISKOVER) knowledge models as an application of the C-K theory operators. Those models are based on three knowledge levels, which are split into a product models (concepts) and design process models, otherwise knowledge that describe the product. The impact of versioning on the instantiation of DISKOVER knowledge models to C-K design theory was also studied in this research. Keywords: capitalising and reusing knowledge; C-K theory; collaborative design; product models and knowledge models. Reference to this paper should made as follows: Zouari, A., Tollenaere, M., Benbacha, H. and Maalej, A.Y. (2007) ‘Can C-K theory apply to KnowledgeBased Engineering systems?’, Int. J. Product Lifecycle Management, Vol. 2, No. 3, pp.228–252. Biographical notes: Alaeddine Zouari is an Assistant Professor of Mechanical Engineering in the Preparatory Institute to Engineers’ Study (IPEIM) at Elmanar University (Tunisia). He received his PhD in Industrial Engineering in 2007 from both Grenoble Optimisation, Production and Design Laboratory Copyright © 2007 Inderscience Enterprises Ltd.
Can C-K theory apply to KBE systems?
229
(G-SCOP) at National Polytechnic Institute in Grenoble (INPG) (France) and the Laboratory of Electromechanical Systems (LASEM) at Sfax University (Tunisia). His thesis deals with knowledge versioning mechanisms in collaborative design process. Michel Tollenaere is a Professor of Technical Information System and Project Management in the National High School of Industrial Engineering (ENSGI) at the National Polytechnic Institute in Grenoble (INPG). He is a member of Grenoble Optimisation, Production and Design Laboratory (G-SCOP). He has also many other responsibility as a Director of AIP Primeca Dauphiné Savoie. Habib Ben Bacha is an Associate Professor in Mechanical Engineering Department at the National Engineers’ School of Sfax (ENIS), and he obtained his Ability Diploma (HDR) in 2004. He is also a member of the Electromechanical Systems Laboratory (LASEM) at Sfax University (Tunisia), where he is responsible for the research unit on new and renewable energy systems. Aref Y. Maalej is a University Professor of Dynamic System Modelling, Simulation and Analyses in Mechanical Engineering Department at the National Engineers’ School of Sfax (ENIS) at Sfax University (Tunisia). He received his PhD in Mechanical Engineering in 1988 from Ohio State University Columbus. He is also a Director of the Electromechanical Systems Laboratory (LASEM) and the President of the Association Tunisian Scientific Society.
1
Introduction
In a context of collaborative design, many research programmes refer to means of communication and shared accesses to design information by multiple users on geographically distributed areas. This requires the development of knowledge capitalisation and reuse techniques, where generic information and/or particular project information of design are stored and consulted by a network of distributed actors. Various methodologies have been set up in knowledge engineering domain, in order to answer the Knowledge Management (KM) difficulties. Capitalised knowledge is linked to the application domain of expertise. A sharing information tool allows its consultation and exploitation. However, the semantic analysis requires that the information tools ‘understand’ the structure and the lexicon of knowledge. Thus, it can make their implication explicit (checking) and detect possible contradictions (validation). Besides, from an organisational viewpoint, this permits to treat problems bound to the optimisation of the company operations. This is possible through knowledge capitalisation and then exploitation. It can concern the management of competences, the resources (material and human), the processes, etc. Nevertheless, knowledge is permanently modified by the different actors involved in the design process. This implies that, in the Project Library (PL), new knowledge can appear (actualisation, enrichment, etc.) or existing knowledge can be modified (expansion, restriction, change, cancellation, etc.). A large diversity of knowledge can be generated with huge difficulty to be managed, because of ill structured information. To outshine this kind of problems, a new knowledge organisation and versioning
230
A. Zouari et al.
mechanisms have been studied. Versioning is a mean to get the capacity to control modifications and their requisite consequences, also to have a traceability of the design process (Van Leeuwen and Jos, 2002). It is a critical functionality within a framework which treats the multiple KM. In fact, versioning requires a complete available knowledge analysis, which is based on changes presented by the transformation of a knowledge version into another one. Such analysis permits to capitalise knowledge by avoiding possible redundancies aiming to future reuse on other projects. A recently published design theory known as the C-K theory (Hatchuel and Weil, 2002) can be helpful to study the knowledge models and the versioning mechanisms. This theory is based on the distinction between the concepts and knowledge space in a product process design methodology. It stipulates that design oscillates from a space to another by co-building the product and the knowledge that supports it. The C-K design theory is based on existing design theories; however, it reinterprets these theories as special cases of a reasoning unified model. This model allows solving two recurring problems which could not be solved by traditional theories. Otherwise, it offers a lucid and precise design definition and a theory, where creative thought and innovation are not external to the design theory. In Section 1 of this paper, the main features of the C-K theory are briefly presented by defining its four operators and the design square that gives the fundamental structure of the design process. Section 2 describes the principle of our design methodology, namely DeSIgn with KnOwledge VERsioning (DISKOVER), and its knowledge model. Section 3 illustrates the complementarity of DISKOVER knowledge models and the C-K design theory. These theories are further applied to the design of automotive air-conditioning systems. As a conclusion, the interest of knowledge versioning and their management are shown as future research.
2
CK design theory
The C-K theory has been initially proposed by Hatchuel and developed by Hatchuel and Weil (2002, 2003). It is named as ‘C-K theory’, because its central proposition is a formal distinction between ‘concepts’ (C) and ‘knowledge’ (K). The C-K theory allows through the distinction between ‘C’ and ‘K’ spaces, to give account of the dualism between design and training. Thus, it integrates the knowledge expansion, restriction and modifications (updated); knowledge becomes an evolving object as the design artefact is. If such formalism always returns account of an activity based on the declension of the generic model (structure of K space, mobilisation of specific operators), it permits moreover to support collective design reasoning in which these models must be reviewed.
2.1 Distinction between concepts and knowledge spaces Hatchuel, Le Masson and Weil (2004) define those spaces as follows: x
Knowledge space (K) is a space of propositions that have a logical status for a designer. This space is often neglected in the literature, yet it is impossible to define design without such referring space.
Can C-K theory apply to KBE systems? x
231
Concept space (C) is a space of proposition, or a group of propositions that have no logical status in the space K. This means that when a concept is formulated it is impossible to prove that it is a proposition of K. In design, a concept usually expresses a group of properties qualifying one or several entities.
2.2 C-K theory operators The process of adding and subtracting properties or proposals to a concept is a central mechanism of design. It can transform the proposals of K into a concept of C and conversely. The C-K theory stipulates that design oscillates from a space to another by co-building the product and the supporting knowledge. These two spaces have very strong connections that can be seen as four different operators. Two of those operators are ‘external’ CÆK (from C to K) and KÆC (from K to C), and the others are ‘internal’ CÆC and KÆK. The external operators ensure the connection between two different spaces either by disjunction KÆC or by conjunction CÆK: x
KÆC: this operator adds or subtracts properties from K to concepts in C; it creates disjunctions when it transforms a K proposition into a concept. This is usually called generation of alternatives, yet concepts are not alternatives but potential seeds for alternatives (Hatchuel, Le Masson and Weil, 2004). This operator allows the formulation of a concept and expands the space C with elements originated from K.
x
CÆK: this operator seeks for properties in K that could be added or subtracted to reach propositions with a logical status; it creates conjunctions which could be accepted as finished designs. It corresponds to validations methods or tools in classical design: doing a test, an experimental plan, a prototype, a model are the common examples of CÆK operator (Hatchuel, Le Masson and Weil, 2004). This operator expands knowledge K while being triggered by the concept expansion in C.
The internal operators ensure the connection between two similar spaces through an expansion by deduction or experiment KÆK or through an expansion by partition or inclusion CÆC (Hatchuel and Weil, 2003): x
CÆC: this operator is at least the classical rules in set theory that control partition or inclusion. But it can be enriched if necessary by consistency rules in C.
x
KÆK: this operator is at least the classical rules of logic and propositional calculus that allow a knowledge space to have a self-expansion (proving new theorems).
2.3
The design square and C-K theory dynamics
Design is a process generating the co-expansion of two spaces: spaces of concepts ‘C’ and spaces of knowledge ‘K’. It starts by K-C disjunction and ends by one or more C-K conjunctions. This highlights the necessity of the C-K theory operators to establish the whole process. Those four operators constitute the design square. Figure 1 shows the combination of C-K theory operators in the ‘design square’ (Hatchuel, Le Masson and Weil, 2004). It gives the fundamental structure of the design process. It also illustrates the importance of defining design both on concepts and knowledge. This model avoids the classical logic of design stages from ‘abstract to
232
A. Zouari et al.
concrete’ or from ‘rough to detail’. These are too normative positions: ‘details’ may come first in a design if they have a strong partitioning power; and unexpected stages could result from a surprising knowledge expansion. The classical opposition between linearity and turbulence disappears: innovations could result from both. Figure 1
The design square
x
Disjunction KÆC is the operator that allows the formulation of a concept. It marks the engagement of design reasoning. It is generally ensured by knowledge partition, specification, validation or others.
x
Conjunction CÆK is the operator which transforms a concept into knowledge. The conjunction is symmetrical to the disjunction. A reasoning of design can lead to several operations of conjunction starting from only one disjunction. The expansion of space K rises partly from this implementation by activation, discovery, experimentation, experience feedback, etc.
x
Expansion by partition or inclusion is the operator that goes from CÆC. It ensures the decomposition of a concept in others (creation of new sub-concepts) or concepts regrouping.
x
Expansion by deduction or experimentation is the operator which goes from KÆK. Its realisation includes all knowledge acquisition forms known in the space K (consultation of databases, experimental plan, expert consulting, etc.).
3
DISKOVER, a collaborative Computer Aided Design tool
In the early 1990s, KM was first considered as a scientist stake, it has become more and more an industrial stake. Providing performance through KM technologies is a complex problem that can be tackled from several viewpoints: socio-organisational, financial and economical, technical, human and legal. It involves explicit and persistent representation of knowledge of geographically distributed groups of people in the organisation. Using a collaborative design computer-based environment, knowledge can be capitalised in a database often called group memory (Ribière and Matta, 1998). A project memory can be defined as experiences from given projects or as project definition, activities, history and results (Matta, Ribiere and Corby, 1999). As in a corporate
Can C-K theory apply to KBE systems?
233
memory, a project memory must consider project organisation, strategies, environment, constraints, design rationale, etc. (Ribière and Matta, 1998). Such a database allows sharing knowledge between actors involved in the design process, and may serve as knowledge repository for inputs or outputs of each task of the process. MULTI (Menand and Tollenaere, 2001) is a collaborative Computer Aided Design (CAD) tool that has been designed so that the MULTI knowledge model aims to be generic to any product design. This research work has been enriched by knowledge versioning mechanisms, providing improved knowledge handling: this new software tool was called DISKOVER and provides new conceptual principles (Zouari, 2007). It describes the generic knowledge level of the product and its design process. However, it permits the emergence of solutions by the integration of constraints and requirements revealing the product lifecycle (lifecycle phases and situation).
3.1 MULTI knowledge model and its knowledge levels The knowledge model of MULTI is based on three levels. Each level describes both the product and the corresponding design process (Figure 2): x
The upper level is called ‘generic model’: this first level describes the generic knowledge and the nature of functional design. It is independent from any particular technology and routine of redesign problem (Menand and Tollenaere, 2001). The generic level is able, e.g. to support the development process according to a V cycle approach applying system engineering principles. This level is made both of a product and design process models. The product model illustrates the relative entities to a product and their relationships as, e.g. design parameters, features, parts, assemblies, subassemblies, lifecycle phases, functions, sub-functions, parameters, constraints between parameters, etc. The design process model contains the definition of the following entities and their relationships: alternatives in design, actors, roles, activities, tasks, rules, etc.
x
The second level is called ‘domain knowledge repository’: it is built by instantiation of the generic model to a particular domain. It describes the structural aspect of the domain knowledge. This level describes the know-how to carry out the design in a specific technical domain. It has the ability to evolve when new technologies appear. This evolution must be under control by the organisation (Zouari, Tollenaere and Menand, 2002). The second level emerges the fundamental phenomena that must be mastered in the setting of the expert activity for any product of this domain and for its design process. It helps designers to know-how a function is usually materialised, which constraints must be taken into account for a specific phase of the lifecycle, etc. This can be constituted by Excel™ worksheets supporting computing design process model relating to particular task or its resulting parameters. Excel™ worksheets are models of design tasks in several tools. It can also be constituted by ‘generic reports’ (parametric CAD models) on the main research result in the domain of ergonomic standards in automotive industry (Mathelin, Boujut and Tollenaere, 2005). Currently, these pieces of knowledge are often written in a framework and can be shared through the web. The domain knowledge model is split into a Domain Repository (DR) model according to a product viewpoint and a DR model according to a design process viewpoint. Theses constitute a DR applicable to any artefact designs of this domain.
234 x
A. Zouari et al. The third level is called ‘project repository’. It offers a rigorous description of a product (and conversely its design process) belonging to a particular technological domain; the current product is obtained by applying the domain knowledge through a given project according to its specific requirements. The designed product library and the carried out design processes constitute the Project Library (PL) (Zouari et al., 2005). PL capitalises the specific know-how of a project memory. Therefore, it allows illustrating the results of a given project (parameters, experience feed back) and to draw the project progress history capturing the dynamic of the project. Moreover, it can illustrate the project particular requirements, the choices which were retained, the useful rules to each task, the tasks succession, the tasks carried out and those to complete, the knowledge versions, the actors really involved, etc. This level can also contain the ill-structured information (texts, CAD files, sketches, abacuses, notes, etc.) that was not yet formalised. The ill-structured information must be captured during the design process to allow future evolution of the domain knowledge (rules, constraints, etc.). For the projects in progress or to come, this ill-structured information has proved to be very useful for all designers.
Figure 2
MULTI knowledge models
The aggregation of DR and PL produces the General Knowledge Repository (GKR) which represents the finality of our approach. The repository capitalises knowledge of the product and its design process related to a specific domain and a given project (Zouari et al., 2005). The development of such a memory corresponds to a phase of a whole knowledge capitalisation. This requires providing every designer with an adapted point of view on the project (Ribière, Matta and Cointe, 1998) and translating their recommendations into intelligible language for the CAD designers (Eckert and Boujut, 2003). Then, provided with these proposals, recommendations and assessments, the designer will work as far as possible on the integration of all the demands for the next project. A step of knowledge capitalisation sets, nevertheless, problems in terms of identification, redundancy and re-use of this knowledge.
Can C-K theory apply to KBE systems?
235
The DISKOVER knowledge model and its three levels are implemented in a database system. This system can help designers in the capture and the organisation of their specific pieces of knowledge (engineering tasks from process model, from product model and associated knowledge).
3.2 DISKOVER a web-based tool The DISKOVER models have been implemented using a Unified Modelling Language (UML) approach allowing an interactive and easy formalisation of the design specifications. Because it is object oriented, UML provides a set of diagrams which can associate objects that are not usually linkable (Merlo et al., 2005). With a web-based tool, when involved in the functional design process, actors can access knowledge with a dedicated and context dependant viewpoint. They can access to the tasks with the related knowledge compliant with the implemented design process model (inputs, outputs, constraints, etc.). They can access, edit or modify the appropriate engineering product parameters (Tollenaere, 2005). They can address the tasks to be executed (concept of push of tasks) with the associated information and knowledge, and how to execute these tasks (edit the value of a parameter, make an operation of choice, etc.) to allow DISKOVER to update the workflow. With this methodology, the designer gets provided with the right information at the right time (knowledge push) and can maintain and capitalise his knowledge through the design process. Consequently, actors can edit their feedback along the design of a task (post it) (Busby, 1998), update the knowledge on a task, update the lifecycle constraint on a task and modify the implemented product model and the design process model.
4
Relationship between C-K theory and DISKOVER
MULTI/DISKOVER project and C-K theory have been quite simultaneously elaborated and thus have set up their own vocabulary. As knowledge (K) is spread mainly in the two upper levels of MULTI on product and process sides, concepts (C) are welcomed in the product model and in the product representation. This section compares the concepts of DISKOVER and C-K theory. For each level of DISKOVER knowledge model, both the concept and process which produces it can be described. Thus the product model can be seen as composed of concepts, otherwise in technological solution, functions, lifecycle constraint, etc. It can be considered as a space that describes the product. In the same way, the design process model is composed of tasks, parameters, resources, etc. and can be simulated as a space of useful knowledge for the design process execution. A product or an object represents a concept. This concept has a generic model bearing his name without specifying the knowledge which can describe it (e.g. vehicle, air-conditioner, actuator, etc.). More knowledge can appear in the generic design process (example for the air-conditioning system: to establish the heat balance, to choose the components, etc.). The product model may be enriched with knowledge by attaching it to a particular domain. This instantiation permits to refine the description of this concept. As an example for a concept of air-conditioning system, it can be instantiated on several domains (vehicle, dwelling, industry, etc.) as shown in Figure 3. Thus, a DR (product viewpoint) is obtained. It will be connected to a design process model, related to
236
A. Zouari et al.
the same domain. This design process model allows lodging a more refined knowledge (example for air-conditioner for dwelling: heat flow through the walls, wall surfaces, wall orientation, number of windows, number of people, etc.). The design process model must describe the methodology to design the product as well as the various parameters and resources. Figure 3
Example of the knowledge’s presentation of MULTI three levels
In fact at this stage, a concept cannot be described only by a single object. By linking it to a project, its description can be enriched by other pieces of knowledge such as used technology, characteristics (functional and dimensional), requirements, etc. That knowledge can be supported by the designed product library where it will have values, related to the project, for each knowledge being reproduced on the domain design process.
4.1 Disjunction In DISKOVER models, the disjunction corresponds to the connections between the product viewpoint and design process viewpoint domain repositories. At this stage, the product viewpoint model describes the studied system in a generic way. It needs to be enriched by the elements of knowledge that describe the functions to be achieved throughout the various phases of the lifecycle. This model shows, e.g. that an article pertaining to the studied system can be composed of other elementary articles. Each article characterises a technological solution to fulfil a particular function. The articles are also characterised by parameters valued by the function which carries out the technological solution. The later is associated to a life situation which derives from a phase of the product lifecycle (Figure 4).
Can C-K theory apply to KBE systems? Figure 4
237
Class diagram as relationship between article and some knowledge
DR, from a product viewpoint, allows the description of the structural and functional tree structure of the system. Other knowledge will be added (grafted) during the design phases upstream to CAD. That knowledge can be stored in the database and belongs to its structure. Adding information to the class ‘article’ allows a better understanding between members of the design teams. Indeed, intrinsic information with the structure of the database does not allow to completely define the product and the design process. This knowledge is transverse with all projects of product design. Design can thus be seen as a process taking into account the external parameters, acting as constraints or requirement on the considered product, to deliver the necessary performance to functions. The requirements and the constraints result from the thorough study of the phases and the situations of the product lifecycle (Menand, 2002). The knowledge related to parameters, technical solutions and articles, also allows describing the contextual elements to take into account at the time of their instantiation.
4.2 Conjunction In the models of DISKOVER, conjunctions are the aggregations of knowledge from former designed products to describe the ‘under study’ products: these mechanisms are usually called as ‘reuse’ in design or carry over. This knowledge can be found in the design process models when tasks require resources. Resource is generally a useful piece of knowledge to achieve the task. Some resources can be imported from other project already realised; they are experience feedbacks (Figure 5). The experience feedbacks are captured knowledge which could be the subject of analyses. They can be imported from expert consultations, tests, models or mock-up, etc.
238 Figure 5
A. Zouari et al. Class diagram providing relationship between project and task
Indeed, it is possible to consider a meeting of various domain experts to analyse the experience feedbacks to agree and update, according to GKR. By capitalising them, the experience feedbacks will be accessible and deferred in knowledge of the tasks for any project. These experience feedbacks must be described by specifying the project to which they are attached as well as the context associated with the project. Thus, available knowledge is enhanced in the design process knowledge repository (knowledge space) by others started by the expansion of the product (concept space).
4.3 Expansion by partition or inclusion The product model of DISKOVER is based on a systematic approach, resulting from the V cycle of system engineering. This cycle defines the partition of a system into sub-systems until components. This model shows that an article pertaining to the studied system can be composed of other elementary articles, characterising a technological solution and having to provide a particular function (estimates, forced, etc.). Each article is characterised by one or more parameters preset by the function which carries out the technological solution. The later is used for a life situation which declines from a phase of the product lifecycle. In the C-K theory, concept modelling (C), furthermore, supports inheritance of components. This allows the definition of sub-concepts that inherit some components of other concepts, in addition, in order to behave like a more specific concept. Multiple inheritances are supported to allow concepts to inherit some components from more than one other concept. In DISKOVER approach, a system is an article whose granularity is defined by designers. They instantiate the domain product model on a given project. This instantiation allows enriching the concept (product) by some pieces of knowledge related to the project that is in progress. Constantly, article instances for a given project authorise to reconstitute the composition of the article (studied system). Figure 6 shows these concepts.
Can C-K theory apply to KBE systems? Figure 6
239
Article decomposition through reflexive relationship and instance
Object versioning (article) makes possible to show this partition or inclusion on the Product Knowledge Repository. The later can be enriched by uniformity rules. The administration of object versions provides means of filing the objects changes. In combination with the history of accesses, it is possible to trace the object changes to the users (Van Leeuwen and Fridqvist, 2003). Having a record of the history of each object facilitates browsing and restoring of previous states of a design model: this is helpful in a context of iterative design. Maintaining object versions in design is interesting in order to document alternatives of the design. Moreover, in the context of a collaborative design, the management of object versions is significant to maintain the uniformity of the object model which is consulted by multiple users. Changes to the objects will be managed by the creation of versions which ensure that the state of objects recorded in previous versions will remain available for further explorations. References between objects can use the object versions information, so that the data consistency is not alterated when new versions are created.
4.4 Expansion by deduction or experimentation In the models of DISKOVER, the expansion of knowledge by deduction or experimentation results from the instancing parameters, e.g. on a given project. This instance allows the knowledge space (K-space) to have an auto-expansion. Parameter instances (Figure 7) are all the values that a parameter can have within a given project. Figure 7
Parameter value
240
A. Zouari et al.
The parameter instances are characterised by: x
Versions: within a given project, the same parameter will be able to have several values. Thus, versions help to capture the history of these values.
x
Modification date: this attribute allows capturing the date of the modification of the value of a parameter; it contributes to traceability.
x
Value: that captures the numerical value of a parameter
x
Modification reason: actors describe the reasons of changes, i.e. stored in this attribute.
x
Tolerance interval: the interval of tolerance that a parameter can have in a given context.
x
Reliability index: a value from 1 to 5 which makes it possible to inform the actor about the reliability of the value at the moment. It is similar to maturity index.
x
The state of the parameter: informs the actors about the fact that the value of a parameter is defined, definite but not validated, not definite, not definable or in the course of definition.
An important issue in collaborative (and iterative) activities is how to control versions of information. Keeping track of versions of information serves three different objectives: x
to record the history of information in order to allow undo-operations
x
to allow changes to data without compromising references to previous versions of that data
x
to make it possible to inspect and compare versions (Van Leeuwen and Jos, 2002).
The traces of knowledge versioning operations during the design process allow also having a self-expansion of the knowledge space. In other words, it is a self-expansion of the Design Process Repository.
5
Application: functional design of automotive air-conditioning systems
To illustrate our methodology and to test the prototype information system, the case of the functional design of an automotive air-conditioning system (Figure 8) was chosen. This functional design process is repetitive because for each different vehicle project, the designers have to choose a technical solution among some feasible technical solutions and to provide proper dimensions for it. Fifty different vehicles per year justify the knowledge model domain to capture and organise design methods. The initial goals for a design are the new performance targets to be achieved by the system that will integrate a new physical and functional vehicle environment. This application case aims to capture and reuse the returns of experiences from designers involved in the functional design phase.
Can C-K theory apply to KBE systems? Figure 8
241
Automotive air-conditioning system
5.1 Enrichment of a concept by pieces of knowledge from a design process Designers can explore many technological solutions in order to choose the most suitable solution within the studied project. This choice needs information that can be imported from other designers involved in the environment of the project, e.g. motor power, vehicle geometry, car walls materials, etc. An automotive air-conditioning system is most of the time made up of: x
a compressor
x
a condenser and fun
x
an evaporator and fun
x
a pressure reducer
x
several pipes
x
electrical wires
x
a control panel
x
an air diffuser.
Those structural systems are modelled as sub-assemblies of the product model domain. Each sub-assembly or component can thus be described by its own parameters with a particular attachment to the domain model. For instance, an automotive air conditioner, piston compressor powered by the diesel engine has the following parameters: x
entrance pulley diameter
x
groove type
x
electrical voltage
x
diameter of porting suction
x
diameter of porting discharge
x
cubic capacity
242
A. Zouari et al.
x
refrigerating capacity
x
speed range
x
etc.
To better describe the product (as a concept of C-K theory), it must be enriched by pieces of knowledge issued from the project design process model. This allows setting values to all related parameters. Figure 9 shows concept enrichment by knowledge coming from the design process model instanced to particular project. Figure 9
Enrichment of the concept ‘compressor’ by pieces of knowledge from the project design process
The heat balance of the car is established according to the geometry of the cockpit, the geometrical and thermal characteristics of wall materials and the climatic conditions. The heat balance provides data for the compressor frigorific capacity (power). The designer chooses then the commercial compressor that has the closest frigorific capacity. The selected compressor is a delivery of design process that has determined the design features of the compressor by using catalogs of refrigerating machine compressor manufacturers.
5.2 Enrichment of a design process by experience feedbacks from a concept The functional design process is a set of combined tasks; this set is organised to respect a lot of functional constraints. For example, to execute its main functions, harnessed compressor needs a power source from the car engine. Therefore, the engine power has
Can C-K theory apply to KBE systems?
243
some consumption specifications to be respected. This represents, for the air-conditioning system, some constraints. Knowledge can be aggregated from other projects, to enrich the design process of a given project being studied. This is called the reuse of pieces of project knowledge. The majority of the tasks require resources more of the competence which carries it out, the process and the conditions of its realisation. The resources represent for a task, a formula, some precautions and also some ‘feedback experiences’ that have to be considered. Figure 10 shows the enrichment of the process task ‘choose a compressor’ by experience feedbacks which relate to other projects. However, the same system of air-conditioning designed for a specific project can be re-used for another more recent project. During the process of execution of the task ‘choice of the compressor’, if the designer selects a compressor which was already selected for another project (X), then the information system mentions that the object selected carries the label (X). Figure 10 Enrichment of the process task ‘choose a compressor’ by experience feedback
The designer in this case can reuse the unit, sub-assembly or part of the air-conditioning system of the project (X) for the project in progress.
5.3 Description of a concept by its partition DR, product viewpoint, is based on a systematic approach, resulting from the V cycle based on the concepts of system engineering. This cycle defines the partition of a system splitted recursively into sub-systems until components. Each article is characterised by one or more parameters preset by the function which carries out the technological solution. In DISKOVER approach, the article granularity is defined by designers which
244
A. Zouari et al.
instance the domain product model on a given project. Constantly, article instance for a given project authorises to reconstitute the composition of the article (studied system). Figure 11 shows that the air-conditioning system is splitted into many articles such as compressor, evaporator, pipes, etc. For each precedent sub-system, there are a lot of technological solutions that differentiates each entity. The first one is the technology in use for the power source (car engine powered compressor or electric motor powered compressor). The second is the technology that allows compressing the refrigerant (piston compressor, scroll compressor, etc.). According to used technology, each article is divided into sub-systems composed of elementary components (a piston compressor is composed of pulley, clutch, pistons, etc.). Each component is characterised by knowledge (parameter) useful for other tasks, example the pulley shape and diameter are used to choose the section and the length of the belt. Figure 11 Description of the concept air-conditioning system by its partition
5.4 Expansion of the knowledge repository through versioning To reduce the number of iterations during the collaborative process, it is important to choose the most appropriate data exchange strategy between participants (Telerman et al., 2006). Moreover, to better reuse capitalised knowledge and manage them easily, they must be filled according to versions of knowledge. During the design process execution, knowledge versioning is focused on versions of parameter values issued from the same design process. The conceptual model in Figure 12 shows that each parameter can have values when it is instantiated to a given project. The values of parameters can be versioned during the execution of a collaborative design process, according to the changes that can occur during their exchange between various actors working on this project and sharing this parameter. Each change of a parameter value generates a version of this one if it has been validated by the actors who share this parameter in their processes or tasks. These versions must have the label of the project because they are versions of parameter
Can C-K theory apply to KBE systems?
245
instance resulting from a task instance belonging to the design process of this project. They will be recorded in a particular database for the project, to trace the history of its execution called PL. Figure 12 Conceptual model of value parameter versioning
Figure 13 illustrates an example of the suction pipe diameter being instantiated on different projects (version 1.1 is used on 307 project and reused on 407 and C5 projects). Moreover, it shows instance parameter versioning to a particular project (versions 1.1, 1.2 and 1.3 are used on 307 project). Figure 13 Enrichment of the knowledge repository through versioning
Design solutions in the product model are represented in a classical breakdown representation with assemblies, sub-assemblies, parts, features and parameters. The latter can be related to any level of the representation and each part of the product is associated with an actor, which is responsible to give the information of ‘its part’ to the other actors. The main parts of the product model UML classes diagram are: the systemic approach,
246
A. Zouari et al.
the design constraints, product dependency and life situations. Figure 14 shows the principal of the product model. Figure 14 First and third level of the design product UML model
The design process model represents: actors’ roles, input data and their origins (previous tasks), output data and their destination (following tasks), associated knowledge (user guides execution, previous experiences, etc.), associated resources (software, tools, etc.), comments (annotation, validation), the constraints issued from the lifecycle artefact and the conditions of task executions. The model in Figure 15 shows the principal design process model. Figure 15 The UML design process meta model and project repository UML model
Can C-K theory apply to KBE systems?
247
The complete static models of the different knowledge level are described below. The use cases and the sequence diagrams have not been detailed in this paper: they can be found in Zouari (2007).
6
DISKOVER implementation
The study led to the development of a data-processing model called ‘DISKOVER’ (Figure 16). DISKOVER proposes a structure permitting the collection of knowledge related to a multi-actors design and the associated products. The software tool of DISKOVER was designed using a WinDev environment. Figure 16 Starting page
For the consultation of knowledge, the software allows actors to: x
consult design process tasks and their state: an actor will be able to consult design process tasks which concerns him (input data, output data, knowledge associated, etc.) and their states (ready, non-feasible, etc.)
x
consult the product parameters: each actor can access parameters for which he is responsible, those that are necessary to carry out his tasks and getting their results. For knowledge dynamics, the traditional methods obliged designers to refer to a design guides, internal notes, knowledge books, the intranet, etc. To help them to carry out a task and to take into account the experience feedback of previous projects, we propose to associate necessary knowledge for its realisation to each task and to provide knowledge on a simple click.
x
assist the actors in the course of the process: DISKOVER distributes to concerned actors their tasks and their associated knowledge (with constraints and experience feedback) according to the course of the design process. DISKOVER will thus warn the user with his available tasks (task push); the actor opens this task, carries out it, launches its execution and save it.
248
A. Zouari et al.
Before accessing the design process, the actor must be identified in the system as a user by a login and a password. Once identified, the actor can consult tasks on which he will work. He must choose those whose conditions for implementation and scheduling are ready, at this time the button ‘execute’ be highlighted. While clicking on the execute button, the card of task appears. Internal parameters appearing on the card cannot be modified, but annotated. The actor has the possibility of seizing the values of external parameters and consulting the task resources like tables, curves, etc. (Figure 17). Once the card is filled, the actor clicks on the execute button to launch the computing process. Thereafter the actor can consult the results and save them before closing the card. Figure 17 Task executing card
While clicking the save button, the designer gives the order to the system to save the results as a revision and to send output parameters values to the actors who need them. If the values are already stored in the database, the software sends a message to the concerned actor indicating him that these values exist in a defined version (see Figure 18).
Can C-K theory apply to KBE systems?
249
Figure 18 State of parameters version
The responsible person must be identified in the system as an administrator by a login and a password to access the menu. The menu allows to the administrator to consult: x
projects: consult and add projects
x
actors: consult, add and remove actors of a project. The administrator can also assign the actors to tasks.
x
parameters: consult, add, modify or remove parameters relating to a process (Figure 19).
x
process: allow processes of execution for a given task. The processes are Excel worksheets which can be versioned according to the need.
x
tasks: consult whole tasks and their instances of the design process on the selected project. He has, moreover, the possibility of adding, modifying or removing tasks.
x
resources: consult, add, modify or remove the resources relating to a task.
250
A. Zouari et al.
Figure 19 Parameters table
7
Conclusion
This paper has presented an example of design system with compliance to the C-K design theory. This approach is called DISKOVER; it aims to support KM in cooperative functional design. DISKOVER is based on three levels, capturing each piece of knowledge. At the higher level, ‘generic model’ captures the nature of functional cooperative design, while the second ‘domain model’ embeds the know-how for a specific technical design domain. Finally, the ‘projects repository’ stores the former and present design projects. This repository can be supported by specific collaborative software, implementing some concepts of the domain model. Each knowledge level of DISKOVER can describe a concept and the design process that describes it. Thus, we show that product models resulting from concepts, and design process models resulting from knowledge. This reflects the notion, e.g. that a particular object in a design exhibits several functions, or can be regarded from various points of view. This is useful for making possible to attach knowledge to objects whenever knowledge comes into view or inversely. At this stage of our research, many issues remain open. The communication and the uniformity between the levels of knowledge are based on a top-down approach. The domain knowledge uses the concepts defined in the generic model and the project repository stores knowledge according to their definition in the domain model. This communication points out the necessity to study knowledge versioning mechanism throw design process and the methods to maintain uniformity between the models during those evolutions.
Can C-K theory apply to KBE systems?
251
References Busby, J.S. (1998) ‘The neglect of feedback in engineering design organisation’, Design Studies, Vol. 19, pp.103–117. Eckert, C. and Boujut, J-F. (2003) ‘The role of objects in design co-operation: communication through physical or virtual objects’, Computer Supported Collaborative Work, Vol. 12, pp.145–151. Hatchuel, A. and Weil, B. (2002) ‘La théorie C-K: fondements et usages d’une théorie unifiée de la conception’, Paper presented in the Proceedings of the du Colloque Sciences de la Conception, Lyon, 15–16 March 2002. Hatchuel, A. and Weil, B. (2003) ‘A new approach of innovative design: an introduction to C-K theory’, Paper presented in the Proceedings of the ICED’03, August 2003, Stockholm, Sweden, 2003 (p.14). Hatchuel, A., Le Masson, P. and Weil, B. (2004) ‘C-K theory in practice: lessons from industrial applications’, Paper presented in the Proceedings of the International conference DESIGN 2004; Dubrovnik, May 18–21, 2004. Mathelin, S., Boujut, J.F. and Tollenaere, M. (2005) ‘Improving collaborative design tools in automotive industry: a case study’, Paper presented in the Proceedings of the International Conference on Engineering Design ICED 05, Melbourne-Australia, August 15–18 2005. Matta, N., Ribiere, M. and Corby, O. (1999) ‘Definition of a project memory model’, Research Report n° 3720, INRIA, June 1999. Menand, S. (2002) ‘Modélisation pour la réutilisation du processus de conception Multi acteurs de produits industriels’, Thèse de Doctorat INPG, janvier 2002. Menand, S. and Tollenaere, M. (2001) ‘MULTI: a tool and a method to support collaborative functional design’, Paper presented in the Proceedings of the International Conference on engineering design ICED 01 Glasgow, August 21–23, 2001 Merlo, C., Eynard, B., Girard, P., Odinot, A. and Gallet, T. (2005) ‘Compared implementations of PDM system based on UML specifications’, Int. J. Product Lifecycle Management, Vol. 1, pp.52–69. Ribière, M. and Matta, N. (1998) ‘Virtual enterprise and corporate memory’, Paper presented in the Proceedings of the ECAI’98 Workshop on Building, Maintaining and Using Organizational Memories, Brighton, UK, 1998. Ribière, M., Matta, N. and Cointe, C. (1998) ‘A proposition for managing project memory in concurrent engineering’, Paper presented in the Proceedings of the International Conference on Computational Intelligence and Multimedia Applications (ICCIMA’98), Churchill, Australia, 1998. Telerman, V., Preis, S., Snytnikov, N. and Ushacov, D. (2006) ‘Interval/set based collaborative engineering design’, Int. J. Product Lifecycle Management, Vol. 1, pp.150–163. Tollenaere, M. (2005) ‘PLM supporting collaborative functional design’, Paper presented in the Proceedings of the Virtual Concept 2005 Biarritz, France, November 8–10, 2005. Van Leeuwen, J.P. and Jos, P. (2002) ‘Knowledge sharing for collaborative design’, Paper presented in the Proceedings of the 6th International Conference on Design and Decision Support Systems in Architecture and Urban Planning, July 7–10, 2002, Ellecom, The Netherlands. Van Leeuwen, J.P. and Fridqvist, S. (2003) ‘Object version control for collaborative design’, Paper presented in the Proceedings of the 9th EuropIA International Conference, E-Activities in Building Design and Construction, Istanbul, TR, October 8–10, 2003 (pp.129–139).
252
A. Zouari et al.
Zouari, A. (2007) ‘Proposition de mécanismes de versionnement et d’agrégation des connaissances de domaine en conception de produits industriels’, INPG phD Thesis Report, March 2007. Zouari, A., Tollenaere, M. and Menand, S. (2002) ‘Application of a multi-actors design model to the car air-conditioning system functional design’, Paper presented in the Proceedings of the IEEE SMC02 Conference, Hammamet, Tunisia, October 6–9, 2002. Zouari, A., Tollenaere, M., Maalej, A. and Ben Bacha, H. (2005) ‘Assistance à la conception collaborative par la capitalisation et la réutilisation des connaissances’, International conference: design and mechanical system modelling, CMSM’2005 Hammamet, Tunisia, March 23–25, 2005.
