ࡱ> `bjbj 4LLLL444$6d rrrP˜@ }H$h5 Q4###LL mèèè#L 4 è#èè*K* 4 z +Wr= RJ0rn   4ŞSèoSŞŞŞŞŞŞ####@@@Wr@@@r456LLLLLL Design projects' repository  a tool FOR DESIGN PROCESS guiding, knowledge capturing and reusing Neven Pavkovi Chair for Product Development and Design Faculty of mechanical engineering & naval architecture, Zagreb Croatia neven.pavkovic@fsb.hr Igor Klari KLEX d.o.o., Zagreb Croatia igor.klaric@klex.hr Mario `torga Chair for Product Development and Design Faculty of mechanical engineering & naval architecture, Zagreb Croatia mario.storga@fsb.hr ABSTRACT Paper presents results of the first phase in development of computer environment for achieving traceability in product development process. Following design process support functions are included in prototype: guiding the inexperienced designers; organizing and cross-linking the digital documentation generated in the design process; evaluating and managing the ongoing projects; building a knowledge base about finished design projects through capturing significant data and rationale; querying the rationale and documents from previous projects. The main structure for representing the design process flow and for indexing the design knowledge is the design plan, which comprises a state action model of the design process. Based on design plan usage, the authors propose a model of knowledge generation, capture and reuse. Two important issues of design repository usage in practice are briefly discussed the guidance of novice designers and the balance between potential benefits of proposed system and the extra time required from designers to use it. Those are key factors that affect many issues in preparing the terminology, the usage procedures and the interfaces. Keywords Traceability, design rationale, knowledge capture and reuse, data organisation Introduction In current design support systems, knowledge-level design semantics, such as design intent and design rationale, function and behaviour, etc. are represented in an ad hoc manner (Regli et al., 2004). Most often this information is found in associated design files, annotations, and communications that lack any formal structure. In practice engineers mainly doesnt record justification for design decisions and the reasoning lying in the background of those decisions. The design process is here viewed as a sequence of transitions from an initial state of data, constraints and goals to a final state, the description of the artefact being designed. These transitions are allocated to individual participants or teams, and individual or integrated computational tools or models. A design process may no longer be viewed as a static institutionalised structure, but rather as a dynamic network that is constructed in real-time as design goals, needs, priorities, and resources evolve (Wallace et al., 1999). In the framework of an integrated CAD environment, the designer should work with an open toolbox, enabling him to create his own classes and partial models of the design process according to his current needs. The goal of presented research is to develop a knowledge oriented framework that enables to model the design process flow (and to integrate used software tools) independently of design phase and class of design task. Related research projects The issue of creating and capturing reusable design knowledge in engineering design has been addressed by many researchers from various perspectives. Research efforts span the areas of design and behavioural model repositories, analysis templates, and product lifecycle management consistently promoting knowledge and information capture and reuse over the life of the product (Mocko et al., 2004). In most cases designers wish to reuse captured design knowledge to adapt past solutions and apply these to current problems, and novice designers may wish to understand lessons from previous experiences (Ahmed S., 2005). Similar treatment of formalism in representation of the design process can be found in the work of Gorti et al. (1998). Their model is implemented as a layered scheme that incorporates both an evolving artefact and its associated design process. They define the design process with five primitive objects: goal, plan, specification, decision and context. Liang and O'Grady (1998) have developed a concept of a design object that represents physical entities such as parts or components as well as non-physical entities, such as design history or vendor information. They build the design process model formalism on a definition of a design model, design objects and design methods. Proposed model of design process stage is in one part similar to "design workspaces" proposed in Grabowski et al. (1995 and 1996). The "design workspace" is focused primarily on geometric modeling. The model proposed in this work is primarily oriented to improve the design process organization and to integrate the data flow through various software tools used in the process. In other words, this research work is focused primarily to represent the design process in the context of information processing. McMahon et al. (2005) analyse many issues of capturing the outcomes of the design process as a part of information management for through life product support. Very interesting considerations about planning the design process may be found in Giaopulis et al. (1995). We must ask ourselves to what extent a design process could be planned? Real design process environments generate dynamic situations - they can change while the plan is being executed in a way that makes the plan invalid (Pollack M.E., 1992). As if this is not enough, real environments may also change in a way that do not invalidate a current plan, but instead, offer new possibilities for action. TRACEABILITY IN PRODUCT DEVELOPMENT process During product development designers need traceability carried by traces of the design routes, because they want to reuse existing design knowledge along meaning, reasons, arguments, documentations (proofs, specifications), choices, critique, consequences etc. Traceability can give essential assistance in management of the requirements, that are results of the needs or predicted future meetings between design and the different life phase systems (in production phase, using phase, servicing phase, etc.). Traces of requirements evolution and verification procedures should help designer in ensuring of the requirements fulfilment and keeping track on the development project status. Also, tracing of the design history should improve understanding of the design routes by linking designed items to justifications, important decisions and assumptions behind them. By tracing designed items back to their sources the impacts of later changes in any product feature can be identified before a product is redesigned. Many different actors in product life-cycle are involved in the product development process. As a consequence of these different uses and perspectives on traceability, there are wide variations in the format and content of traceability forms across different product development efforts. The current literature and the standards do not provide detailed guidelines of what types of product development context must be captured and used in what meaning. In our observation on discovering the main dimensions of traceability contents, we can start from assumption that the traceability is always related to a specific design episode. Such reasoning comes from re-consideration of the design decision-making framework proposed by Hansen and Andreasen (2000). Each design episode has the specific traceability scenario that can be described by answering the basic questions: What are the traceable items (objectives, requirements, design representation objects, tests, etc.) that are managed during design episode, what are their characteristics and what are the links between them? Who are the actors that play different roles in the creation, maintenance and use of those items and links? Where are the items represented: in physical media such as documents, drawings, spreadsheets or other files, or in less tangible things such as telephone calls, discussions, emails, meetings or peoples brains? How are they represented (by more or less formal means)? Why were they created, modified or evolved? When were they created, modified or evolved?  The meta model of product development context for achieving traceability There are no existing tools that support achievement of the full traceability in product development. The existing tools besides their main functionality provide possibilities for the partial traces production, extraction and/or verification. For example, PDM tools allow navigating some historical routes of a product development by recording the evolution of different documents through main revisions and versions. In the same time the feature based CAD tools provide possibility for tracing history of building geometrical feature tree. But, the heterogeneity of existing tools serves as a reason for difficulties in full traceability implementation. In engineering, each discipline has its own languages, methods and tools. This results in a lack of ability to trace development process across disciplines (Palmer 2000). Traceability achievement Considering how to achieve traceability in product development, we can emphasize the existence of the three main stages: Identification and planning: this stage is characterized by definition of traceable items accordingly to design episode where the designer decided to make things traceable. In this stage, the main task is to define what (kind of) objects should be traced and what (kind of) links are needed between those objects. Recording and documentation: the main task of this stage is in creation of traces that are result of product development activities, designers actions, decisions, reasoning, events, etc. Only explicitly defined design items and routes should be recorded and documented for further use. It is performed during all phases of product development. Utilization: the main task of this stage is extraction of design items by following, querying, and navigating them through recorded and documented traces. It is done by simulating design episode in another situation: for performing changes on existing solutions, reusing of the existing solutions in new projects, configuration of the new variant of the product, and educational process for inexperienced designers. A meta-model of product development context for achieving traceability The meta-model of product development context (torga, 2004) describes all construct needed to generate traceability models as well as their semantics. The meta-model consists of traceability items and links (Figure 1), and each of them can be specialized and instantiated to create specific implementation models. Design objects are generalization of inputs and outputs of different phases/stages of product development process: requirements, working principles, activities, organs, functions, parts, design characteristics, design properties. These items represent major conceptual elements among which traceability should be maintained during the product development. Subjects are generalization of different actors and their roles involved in the product development. The subjects can be project managers, designers, analysts, customers, suppliers, testers etc. Subjects act in different roles in creating, using and maintaining various design objects. Roles are characterised by subjects knowledge, competencies, rights and obligations. Sources documents the design objects, and may be different physical media, computer readable documents, references to the people or undocumented policies and procedures. Decisions and rationale are representation of the design rationale behind the creation, changing, and evolution of the various design objects. The information about how decisions are made by subjects must be maintained during the product lifecycle to ensure that needs are understood and satisfied. Decisions based on rationale affect design objects by evaluating and selecting its alternatives. Design Repository a prototype ENVIRONMENT for traceability implementation This chapter presents results of first phase of development a prototype implementation environment for achieving traceability in product development process. The developed prototype still does not include all elements of the previously described meta-model. Following design process support functions are included in this phase: guiding the inexperienced designers through design process scenarios, specific for the particular design environment providing the structure for organizing and cross-linking the digital documentation generated in the design process providing the data and interfaces for evaluating and managing the ongoing projects building a knowledge base about finished design projects through capturing significant data and rationale for steps of each individual task and project querying the rationales and documents from previous projects Relational database environment is chosen as the software development platform for several reasons: Relational databases offer powerful search tools and means for management of huge data collections. Software market offers a wide price range of relational database environments, mainly varying in network and security performances, while there is no significant difference in modelling capabilities of complex data structures. The prototype system is targeted for testing and usage in small and medium companies, thus for the purpose of initial development, a low budget and not too complex software development environment would be sufficient. After the implementation model will be fully developed and its usability proven, it could easily migrate to more powerful (and expensive) systems. The representation of design process flow Typical product development is realised in small steps by redesigning the existing products, rather than by designing entirely new ones. The proposed repository model does not make difference between the classes of the design task in the context of the design novelty or the design process phase. The main structure for representing the design process flow and for indexing the design knowledge is the design plan, which comprises a state action model of the design process (Pavkovic, Marjanovic, 2001). In this research phase the focus has been put on support of adaptive and variant designs. We have tried to integrate design information management tools with the design process planning and workflow model. It is defined as a model of design process decomposition and the execution sequence. The purpose of the model is to organize and to try to predict the information flow as well as the sequence of execution of process steps controlled by conditions and constraints. The design plan is represented graphically as a collection of nodes and their connections in a directed graph, recorded in adjacency and incidence matrices. The connections between nodes represent the information flow and/or the sequences of node execution. The nodes of a design plan represents design process steps. To execute a node means to perform the associated operations. In other words, the main elements of the design plan are steps and actions each step may comprise several actions. The main features of the proposed model are as follows: design plan contains a set of predefined steps and actions for the particular design project (task); new steps and actions could be added during the design process for the management purposes steps are linked with project workflow and timeline data steps and actions contain elements for recording rationale and for project state evaluation each design plan, step and action include a set of links to relevant documentation the repository contains a catalogue of all kind of documents being used in the design process The term "document" assumes here any kind of digital file (CAD part or drawing, spreadsheet, text, picture, etc.).  An example of design plan representation with directed graph The connections in directed graph (Figure 2) are classified as: "normal" execution sequence (points from current node to next node) "recurrent" (repeated) execution sequence (points from current node to one of previously executed nodes) this is a kind of prototype model of iteration in design process "information dependency" connection indicates that data sets (of objects that are referenced from connected nodes) are directly or indirectly dependent The design plan node models one step of the design process, including: checking of preconditions, list of actions, checking the "postconditions" and deciding about the next step. The process of knowledge generation, capture and reuse Identification and planning According to Ahmed S. (2005) novice designers require support in identifying what they need to know. One of the primary features of the proposed design repository is to enable the novice designer to access the organized recordings of knowledge and experience of senior designers. When starting a new design project, the designer opens the particular design plan skeleton containing a set of predefined steps, actions and their sequence. A design plan skeleton is the structure that should represent, collect and organize every type of knowledge and data that is or should be known prior to start of a new design project. The term "skeleton" is used to emphasize that this is an initial structure for building the complete recording and documentation of finalized design project. Relying on our own previous research work (Pavkovic, Marjanovic, 2001) we assume that it is possible to create skeletons of design plans for adaptive and variant designs. The most experienced designers should create skeletons of design plans for particular classes of design projects in particular design office. This way experienced designers should generate the knowledge about how some particular project should be solved by their own experience. As previously stated in this stage the main task is to define what (kind of) objects should be traced and what (kind of) links are needed between those objects. Figure 3 shows schematically the process of knowledge flow from generation to storage.  The flow of stored and newly generated knowledge in the process of the proposed system usage Recording and documentation Through the timeline of design project realisation, the initial design plan skeleton is being updated, upgraded and "filled" with created traces that are result of product development activities, designers actions, decisions, reasoning, events, etc. At the end of the design project skeleton is transformed to completed design plan with explicit design items and routes recorded and documented. Such design plan is a complete description of a finished design project. Finished design plans are being stored in archive. Knowledge reuse By choosing the appropriate design plan skeleton, the designer accesses and reuses expert knowledge and experience. The other way of reusing knowledge is by extraction of design items from archive of finished projects. Extraction could be done by following, querying, and navigating through recorded and documented traces as also by querying and accessing linked documentation in digital (or some other form). Predefined and organized reuse of stored knowledge in a proposed system becomes an integral part of the design project solving process. Predefined and organized reuse is achieved through special items in design plans that tells the designer what is (or should be) available for searching and where this knowledge should be found. Some simple examples of these situations could be: changes on existing solutions, reusing of the existing solutions in new projects, viewing problems and solutions on previous similar projects, analysing testing reports, etc. On the basis of all previous considerations the "design projects' repository" is composed of following components (figure 3): A set of design plan skeletons A set of tools and procedures for working on active project by using the copy of chosen design plan skeleton The archive of finished design process Methods and tools for indexing, searching and retrieving recorded knowledge All the documentation linked from design plan items, - it should be considered as "external documentation archive" spread over ERP / PDM / PLM and CAx tools Guidance of novice designers The guiding function of the proposed system is accomplished through following features: design plan gives a novice designer a proposal (or a kind of prediction) of the execution sequence of operators in the design process domain, or in other words a guidance (a path) of the progression in the particular design process, references to relevant documentation for each design process step and action provide the mechanisms for easier organizing in the process of gathering necessary data and information, querying, searching and retrieving the archive of previous projects helps the novice designers to gain the necessary experience and knowledge much faster than by other ways of informal communication with experienced designers but that doesnt mean that we underestimate the value of face to face transfer of knowledge. Entity-relationship model of the proposed system This chapter gives a brief overview of main entities and their relationships in the prototype database that is still under development. Once outlined and established, the computer based design process model will be the subject of permanent improving and maintenance processes caused by new design science cognitions or changes in the environment where the design process proceeds. Therefore, it is proposed to outline the global design process model structure as an "open toolbox". Such an approach should enable the designer to create his own classes and partial models of the design process according to his current needs. It can't be expected that it is possible to build a model general enough to enclose all phenomenon variations in different real environments. Keeping this in mind, the presented research aims to develop a framework that could at least enable the use of different partial models (from design process domain) in an integrated manner. A real system (real world domain) whose modeling is being considered here is a teamwork, computer supported design process which uses computer network (intranet) for team member collaboration and data share. Is it supposed that such environment intensively uses CAD software, databases, PDM and other kinds of software tools. In outlining the design process model the focus will be in efforts to adopt the model as much as possible to purposes of computer application. In such approach the authors would not try to build neither primarily prescriptive or descriptive model, but some kind of a hybrid. The design process will be treated as information generation and transformation, estimating that the majority of the information is computer stored. In other words, the designing is treated as a process for which a computer support should be modeled by mapping a common working process (from the real world domain) to the domain of object-oriented software system. Based on the presented approach, the entities of conceptual domain will be proposed. In the process of outlining the model structure, the efforts will be focused to make the model general enough for wide spectrum of application. In the same time the model should contain a rich set of specialization possibilities, to be able to efficiently adapt to specific characteristics of particular application environment. Let us compare the conceptual modeling (outlining) of common business processes and design process. The majority of business processes are relatively simpler in structure than the design process - therefore it is easier to extract their conceptual model from the real world domain. Most of the transactions and operations in business processes are well defined and determined. In the contrary, the big part of transactions in the design process are very difficult to predict, and impossible to prescribe. The main difficulty of this research, particularly in developing the entities of the proposed model, was (and still is) the lack of the general consensus in design terminology, taxonomy, and typology, as emphasized in Andreasen et al. (2000 and 2002). Design science misses the CAD theory as pointed out by Akman, et al. (1990). We have chosen the approach to build and refine the model "step by step", doing all the possible testing before further upgrading. There are many issues of practical usage that affects the model and generate the need for new entities and attributes. Those needs could be recognized only in stepwise attempts to use a system on real problems, and that process is still unfinished. Therefore only the "kernel" part of the model will here be presented those entities and relationships that are crucial for understanding the basic ideas. Figure 4 shows eight database tables and relationships between their fields. Four entities make the kernel of the proposed model: design plan, design process step, action and document. The attributes for each of mentioned entities are stored in corresponding table. Each of these entities is categorized, having a list of its categories in separate table. The basic idea behind categorization is to enable implementation of different behaviour for various kinds of entity instances. Table "design projects archive" contains main attributes of design plans. The data for both the skeletons and finished plans are stored in this table. The difference between various forms of plans is determined by the appropriate plan category. The task of program procedures and interfaces is to implement separate management and behaviour of skeleton plans, active plans and finished plans. Each kind of design plan contains a list of design process steps, whose attributes is stored in "design process steps" table.  The "kernel" part of design projects repository prototype database structure Each design process step contains a list of actions, whose attributes are stored in "actions" table. "Step" and "action" represents two different levels of workflow nodes. The design process step is devised as being at higher (abstract) level of solving a subproblem or discussing an issue, while the action is more concrete designer activity like performing a calculation, modelling geometry, detailing, etc. To complete a design process step, a set of actions should be executed. As both steps and actions represent nodes in the design process workflow, they have almost the same sets of attributes. During the work on the project the designer has to confirm the completeness of every step and action. More important, the designer has to write the rationale and any other significant data for every decision made in completed steps and actions. The sequence of steps is predefined in skeleton, but it could be changed, and new steps and actions could also be added. The system enables iterations within main project checkpoints that means that every step and action could be repeated several times. The checkpoints are one of the steps' categories that include procedures for evaluation of the current project state in context of terms, expectations on solution quality, etc. The process of using the proposed system when working on particular design project (figure 3): Choosing the appropriate skeleton, copying the all the records of skeleton to new "active" plan for a particular project "Filling" the empty fields of "active" plan with new knowledge, adding new steps or actions, recording the exact workflow sequence Completing the project the "active" plan becomes the "archived" plan, the records remain in the same table. Every design step and action, together with all their attributes and links are being recorded. The sequence of execution is also completely recorded, so the whole project solving process history (including all iterations) could be restored. The rationale should be written in "memo" fields in "steps" and "actions" tables.  Roles of system elements in the usage process of the proposed system Each design plan, step and action has a list of links to corresponding documents. These documents either contain the knowledge needed for the particular step or action, or belong to the documentation set of the product being designed. Table "documents" contains basic data about all kinds of documents that could be linked to particular design plan, step or action. To which of previously mentioned entities a particular document belongs is indicated by filling one and only one of the three fields: "action ID", "step ID" or "design plan ID". The document management function of the proposed system overlaps with the functions of PDM systems. However, we think that it is necessary that a proposed system has an organized structured access to all the documents being used in the design process in order to build effective searching mechanisms for knowledge reuse. In this research phase, there are still some open questions regarding recording and indexing of design rationale. Further research efforts should enrich the model with new entities, attributes and procedures for resolving these issues. The software COMPONENTS OF THE PROPOSED SYSTEM Figure 5 explains the role of particular software components in the processes of design plans creation and execution. Operations of creating and executing the design plan are supported with "service" tools and applications. These are very complex procedures as they must ensure the highest possible level of accuracy of the created plans. In the process of creating and executing of design plan, the designer must have on disposal all the available knowledge about software tools used in a particular design environment. Similarly, while planning or executing the design process, the designer should have interfaces to engineering databases (with product data), as well as to knowledge bases about design process and products being designed. Those interfaces should also be realized as service applications. The design plan creation starts from empty plan frameworks and process templates which consists of elementary entities and database structures. The design process structure could be decomposed to a hierarchy of design tasks and subtasks. Therefore, it is not necessary to define a design plan at the highest (most complex) level of design task abstraction. Computer based support for complex design tasks can be modeled as a hierarchy of plans and subplans. The design process control at higher abstraction levels can then be left to the designer. Previously completed and tested plans should be stored in a separate database (archive) to be available for reuse or to be used as the subplans in a more complex plan being created. ISSUES OF DESIGN REPOSITORY USAGE IN PRACTICE An essential issue for the proposed system usage is to find a good balance between amount of information that a designer should record in system and the time he spends for this purpose. To achieve this goal, two components are of primary importance interfaces and the product development ontology. A lot of research work and testing remains to be done to develop good and intuitive interfaces (and procedures) that would save designers' valuable time. The role of ontology is to provide design community with platform for better communication. There should be no misunderstandings about what is being recorded or what is being searched for. The other question of practical usage is what types of knowledge and information the novice designer should be able to find in proposed system? According to Ahmed et al, (2003), the experienced designers were observed to follow certain design strategies which enabled them to evaluate their decisions prior to implementing them. Some of the questions from these strategies most properly describe what issues a "guiding" system should be able to resolve for the novice designers: What should be considered further down the design process? The skeleton of a design plan includes a list of further steps and actions down the design process. Novice designer is able to analyse the process of particular task solving. In which projects did similar issues arise and how were they resolved? Recognizing the similar issues in the archive of finished projects requires knowledge indexing system (and ontology usage) to able to find appropriate captured knowledge. What issues are relevant, and which are the most important? This part of experienced designers' knowledge should be written in explanations of actions and steps of design plan skeleton. How complete is the task, will further information be required? A special category of design plan steps should provide procedures for performing checkpoints and reviews. In design plan skeleton such step should contain a list of information required for analysis of project completeness. How much can I expect to achieve if I continue this approach? Maybe the most useful information captured in previous projects is why something gone wrong, why certain approach haven't reach the goal. Knowing this at the start of new project, the same situations could be avoided. RESULTS AND KEY CONLUSIONS A specific design process has been analysed in order to develop and test the prototype of database structure (entity relationship) model. The chosen design environment has well defined and organized design process that could be easily represented with proposed entities. Mentioned environment is a small design office carrying out projects for garden and building equipment manufacturer. The prototype relational database model, and a part of user interface is finished. Current work focuses on preparing examples of design plans as the basis for further development of system functionality, usability and efficiency. While developing the model structure, it becomes evident that a test implementation will require a lot of efforts in coordinating the perception of model elements and structure among potential users. The other important question is how to ensure the designers will write down the appropriate explanations (rationale) when they are necessary. One of the key requirements for the proposed system is that it should take as little as possible of the designer's time. Previously mentioned facts affect many issues in preparing the terminology, the procedure of system usage and the interfaces. Another important issue for further development is the eventual transfer of the proposed model from cheap software environment to more powerful software and hardware environments, to be able to satisfy the requirements of larger design offices. Already at this phase of the project it showed up that a proposed system would generate a huge database in a relatively short time of usage. In the context of design information management, a design plan is the most complex object that integrates design information through sets of references to other (simpler) objects. Such an approach enables very complex queries and views of the single design project, as well as the set of similar projects. The main goal of the proposed system is to store the design rationale in the context of the design process history. In the next research phase we will try to find the mechanisms of indexing, searching and retrieving the stored rationale to be able to reuse it efficiently at the beginning of the new design projects. Acknowledgments This research is part of funded project Models and methods of improving the computer aided product development supported by the Ministry of Science and Technology of the Republic of Croatia. The presented research is performed in co-operation with KLEX d.o.o., Zagreb, a mechanical engineering design office. References Ahmed, S., (2005) "Encouraging reuse of design knowledge: a method to index knowledge", in Design Studies article in press Ahmed, S., Wallace, K.M. and Blessing, L.T.M. (2003) "Understanding the differences between how novice and experienced designers approach design tasks" in Research in Engineering Design, 14 (1), pp. 1-11 Ahmed, S., Wallace, K.M. and Blessing, L.T.M. (2002) "Capture and Reuse of Experience", http://www-edc.eng.cam.ac.uk/knowledgemanagement/designexperience/ Ahmed, S. and Wallace, K.M. (2003) "Indexing design knowledge based upon descriptions of design processes" in ICED03, 14th International Conference on Engineering Design, Stockholm, Sweden, 691-692 Akman V., ten Hagen P.J.W., Tomiyama T., (1990) "A fundamental and theoretical framework for an intelligent CAD system", CAD, Vol. 22, No. 6, pp. 352-367. Andreasen M. M., Wognum N., (2000) "Considerations on a Design Typology", Proceedings of 3rd International Workshop IPD 2000, Otto-von-Guericke University Magdeburg,. Andreasen M. M., Wognum N., McAloone T., (2002) "Design Typology and Design Organisation", Proceedings of 7th International design conference Design 2002, Design Society, FMENA, Dubrovnik, Vol. 1, pp. 1-7 Bracewell, R.H., Wallace, K.M. (2003) "A tool for capturing design rationale" in ICED03, 14th International Conference on Engineering Design, Stockholm, Sweden, pp. 185-186 Giaopulis A., Schlter A., Ehrlenspiel K., Gnther J., (1995) "Effizientes Konstruieren durch Generierendes und Korrigierendes Vorgehen", Proceedings of 10th ICED conference in Praha, Volume 2, Schriftenreihe WDK 23, Praha, pp. 477-483. Gorti S.R., Gupta A., Kim G.J., Sriram R.D., Wong A., (1998), "An object-oriented representation for product and design processes", in CAD, Vol. 30, No. 7, pp. 489-501. Grabowski H., Lossack R.-S., Weis C., (1995) "A Design Process Model based on Design Working Spaces", Proceedings of the IFIP TC5 WG5.2 International Conference on Knowledge Intensive CAD, Vol. 1, pp. 245-262, Helsinki, Chapman & Hall. Grabowski H., Lossack R.-S., (1996) "Knowledge based design of complex products by the concept of design working spaces", Proceedings of the IFIP TC5 WG5.2 International Conference on Knowledge Intensive CAD, Vol. 2, pp. 79-98, Pittsburgh, Chapman & Hall. Hansen, C.T., Andreasen, M.M., "Basic thinking patterns of decision-making in engineering design", International Workshop on Multi-criteria Evaluation, MCE 2000, Neukirchen, pp 1-8, 2000. Liang W.Y., O'Grady P., (1998) "Design With Objects: an Approach to Object-Oriented Design", CAD, Vol. 30, No. 12, pp. 943-956, 1998. McMahon C., Giess M., Culley S., (2005), "Information management for through life product support: the curation of digital engineering data", Int. Journal of Product Lifecycle Management, Vol. 1, No. 1. Mocko G., Malak R., Paredis C., Peak R., "A Knowledge Repository For Behavioral Models in Engineering Design", Proceedings of DETC  04, Salt Lake City, 2004. Palmer, J.D., "Traceability", Software Requierements engineering, 2nd Edition, IEEE computer Society, pp. 412-422, 2000. Pavkovi N., Marjanovi D., "Considering an object-oriented approach to the design process planning", International Journal of Technology Management, Vol. 21, No. 3/4, 2001. Pollack, M.E, (1992) "The uses of plans", Artificial Intelligence, Vol 57, No1, pp. 43-68. Regli W.C., Foster C., Hayes E., Yiu Ip C., McWherter D., Peabody M., Shapirsteyn Y., Zaychik V., "National Design Repository Project: A Status Report", Geometric and Intelligent Computing Laboratory, Drexel University, 2004. Szykman, S., R.D. Sriram, C. Bochenek, and J. Senfaute, (2000), "Design Repositories: Next-Generation Engineering Design Databases", IEEE Intelligent Systems and Their Applications. torga, M., (2004), "Traceability in product development", Proceedings of 8th International design conference DESIGN 2004, Dubrovnik, 2004. Wallace D. R., Abrahamson S. M., Borland N. P., (1999) "Design process Elicitation Through the Evaluation of Integrated Model Structures", Proceedings of DETC 99, ASME Design Engineering Technical Conf.     Proceedings of the TMCE 2004, April 12-16, 2004, Lausanne, Switzerland  PAGE 12 REF _Ref43622472 \h  \* MERGEFORMAT Neven Pavkovi,  REF _Ref43622484 \h  \* MERGEFORMAT Igor Klari,  REF _Ref43622991 \h  \* MERGEFORMAT Mario `torga  PAGE 11 REF _Ref43622410 \h  \* MERGEFORMAT Design projects' repository  a tHn& 0 2    , 0 < > d h b z    ! \ ^   L N ļ hwhph@CmH sH hwhpmH sH hpmH sH hwh(mH sH hh(h@ChM2 hTFh(hdhs, h[Vh(h h[Vh[V>2  . > f h R b m$$gdgdgdpgddgdTFgd[V  HNWXlmv ûå|tplahwh;mH sH h;h)h2mH sH hwh>jmH sH hwhemH sH hmH sH hwh2mH sH hwh[VmH sH hwh)"smH sH h4^mH sH hwh(mH sH hk>mH sH hwhpmH sH hxbmH sH hpmH sH hxb hwhphp&mvo>9 e k!_$'()) *9*f*h*$=I%1#&#$+D./a$gdeRgd)kgd+gd+!wgdvgdvgd2$ oTUhickkq#=>7 ŽŽŽ沫znh;CJaJmH sH h;h;CJaJmH sH hTjh)mH sH h@CmH sH hTjhTjmH sH hv hnh)h hzhvhvmH sH hwhvmH sH  h@Bh)hz hzhmCWh@C hzh)h)hwh;mH sH h;+7 8 9 e j!k!##_$%%&J'K'O'P''''''((((()))) **9*=*f*g*h***וו׉rg_gheRmH sH hwheRmH sH jhheRUmH sH hmH sH hwhp5mH sH hwh+B*mH phsH hwh%mH sH hwhpmH sH  hwh+ hwhphwh+!wB*mH phsH hwhpB*mH phsH hwh+!wmH sH hwh)mH sH h;$h**-../12254577E99:O;;<<<gd2gd2gdgdzgdzgdgd2Agd2Agd)kgd)k=I%1#&+D/]gdeR*,------...../////11 1!1"122222222෬tlaaRhwhwB*mH phsH hwh2AmH sH h?:mH sH h)"sh?:mH sH h)"sh)"s]mH sH hwh?:6]mH sH h)"smH sH hwh)"smH sH h)"s6]mH sH hwh?:mH sH hwhpmH sH hwh+mH sH hmH sH hwh`AmH sH (hwh`AOJQJ^JmH nHsH tH2333 333333334454D4o4444444455556 6]6շըxfWfWfxh6B*]mH phsH #hwh6B*]mH phsH hwhB*mH phsH hsEmH sH hwhmH sH hwh6]mH sH hwh2AB*mH phsH hwh>jB*mH phsH hwh%B*mH phsH hwh7nB*mH phsH h)"sB*mH phsH hwh)"sB*mH phsH ]6^6e666666 777$72777788899999E9e9p9999999ں~sh`U`hwh+!wmH sH h >mH sH hwh(mH sH hwh2AmH sH hmH sH hwh)kmH sH hsEh0J#6mH sH hwh0J#mH sH hh0J#6mH sH hwh6]hwh7nmH sH hsE6]mH sH hwhmH sH hwh6]mH sH hsEhsE6mH sH  999999:-:.:0:4:G:M:b:::::::::/<N<<<$=0=?$???@@@+@׹ϦϦxψmbmhwh mH sH hwhmH sH hcmH sH h@CmH sH hwhsEmH sH h2mH sH hwh*qmH sH hwh2mH sH h)"smH sH hwh)"smH sH hwh0ymH sH h >mH sH hwhmH sH hwh+!wmH sH hwhemH sH hsEmH sH #<N==>o?@,@'FF G|GG-HHHH#IgIJJ`KKgdxgdE&#$./]gd_Tgdgd"'gdgdEgd*qgdsEgdsE+@,@@@@@@@@@@AAAA%B&BABWB^BaB~BBBuCxCCC D*DE9EzEEEPFUFZFaFuFFGGGGߵߪߪߪߪ꣟sshwh[V6mH sH hO3h[VmH sH  hO3hO3 hO3hE hO3hTjhE hnhEhwh"'mH sH hwh{?6mH sH hwh4mH sH hwhlemH sH h >mH sH hwh{?mH sH hwh[VmH sH hwh(mH sH ,GGG-HHHHHHHHIIJ_K`KpKKKKL{LLLiMwlwaVaKhwhmH sH hwh[mH sH hwh8{mH sH hwh mH sH hwh*qmH sH hwhxmH sH  hO3h_T hO3hEheR hnhEhwh_TmH sH h_TmH sH  hnh_Th_TjhnheRUh*qmH sH hwh[VmH sH hwh"'mH sH h)"smH sH hwh)"smH sH KKzQ|QQQTTWWXwXX YWYYZjZS[ \M]gd6gd6gdEGpxgdi;gd*qgd6gdW0Agd  &&#$/] gd+b< &&#$./gd+b<gd gd iMvMxMM@NHNINN.O;OP4PPPPP!Q*Q+QyQzQ{QQQ7RCRyRRSSꔌ}rgg\gThBmH sH hO3hmH sH hwhmH sH hwh+b<mH sH jz)h9&h+b<UmH sH hO3mH sH hwh$mH sH hwh]mH sH hO3hW0AmH sH hwhmH sH hwhW0AmH sH hwh)"smH sH h)"smH sH hwhfmH sH hwh mH sH hwhlemH sH SSST T TTTPTcTlTTTTTTUUUUUUVV3V{WWWRXSXX Y YYYYYźźŲŜŜő{s{{k`hwh1 hmH sH hBmH sH hO3mH sH hwhEGpmH sH hwh/DmH sH hwhjmH sH hwh~{>mH sH hwh)"smH sH h)"smH sH hO3h(mH sH hwh(mH sH h(WWmH sH hwhLmH sH  h6hLhwh"mH sH hwh(WWmH sH $YYZhZjZZZZZZZZ [![8[C[J[S[^[a[[[[[\\ \A\B\%]&]K]L]M]~]]]]]^^hyiŽŵŽzqhnhO3@ hnhO3hO3mH sH hwh%&mH sH hwho.mH sH hwh`mH sH hwhwmH sH h@CmH sH hX'mH sH hU}hX'mH sH hU}hU}mH sH hU} hU}h6 hU}h!&hU}h6mH sH hLmH sH *M]~]^^>abefimoo=pr=uuvvwKx & Fgdlgdlgdgd"9y"L%&#$/]9gd+b<y"L%&#$./gd+b<gdO3gd`}Zgd*qgdwyiiiiiiiijjj>kdkfkikkkokukkk l lll+l2l3l8lOlallllll:myZy[ybyfymy~y zzzzz{!{>{T{U{X{{{{{{{|||||"|0|;|\|e||˵yhE mH sH hwhA=mH sH hwhwmH sH hwh0mH sH h)"smH sH hwh)"smH sH hwhMImH sH hwh>@mH sH hwhz3DmH sH  hnheRhWhhwheRmH sH jh:h:UmH sH .KxMxx{|}̀Dȅ?_w=Mgdgdgd f9xgd>gdwgdwgdlgd_TgdhgdMI9L%&#$/]9gd$L%&#$./a$gd||||}}}}}}}}}~~~~~~+ˀD DžȅFWXҸҭzozhMhhW0AmH sH hMhhMhmH sH h mH sH hMhmH sH h' mH sH hAsmH sH hPpmH sH hwhwmH sH h_hlB*ph3fhX' h_hX'hU} h_hl h_hkMhlmH sH hhmH sH h_TmH sH h QmH sH *XersGHWY_j؈ !$8:;>STWdpΉ5>?~ъӊԊ=E^_ŽŽꭢꢭŚŚh"bmH sH h AmH sH hwh)"smH sH h)"smH sH hgmH sH h mH sH himH sH hih~6mH sH  hwh~OJQJ^JmH sH hwh~mH sH hwh%mH sH 5_%'Ruvw-..:=>=M%(RTu ŗǗuj^jhwh]Ba]mH sH hwh]BamH sH hwh2mH sH h*mH sH hmH sH hKmH sH hwh/:mH sH hwhmH sH h@CmH sH hwh(mH sH hwhmH sH h mH sH hgmH sH hwh~mH sH hKB*mH phsH hKh~6mH sH !M ؗs:ՙ}N~~:RDPH֦gdmv gd{gd+gdgd~*gd rgd]Bagd2Ǘɗחؗ -/0:stxܘݘ/:cjk՚֚N2Ź蔐ynhk4h~*mHsHhwh]mH sH h~*h~*mH sH h~* hnh~*hwh]Ba]mH sH hwhmH sH  h rh r hyo`h r hyo`]hyo`h r]hyo`mH sH h rh rmH sH h]BamH sH hwh]BamH sH hwh]Ba\mH sH (29'(jklo|}~:QXYZKNQR^|u|qih{mH sH h{ h(c#h{ h{aJ h@Bh{hwh{mH sH h{mHsHh@Bh{mHsHhwh+mH sH h~*h~*mH sH h~* hnh~* h@Bh~*hwh~*mH sH h~*mHsHh@Bh~*mHsHhk4h~*mHsHh~*mHsH)^oR`n$&D|~P^eEFɥҥH֦ ^_Ƚӽ޽޽޶޽޽ޫzzs h;h(c#hwh;mH sH h;hwh2H*mH sH hwh2mH sH hwhPfmH sH hwhmv mH sH  hnh{hwhwmH sH hwh|amH sH hwh+mH sH hwhmH sH h{hwh{mH sH h{mH sH *֦P"gdJ~@kd7$$IflS t644 la"$ & F @7$[=&#$/If]7a$gdJ~ $a$gd;8gd;ʧ24TVprtxzƨȨިѱ¥zvpbzvjhxh@CU h@C^Jh: hxh@Cjhxh@CUhxh@C^Jjhxh@CU^Jh@CCJOJQJaJ!hM2CJOJQJaJmHnHuh&h@CCJOJQJaJ%jh&h@CCJOJQJUaJ h@CCJh@C5CJ\h@Cjh@CU%24LNPRTVbdhjnp?@ABŰugu`^``uOh Xh@CCJOJQJaJU h[Vh:j:hxh@CUjhxh@CUh@CCJOJQJaJ%hM2CJOJQJ^JaJmHnHu h&h@CCJOJQJ^JaJ)jh&h@CCJOJQJU^JaJhxh@CCJh@C h`1h@Ch:jhxh@CU^J hxh@Cjvhxh@CUPRlnABwj hh]h`hgd;8 &`#$gd,k $a$gdD| $a$gdlW!gd X!$a$gd X@kd$$IflX t644 la!$ f$_=&#$/Ifa$gdz( ool FOR DESIGN PROCESS guiding, knowledge capturing and reusing Proceedings of the TMCE 2006, April 1822, 2006, Ljubljana, Slovenia, Edited by Horvth and Duhovnik ( 2004 ??press, City, ISBN PAGE 1 B`˶ˇ˃| h;h(c#h(h[\ h;8h@C%hM2CJOJQJ^JaJmHnHu hsh@CCJOJQJ^JaJ)jhsh@CCJOJQJU^JaJh@C h~h@C jh~h@Ch@C\mHsH h@C\hD|h@C\hlWh@C5\    !"#$%&'())*+,-./0123456789:;<=>?@ABCDEFFGHIJKLMNOPQRSTUVWXYZ[\]^_`abccdefghijklmnopqrstuvwxyz{|}~  !"#$%&'()*+,-../0123456789:;<=>?@ABCDEFGHIJKKLMNOPQRSTUVWXYZ[\]^_`abcdefghhijklmnopqrstuvwxyz{|}~7$8$H$7$8$H$< 0 0&P P:p`1. A!"#$%SS @ 0 0&P P:pmCW. A!"#$%SS P TDdU[7bbb  C >A&traceability_model2:EA+Ed11j ׎NIw)y[u֫LQ* xn7Pk#6$c궯B-7Q+aIci7}L#$ye5s?5v1¸cz) ] Oю>&EJYEoc cAlL(_>.V̴GӴݛzWlv1ruxGSQۍOrю>##|%6kiZhS-bJ )R˚ _)RBV+ɉnpQgu; ߼UJ {qm]>x>Ytܒ E&8ɸ5mҕ J:h 2x߭ucFzh7+= GfBWrEϼ+.'i'bbyuco7l̛ ƛW79l\eCSU^;\HeHcpƯߜ*"W\8{VރP"ɧH*MLySAXR=W[Vl#7B P"TI[?\+6uvs^xŞn.DŪ"قح,8<̡=CvqC~O8LRGy)`$8ftZrmO0#8b`w AP {7#gYAlh܁}vBt~hs}"\Ggdq߸H7sD9L ">pB`H؟/ivN:>NI'ߥ1p}* ^o7 .vA tGI7[lasI/E *9 ac8@I؝i9 @oytR:V'9eOl=*Imz}gOc}l=!p/zaN7._vt=섮CwNwb}숮ǰ~O;; stt\A{J: +oyFꗫh\MԃloDaVAz~';i;?;x;}Wx+};o4zPj5jWo#7@zЭ;騠pV7^g%~@97#NYMunǜ5=gԂ:PMk} Zvu@iFh-thF@b=jпvհFors!RAT+l5y@HU1-tZqԁz7F7-ktڡwbNA)F{VBfsTiAAlAUþ ~:=xG C whԠՁ? 1q>V_;K<`,H>a7ˁ4B/ӡ?jNiDf:YkV:NkZ;M:X:c'@yrчܭBfs7љFnԂ נ a_ ws 0huH2hsmx@ %/%j_ڽMZMG `'n2iɅ^.tC:@huutSqҵӺTn, 2K~G@?Ӆ!AiW}dG^UgWҤN!/@yQ )~T;oz蚡o8f2jiV2Qd ٚJr4yIt61"\}flg|߀7( 2K~G@!^@9WR H' M')x v?tyn|ݷ_ߕtse7/;kF%o>pVxP4?W߯\}7odΑ\Ѿt/y[\)sJ/睧V\?b6G(OxdAy ZVJI 9Gf$g;̄֊ee偲EmOs itn~\cw\cv<,3P#nG ===q}M׋&ƄrPVx( !L;YGJzN4?5hFq2a}W-[q"#Ɲq6 <=6:m"<z.)_zɺpkvhzEK M6VX=+{QdI`Q(+F}czòǤgN@߈*" ު-^?E2|$}O&˓Ӣ9_,Oz3M=V: ˓f˅!^t)C, Fw|(e#Wf1/rR0>J7^sطSɞ/JEVƕc~w+M W^49ю"(^lҶFyնI鳽\5+_b]P3ʫ쒲%>`%O.\aLk_Z| 7\y'Ϯ~΍nV_eNVmj3W9 V]OKbnp;AY|M*t>L8`+M}D5$^(f3tk#% D{StО8C#QDd("  C RA:vrste%20veza%20cvorova%20eng"`2ԩMKS(Qs/4`!ԩMKS(Qs/kdUTx\tŹ߽3;; ?5P1"OjSЇ 0E!bR5@A[#cTEJ <8Ҿ'B= ϊT{$^A7wwrw7& \/ޞܜ7{U1-(JL>I]>ޯRTe"_LRvH6Ϗ`O[ Eb/vd)7)Cy>4VT&)@"W)bZYsɄ+ Y֠ϐרN]_rwƎ=Y {}\Ih3,R dEo~D^\9b p~M;~Xl#>Uߥ{ +EJ->Zan'>~[P X1܃3E-1\ ʃmw{%p/+N9VHܲ>̳̓ 9xȇSEY ;k岶S!GJ_J%O)d2+HRG&) df[olG*%HT鯕\䟂,zA&mAV|u3yRm Ou{"υ;UBrW/jF8k\@,F7_5 6e(Rk#HndnxciGNFO"GltBP)z Uv]@+ס!_Q~MQ%Kn| ^"tWƣYc]D㓑WxW$ ZEITW++*Em`B*$h"y "P9f[olG|3-tΥ/-&A6rӸśy@.:g=Bv}Ic ԧ~s*qÆ|f1*ch6{ -aP#;#o}/ln|'/E|+!_v#[p6o™gi&;x+!_l?7A=@}%X/]G8@ p;nDOP3ۂd3Zj6ΡɌ{qRgOf x&ۈ+x9{:fv *<\ l^B\ We'`C3ۨF%?߂T~w7gCi3AYft&jzDDZ}@%3,Wfr6Vod-Tofeqπz^\glB}o|5صWR^FK8G|UPz~G i8j9ϛcyygN3x3:anly_g WMb33̯1fYj47+y\||` ]myC3|uY͐oCufk8'>^;LQtoÀ"-::h1@BTn݋&Z3QU gPY{ -ا˭|*۬B|V@[yv*O oT{noD3׀={_ah=iv: jD)~Da.E(l}ZKB2N$YAZG d y3-#t-͢tͦGi.K`ճL,כI,rY`O]_R2B/j_:C?L2~h"YlVVGY%æ26f#Ȇr7>gSH6$:r'_M&27Av;߇f[gcl=&ӭl '%` c-492ԧBDE35*lm5O[ohVVm5hFm[+~XjVg$J "RlV)j;ZE[6쳀kB2Ю yv){(jdݡjhS{Vd7hyv6Ю4{vjS 7mIq*Vhbk5-6|kͳZ oD+W/ jk^oM[6L?y+g}ٙz}NTNr{e4G#fp_t~,oqx9 fj یs_{;Ft JFvkK$? U{5݀OP~H &o W2U\[n&߭moF .W];Lӣw8QXi)Jv?QGEǐ>Q('Nf(cb =l2c)[HTÁ0z$:DjyE}举f:~MUkM׼96"?>REJk>z|w^GGRm-rqZ,6?r.~kq[3 [q-ROn趁LG".ƉWx9pJX^E'ݪ!tH+>':qt+> nW\nE{K?n,)nQݢE tǯVm)A]H{- [":v ҭ<Y[Bjo_G̏}XTxVt>+<+O8qPh_2:ۍ&1e<*=i8;)Rk)pkh\K0G; Us8sh[+H47k t%r8O|jb| E'j!t))%tS݊XX81@N閄-I[M,;~[I~\{- [S4 !tK-M06 7yƾ0 mEB Y/' [#n  /q?⹥CC{ҭBFo|[֍nYݮŎnE\}ɣ)nYݲe t[8  t]|3([B7NHiBw[@6;gY[?"-[@yGkH^ 4t)UzrQNyޘyiQCbއA`9͹אG_ySi7~y;G{=awp-w.RwDyp׳ul;k4v^68ĦXn7.a!樧A><K=|K>8—-8_ov}x6[|>Ml /a YfXv]z|yu s}{7f7 bë?ϝ+^fݙ tg&J8bH ]\k?E'ݙ!~ޱԔ-AgI)s47he@^w?s@_J\\q?P^T)s:EiR *e5]sL76+\8@(ߍK#~P~ I8qNsTN K^xS^Þ[,_hPW;=;\> Yů+[t%h'W.^KinyP^MDڼ!5mzG 32V8eYw52֌TQ[kms>8^rlm!_k32S9oѶj#N:m62#Hk(}bXm[^ im???کKm#;mc.m#,ƭs(\H4\zDsUkzcZ я@IG\!(&b-}X{W\M{._z }9Q=_uK*γ LuYx}!bEnU,T=zx JfILqa/ugm.E5W"/\ +k]#3EDrXTm=}Esֱ_LGNqB;[P4"-ėCWRK'鰎}9ISI:jNaTs벧tXK=՜Yߝ/:$O=Tskp'M[R_(tb'.r9tb;UDb{PF =bHN[$*qOi=tbU3#A I{ۈN^%v6OCaU{]U\3 ևNN]+=\WܮpG=_أiqٓBua/p|y歟҅Y IgfvaڅYIgfA‚wM? z(.,Wˌςt,qZDlF? F(8ڋY0΂( w~KHwV/tU}.60]l`u=bsYgbua5B_|VYYeYqZXl8? < ͂`bBp,Ig ͂+ VkQgJ: Vh.,xC`bBpe,IgBعyowƍE^Иq[n,ba>Kl5]@peqvO= ƐX?Cb%6XC=cqyO=F$%K.-977!c창a,3%Ô]49b; #KHXĐX!;u؃LbcՉĶs%M2%Tc&_|~MOw7r9rov98_Uɹ~7iod߷bG\>u(o\jNݢEU j@zVeR hi. s߾VGj+TՓuU TGuߊY\qKz.V. S =QxGϻFk8;WuߞJ^;_PKb-Uvb;l%Z'މ ?yQhΑwʹZ^KwC>y))//?NkDaz|#Oyr)!I VWK{K#iIyi)`)]G}ufq0.TzF{hg1!RY,8]&o;WB)/L НtPC? O5B-Aޥ ki.ѥG-ܧ.˅ga u-MaA}Oئ>S? -BS8~.C/شIFPcGF$MS8NĘk+kľ`6\(^,|`0 3-lfS< 㛵,3R4fd󘑁if6cF-)xļmOn>skrmjyQa {UŒ=/%ǧOB`vUo]Vj^z0}Xfvfz.$\|-$3 2 %lgVT&gb?~3Δ|-dIf|8Y>R6rLm5?7^T:7 2,5')}-Ivh?N?y^9S;^~$N`R^%?HOY@8ȏ?w _e.~W?,|W +92B~40QTeE/r,|ʽ"l~Ͻ, q܋ssSp7Gઅbaa"w0&ʄ.! q?%\ͥ s\_+w¥:VHbvCh̷A ]9/pז#\;$I⚈}ER+>\XGV[:UƽB2${"㹹d"WC*R=H%p3H-WI⦐8?yL^J.{l>1]vTO秐jg{BA"o\K>"gV~!ſB_%"u 9"?{OWMN@8 q)B{+G py3#x.ϴϴʹ3yccG;sR~ 86`,])ƙ#}h:q8=c mnG54=?3#[3 #,'9Lj9z>=F\&\!^|/q#G\GWsVO6t_(`+-'w1,gGSm$#^P(d[f,k~dE9=C$WhL7qEhČn-LsBc=1hba>_a3%ӗt4gxھ7⾉&*(WN3^Kn^(2>|?e{# d߉͸Rc$e+ӉE>}BaE^VX^Y#4 D'Dz-vVX^.qdd#~ڝ~6Ʌ>+2lmtcGd\FEd}ӊS+7w霙( מEJ͸du̇t}(y6DA?#'Aǰ K KfVJ_E%{bjIeg΄fhY5{˜ߗܻc:=G13>iPߤRv_TɎ"w}3I8VOcyG]ƞIĘL3gY3B9lt6]au 96-Rbml'7t S|'**q9f)B <0ײdeO[8zlkTnV'mOEa [˛W- Z>+x\r=d1k^{$+xO8565)dϽcWbU1E{1` {ܻ RJs~L6}_WVfB{gfygZdAk3VƜҋby0Y}3J L`ibH`JP-#ȅyy}sqG3lמ~փ’pZ!0pEh֪k^7FRPRIw/cKE]ҥX]Rƙΐq)MǔEVT|i;'& +P'⸘uGjJ݇3'[ AuhN ;u[&Du,cu3j0n3fop%m.hMqgkZ:t6rߌݷ|? S_ygWgٯ_KYgGDd'\Sw"|YA|/4g|˲F巖%xx:LKZ  ߛ,Kh,۟=C:{^Yx,Q`K1_ L>Oɘ pH %O/]d\&Iyۯmz~q̎W8gg祚?˰~DI[2ݧ?ovOka>gWFX/s[Zaug#xY/)*-A,iSouvGqV)zOޙgu^fgJ?2oL4skc=.e۶|2of#k[O& fzR1P: 8·9i]2L6;|3_z5Oc,}Od}朘TntlQϜlN6lNzQ{ƞ7܍:ǥWZikft >9j}cMS[:Oup3Kz^^L*Iqb [ rrFs};PK3j#wx訴}hNڨ1zw4$NVM4ֺR=X[ĵ(F7VnO@d/WTA&&ek~XYPQV]E.ޑ[z-R%5+&>8eg.2B]w Sw l{E;\w;zkW?`U;r܍nqWږz{#wMN=mw۠ƍTq;ݯp7rq]or5IqO(GӶLN]#Jl9Rm5[ '_8] 9qۺ{ږ%nKm7sK6={_xlﵭd{m[}mmxLۖtI!6ambYcͅ#Dm_1'vo%!YdMԣ?',?wJ"eMŮ7,r\~ư蹖׆%OeHk̽ [LÒlaI<&]rwXL2,XyBU^P33,<*?>>ʯ"nذ ]i9[腡Ak\{Jea s5q- /-˟ѷɇ KZ]ZKp:3MB;],Kaɴ,,7K<]XNkiZBw,<;>,w^1-ˤߦejôd~C ѻ;"i bevG<Gs=2Sbdubd5 %m;e2y"[=`YB[hY Õ9KLKH9#y,w+5Ϯ-KY؜܋%4NՖ%4K(\)հ+51'L`EδvrX+!ffl>mƾ?Hp d b ev*TE$ԣe=IQn0qmHt%ݖ@mo ev*TR551g#lP\j9ֆ𼗈|"q {X@CY]E ?LA2#f)bCrb3ym;Ck_w<qFn|FwڌF1pІ4 ^CH$;KOX|k(W᧒ B@ @؆-zJ1'&U4UUԫSIgRP > mRжh0mv/yўHKv=**UDMB>N:FB[n0qx,G"v`;С®^J |w|G-/m]N/)v&R9c ev*T1v#֧)bv#=g+yIHR aX|k(W᧒5V!*^V#5Na}Ї }3c'c eC>~p.FEU]!ŒP'C @ `C>ԁ1jk6bFȡ&C}PBcF1vcH }w|&5x_1F((cp pA.}0v.} @DAh;e0tuCn }1fnc>6 [ :|;M vv< .PPcB*B P`P焏NVQMc#ALiC Р |w|G-cj ٠ xl!¾ Z 펰%. >I6hbA6h g縍&n3mo_6u|D< lGl*&`3孰oC}#C|w| Y< 3ߠ MZ1[P 67¯Q#vށvL)lв\av lAy+PF=p+\"xax7h}~F&`3孰oC}#"bX/ "rxI0yjƾAko:7iIނVط~Z5EYUQP-< ~8wl&`3孰oC}#.Ab*Fb.A&h |_ Wp4¯Q+vl7F<)p< O@sݹ 9mo_6uO^6&C}ޖ    aKB]|m%AY9ض&N_;8d0}(Ї}(Ї}(Ї}(A7;d0$ }E>(A }P1#v܎;.aX @#|;|;| {~{>+.ڼGM3߭ kki{*W2V[X;n۟u)@2::u$ٻxI+< u`hm]ɶ.N|'î^EĚ{6rAZa|wu] ev:t(C,?b"90\_w|Mk_ 50hԍ(Bh;7yzxBwNwduuӽa߁h3m &CWm`ջJ({;ÖNNhEe}xݻcgOw2::u^6 uN8D mp x;[90v#ev:tQa50Q p-vvNvv:1v ev:t؍X"槈)r؍{&ʕzx|@I)NFY]G?ݻ1V#*\ثj_4y }Ї11v2P>d,bXXYa/L:puPPc@ @@QXs6bF5h_+< )A1;1>(C,?b"9a|sWt]\6~8X (ς UB`0G#Q(jGKDŽtoB"a<Q{WE*Gr.GS91jpKc|W< *W!F-bAZ~ 9 b|.QQQ+x X,e-]6Ж0K{=u}jjg^*UGykf52]qsP:z}:$Q{WEwug|?Chxb[ut\:6Q{WEGau[EhxtjLC+bjiyL Q{WE%@> >|2$9,dp=ͥ:Z͡sZFyU_M:#Fꊘ]3rHA.asRΡKZFyU_ F!51 `00psC'n 7 7ts4pbA9oB a(]Ї pA.}>Rp)QXYS0jp>(A }PBY<51k1P\N60̵wmt5'f?}7c;I?I7h#vyN۽^Np7+[O( &oYXXO#ӈ4rX\u< w8uW&[WߛQMC b=#Aa(Rww3~O;~}lP烏>w&CW{3þ 1͆m$Fg|GHL܋,2LhfL8[=Y ,^!RWrl5 h;}TǸz2-"`)ao@}I I}o0| )zRTdm 7!^ڋ{{rϙ< ד"2_ ,7 d=>D̵!rX\L>W5X'CTaAX ,7#2[9X< O;M\DXK7~ `>bCy9#'nzB}Q})ao@} `:bLCi9 #P1; w;@!pp lQ7>{ f7y23sEdc11t,Ey9 o_I–ߡh0y.w֓5Zb` 7~ 6&G' Z Z Zb v*Tkh+| ? 0W^dEЋ #NNN{KLQR^E^E^}"^އ&F 0B/zG PB/@`#C\"ueb1 .HuA/.^WX8o.Cc5yOg7tsC/n 7^01!<Ĝ.n*UE^T Ћ ws01!4Ĝӑ P1; w;@!pp lQ7>{ ܦ< |A^4EjЋh CaKC IPILc}1K @/1K \zu==ѦWżKWbX%z^bXxX@]E ?ƚ| ?A/8%zA/qK;;a@\#&CߟFh}]\]u88w\?ȼ~WfuF8ۻg{D5%U1GttS8v9;2"Hϑ3 ʳm^9M^"ϐyY6J&-S;7+8*8%:ٙς>ʗkrOm_以Wv|ɎC }kz~ Jo) 'Y {l{ܭ=jƱ|T~+ϟDŽϤceJ?.d|Z|{عVoXg_?5~Ũ7[oi>o7;ZoFvG&l̚,T^[fyo{?/MWҸߥ)=\%Gƹיw+鹸xs7Id=?\yWU*RT>G_%mmgQi/=omۥl[ pl_[,NrG?p>F箒r;9<{RͭU|+p%se#F;e/?OC97*&[^]a~0=ȏ_wѽt?ҷW*o>3:KDcom?tbctbg??_Mj n"+KFFjRI⚈eZ^̔6;{I̊8wNj~)Xr}](;Dd 20  # Ab:h-5K-;d:Unx:h-5K-;dPNG  IHDRV[}YOᙉqpԿ[1my`v;ϴY4xj?qZ(f>G E-ӼVflNך$sK3&r$$*,.MMmO~3t=Soލ~c_b+ *'GG# X[a R2yeӪd-fr/nX $sSaT@%PkqZ3l-: 49'(Z4ڦyJ61VZ|~u>nm)Ci ylR6Xqgҝ04#VYUC}9[iUmS (1rїiUV}w#7ӪeC^X6oO1z=E^h)npvJn i/TBªYTkta]I_ޡZVu3o0Nxm5="6dnk9Jhiv۔ڟ2젃{&UƏc**fVjZO q#v*Y=UT m[FU+Pj$TUgAܓ[-ſo@-bT lg(MRK=_'^{i%pJ5z+  :Ȓ`!@aوM2 SZlc&L8O$k..şt*{Ӯd^]1^- Jr77~Z|8Ǜ[jUS%8$[ҮE86s:CLx7-?ͧ̓U$̕j@<5E5r:z W*˦ɤh5Ifsf\}򚂷3p KKW]y݅#|>6lkS jho:S3F7ڳOnPΔb?y0eFB0SV|⃫MhUY/Ge}h&= 4ZeӇկ681봹hZJ̬Z^1dQLfI+PdV<CNk "fVk ⰋKʼn[x9)-DžGvl+D߯0?b;-jxj n('%70fR6%Vc`)F KW2ɼ7|3c8'HZ Y? j`Yg…iC)uS۔L\ȹwBO KXr &KԔN\D ]5Nt[Ԋ@;3aK?٬^>@meMŭc2.1dUX?$VC&/A4׻WuEfRTb5iynΉ.Vbe=?ZIk 3w; Z V"+\o M޸C'~Lq%i֌FUh҂<ݱ]Y^AknH|?VXŋnoU!;@JD=s>qK lIUVM Ɏ!XAMj=989 #?yi.jx'f4:i>blHԓM|Y"2L@Q gJܞkZ2٢e>:zA+¾.~V-Vw}NyÐj)J5Y=oRJ V>(0༽M][Dn "MU͐͝ 3(cމz^ cd7܈b&57\8#`0tL<4>KPPV6|RL C̬;$ÒjbMOV@bi }l,{e`Z[pf [Л|?gp3ʧH?uPCysM+vG+OMߎRtufՔpt ƴQ_Ց4鬘VFsꩌ%b_z-Lm _8)Xh#f/̱ LZA'{_nqjVU 591O=Gti>\pOqjY N@gE/tĐ5ukMb-n2t;/4.މ.aZ:س/INA) gQvr|bȅ3#v]^M:3nթfoIiWQ5-%L3JxEVEeZG[ER'ϥ˂j ~<3DLB/mP]񹴊rT4`[DD$!=H=):$RqS[06'K"p#q'&٘tci%Db_>zd±uGY1"rzF;V a]x >b_v՝^!J!ՈI$r*/0ɾ)g9y)^rTZEQ΋ᯯBPc˟pzl&6Z]X7Ln$B@̆}o{bÒ >*~ /ǐ_hPniqoEh5n_S'q 5uo^Uk #ŴJIiZz~CK \g*O\@K1fC0v$3"JN:L-NЋ#a DZ=@^ a߆bqm7EX"RMHǦ oڿrn닭\ʪu3|4O]{d@u\NYVU.K@Z=$dgy!Ssʚ[XϲW^j*eBAR:L7r希@ho*ZD:VeX@L8,#@B4Ze$ 9#!pY고uzp4{D:V:"Cɓ;y^ʹ{Fnz:BkP߽ KbZpbsT+ZWubz"_ „=JwJʪ4bh}-yc|(: :\!SCx!Ι">6^$G cR &V%3ý7+ kϢ.wwWwNcisV6kM̼'4ۋ(a S2s:VЕg̽';W-M[~vHjOtOqTWD`I#Et2:,0 X]AE!D8D+Zg_90 t1."WGnGdw[[3VN.鉎>V!k=P̓i!VA_DO2 Z-( A!w0DZjn9!6v쨁bfd9V$P|FH2Њ,gC\W#@y' +vdPȀ1'W4ˣ%#o4NyaZyC ?`9v= "S#x3'g=y=XZt<Z[As<%9B: Kf~Os0!\\dShE$[!/2vc:Hsyی8ih!e#IO\ $gChEa<8vhۋD!w6J$Ɵh>N4N;pƋ. tUoja%O/q.Az2!WJF j;s-R\1;V4nF)uVz=i^LIBT4՚`*FAޠr~#":Gt?pBZVAD$Y}!Z"B.NТ O]NUs'xZ%^/NZI yP> [s|x.f/Bѕ,m@vBprо!0#\`, Btᦼ6^И^C5Cѱ}. 䢷?tĻQ^1t! }@x:ekZ=<,  'EE`]U#vA=egZ耩&`yF0I=<("sδ*kp=RGzlL+.Ts:CbN 65u]6>kLv]N]fݗV:;9qlF@ /X#{ixψj,(C4.U+reDz$+uV4.F!}NwٕV_Ѥc{Mlˁ͌Ix1{ ʓ6n-w(q 3[ lJ+«.&Y=r`H5ƧlJ>1Sj| &+g<˔RlړVot_WdqqPyJ̀cE8.{E UGOE$>D"yZyOwْV7]EsRF`KZ|0Ϲobp wk8L+_)tN}9v6pf烬( iN rXGRL <.Ѫ3`i%l@ρeVC>G%`Z&A^꘏X80eHBpIDV|gSIfm#gh0v &c%ϿMڀX@c':SyfyHݺ X3Xc+ʌ%LEX渤#~Cj.B]vi҉жFu10=J'9bd^ h*X Y[rIDB |h iha `]:l]0L9}=~QM(0x=ۯt&` oPiꈂrz'+ hI82 W ,Jh8L\U!Puépd%b&a˴UI)N Y5ΔM|sܩ6Z>j]]xi|};bC`6KG珵%o @z LR$瓕/V_`-ƷYGN f./Ew Jnhtg;\&}?6)Tntu; cܴmpZ$i%_4vhkT=emZEܼ n&^vJIIh.IM:qfo˹3w1)*w~$뉵EUH*mLL1JS>!btƔo\Ӟ쭤P' r{%VYі7Z64ME@$델z+i:Qo;zV~R1WREJf]VI ǻ^3LD{Gg*'ZI7`jt0GVߜ{Nbn$VN"! x w ɚ N~4PXrǀ(Oc9, )Ow*gBao=7|~b# IOìPC.*#%`BVjF݌_,/X=2(͖h q-Mo9[-P{&Bڿ7 M#xe {U!O"WIrތWT*%j40!ĬYk[] Dn@?iX~j*p`ဢEK= I @@)X&VdbaZ5al%SʃXqثcXb[ rڧ" -Vy(-OčQRB,Zޖ%CYĚqZFXr5t%+;M6F _[Y+Zbk39xK+ò&Hok׉H+1e" fL^tBe͢20bea޲Ҟ"5B[."]|yCcg@ [-6Ay^2̙X gE'؍M:H0]VU -ĐP6F F+r_ WRm6$ˁr-.kӈp )xBj/::a>;ȉ q>ڇ^<ڧ9R(hdV5(9!@L+eqnh7LiU5ꉽnM:}gP[w`.<nYo[U ȉdN5ܣ=~}-ŭmd|Ģc!`ʄӵ6b7\{d׾6Šk"63sFbIul܈^xW桿0WYcޣ4<~y쳫m+=b5MI =;)JxKU&8\̘Xiޅحڨj%sP>Ƶ$i* &d(YQګY|qQ3hn2K]wڵ?uW!`8Snh)?I4$Vb=xF'XB8&GK #P8NDf,BJ~< DLJhEWԈ~&C#\i [:U TI$/h}](&ni$kM nopc&oϨ8EިWcxS NY dO=8ij[& BF9.%r\KWXY爨0ZYБT},&&7l^D`IνϮ٬iZ}e:"UX]!G@Z ͬݵ.m,*Fʫf2'.\%PYxYm{bR3jil(\7T) 8Ad[9UN&|b8'!W=U;;Drc<ҳhL3gp%vǿ̭M/le!{a)8rKr+bKP^y V9^+&X 'aZu!m^"p,Kk3'1puuGo V4&uwhĐ8m~@][vLo(*0t+3E廅(WbRJ( b+p/`2ƃp|Î!zB9IP92o(0MPzXW;,_4P/c 6",M%`Gz{yV5R~Zn!5HÈ5X<[𜏧X &+L 帢0ײhXeXyOMLDM6ÆXq"S9OQDr&Hh0'T!^!ϖ:7d="\I)53Fj^ |ĻfP$6hajk9>nVhF mo*G8`x?UԤrj" _F h8'F,1}BmxLVInl/rU{3r=z3dRiUZ84A'07'[ksG܏X0S-Z|~"iJ4߄O+C6 ;jO̡C7%.7S`UPgveڛ}`:h ReaR@VOp'V.S(@@%hU$D0mM}l%A{VM-Q 6P{a1h hʚGY.pbI@:N7i]&s5|"cZ.A܌ūa" 旐[_߆jͪX1M.A%veMr B3BLjPE.dSZn9W%#쌠l;6ѶoJH={HqS6aZHQ ?‘`ZBjjo>YE GB,sb<>#D ,Fʐi5 |Xlǐ᭾ģbJZ0])8#jcW7g1fBfXuδy k j#ZeX/j~KȚĒۖV+`!db*,ڶ Ҵie ҎmBŮiVMm+!@z94` V %HaDS_'i$iC,1Cx,79 %!А-() /JX6Nzˮedi)iPT82]P:#!$VXy$ !;!Ӫb/%`Z$ܼ!֜GR Zƴ:h*P7 &ؠ)qiuX3ȝi5XU,JiUܑC,0s0tLqط9O=GcZZ*X!Թ@!7iuT V8, ҧ[9JX 3֑B>:W܏]G%o~ܦ;ʴQ:N}csu0 [>xgtʵ+D <,'?>0/}z+DM5OD <5VͤV !/Vlt󗰝PBP7RCd&!dB,1',ޟoNdž!I Ejۻ1ܐl^]]7*^d@6҅yS:VŽTۨ`ZKt2㿺U0ʨ JYAʏQΦ Md(aHu^ ;Db{t(jSQ5T-ZU6|4S!pvM0Mj2ϿCNՠB  PDoY5ᕪ>͕zrSS 4ƶd"㐀oVsAIV+iڥ h4ZƯI/Ӯ: -ox$]uw3>|R>R_%WrxcF?Ch׃E #y,,9VzzJcޮK"UHC('W셭]ݩA௦5\ !6+'N[._Ejx.\( Ԉy"Z0N)R#4eyL}j-9,-ZSLi5"^c\`rjGkET#"ڞVறQۏWL+ w)))3c ݪV4Y1S^bfY~yUճOyQ[WYCD^>hU,i > lտJrS>'4DX>KHoJ/j]j1A9 . T.hNd ZFKP;-흁V9-%( VBl/X<Ո\ ;"" _lpc\Eq[ibvBE+k&cBD6V,I0@˴hB8V}WחTx׊y *)@ZujFLlUW^5lt5H",jWAjE}Lh( է9 EL8WYMU^߽F y+BߣH-J`ZuUu-%RĸvV|†h#R7[ 3n_OVJ (xOaX/`ωJ3Iꇸdd \rT Z'C ފDq q)aK$>CX&>NxM=۾-`rv%$s[녩|BOd,{.ĀJM@|A V}>g+iI{pJkUYUVSĂjCM,7QMXwSΚj.Za_՟W  -6uQ|O5eџOwܑv@cm`[vOom2qV`' #˩Y5H\hLm0Za'z!l`Zm,W`FXfuWRF*eRp8 RM9. UZr&#ƛhi{U/(joԋ# 'j)Aj#v-yܞM^!0p/^L5ks[.ܻ:ADn kACdM/ NRV2$ htJ0F1SylŸevm_{վ)LNJ_XE/1/hrsK5>y[o<2>kdZ1&l;La`afk j6E #"C*L+*R #"CBUUF[)bTdm-uA5s VVA. dh!.Q&IENR(%7=F^=-p],Re`Z%%PEFoy5=V*BWL0GعiJytLNĂ%\H>%b`Z%y|e9Ha))yŊL<ǐт(jټFdZUP%e%=V^sUP[bJ1-WlLqs"0VM~>6iE:(@Z3ǹ\b\gvVetjon/Ã&zVBZARx(VUFeXM~q3iJ9y/JLwRP"?G˰TV˼&S; iuTuwDiTN`Z g#Luj8`Z(U`VjGr#,~GV;J4;AGIENDB`XDd3(~  C ZABthe usage of the proposed system2WqC]e}W`!WqC]e}h  eeWxx;6Lvf7mCtNh"RDDEE׈T!R+HQf g .'y';;pbⲼmZ .,FBQ6[ 'իW#U*8Y,%t[QC,g[]?e˪7t9.Uz.Sٕvk*\ʮzwӣ])u^_tpѿwO9G_8]O8#!0OWwv:z-wM)z=G;^Pw Ge(q$E;p8uêG9.kQ4q2Cg(.6OqVu:UEת8q|zcxKW9^S9֨MԖj[2cݱX۱HX!x;:>" bszʹL޹BJ\9_S|5wT\]\ڮo՛]gzj 24j*:e~E(?J*(>J=*G;(%[oWje'. } 3Begh<:辇ؙJy-W0r k4'kngM6i$E22\K.~Y,C} BٔG<0I_'9~zq?)]tkֵ[݌( o):͏=Hq8Rq(W<6E {UVE[('zɕr=>=wԻUn(ȭro|UX,·ِ,V&_jդV^UjuJͽ{El-y/D2}b}%*ޭӻI+7Bz@<{rg1,P׉sa+NqjZ T׋o&U;-}mazJ^b7U*NJTM*!Q*Vd-S\AM+re@Qn;Z{r}uLR=%wT=BZ$PjSF)թSEe*)a*+ tBu_p-﯅"!85TYԵӻ#jhEN]se|5zIcPA-M\vM:NWסJ5tҤ}-T˓zZjXy ,bZ9CnoQOgi}B73nۡcv-j gO;'=hk4iڱ[`Jǖ]{4³f*ŷZǓIcZnuر]JM`}q~wψbW,W`"t;w>;f{vQm"MN]:6k^~'zQfn=ۤCPLsŏ?ȣ_;Vۍ~ڿc'F-:jӡE.m:U"(}:W'Q(:M _ 6 46Ow@`#m[7&s3%+3kc9uA\?'}`o?ǗeWK|k |ɾ%g}|3C}|={7ߟok|`o2wN!ξ_?w7_owO_Ow/_}Fݣ|*'*gʹ |%xJ_;-==/s Ļ $ʹ_TpOTvTsٽ<ȝh tpoto vo s t q~?0&fAx_G}5*9o 9߽B\| r][Ic`iQS:02S3- MWtѼSEͺumӱSʼnu"yy8\7zކݾa[/%p%p)p!mࢯM@0dրn ɁrFMH6@5L 2"FqN05ߘucpȼo6>4kL667f9#Ì3)Lb^`g=c=m=i1FFmHszF3ag9zF=c'!́g~qfo fWgܬ0ydgYѳ,m|h&yA!8f&zp؟9zNy_S/ T=e#)hI4 iiiI t tLT7~=\;zК,|1j<Y(^UyUJC_k|[l = Y}yFe~o~lay@@bԣo?WYz=ڿB㟭San10,?c=5h]tUthk},}Ԣji~ߴF2E7+;ŝ݋Ept_r.rForۢp;_sѫZ+y3U_t׋5ywܭqgp0 cO'T)l}{{{{>gw꯸?W诹o'ow{gOg$|AB+č_:#+w׸{FG{U(N|׬K&U^c(ښoB$F̸MoFz7h1`>̨?a$#NchCҗ}qY[i5i-85kge쁝ߛe|4v޵&owΛfdzWirRcw1;x;x1;l 7z݌~ގ}6Fo3hd{3aw<;;3333󄷩9odoo5+droeO'[޳[7ɳ a?={cLKyk=sZeZVcx$GӛzzWOSS穭Շx= ўXO#}6}24S!tB#>g+j-)_XEU+F_Ώ'>^mѮE׎~[UwgqʗTVTfR/X^i,4 &)J`UzMoЫ ʈ`d<.xA<%O3Y=Ny^p lSyg718$ g?gw3;iqR0_ .G_g}SĞĔ8CuiYIQpX/8Z%&CH1jǎBQbƎcbLj'E)ix50NxA<"  ,,?dŝ fqk`9[P|3_8 o,dy")o 7>䝁cS e@r2 +^RTb[l"&*$%&[^ITTڱ qW_f9V}ӥY6[pOz]MVw}N\~߾I^wyunŐKPNR KRCsvR'>:IJwI~v!i4BZ'HJKqi4Q!(Mg4U+MFpi0 t0M: SdEi0QzKxAZ/ Ji0BZ <$I/ wI 4J]z\h(n եGaB9 0a.L>"LYGO[FYG íc!֧ / ]; mLuPߺ^k}Kc&Զ#ԴjX?Bu8aTT:FK5cRduT:Ojh] f]"5X7Jۥ!֏Q}8$Ai4ZK"[}]|G|NԷŕe: ҽMk}NQ~qhe/SvmLN*bM^-^ۋ *6F؆`l}{غ5 bbٻj^X_e[؟mc=m{paېc= Cc Cb=ñ=c c[ co6+"t-' bBXEc!565&Uh@6 :EZXźwٺw:u"LE /“>E B__9n_k(t.t m}6Bk=OhC#촵} N::~.ۺ,}O?苳?Kimko_k`_kh_kd_;^5o1 qʣʿ]'kJ=VڵIZ"Y6{kð{=fk^QgHօз Gt mj'0m8@{_kdj; b+Pl]jtkHӤ[5?$J |Vm1*7Z|V 76͵r+m|I'!Ns0P~B+jW5AyQ)52Ws* 4QYI*X:7Z#>pc2)a2O+ 'e*ca<CM@eG7:(arh|mQNՕM7F9[# KEҷF*̔1&K' ct!6JF iAdۥ ʨ'-3H ZRQCiT&UFi,.~T%KzT*4%^CZTՓ.h SaWTZ}LU{Pڤ 6j#7'X@/i\m&JE\ZW|4*UJu}RC_3:zRO/P JCJ食TԿWg Ge2^/T&(3KJ*,/+!tBבsyuX'׾qc~g^~{g*&_WX_:Gs$Rqllﮱ%]]y+Ͳ3PQ;vcF`#tkDOW~?#\@}vGp~}}-EVW/׉Co>;=b։k!fXq}-3qi6tJ5U{:Wo˔6ClRCsʜq*}[%qQI|>:^VU[QC!yWfWݾ訹m2j+MUiX[5zPjQjmͪЊj%VMAI;TN+p B݇Կv+]J]mr]U۪4ֶ(ʹJ+m:jĎڍ<&wGPLw q}~CݾF8_#^ {3WLJX\5"meu|%K7rMj7`EݶS_o{OϷ}ٶ/, }vQEL3fMymƌ1ClA6#s-:bcB dg <#GF`/ꍹfUc:Y1-F֋zY^{iݩ[]^k=6kdɌrY.c:K6Suo}NZGC*rkoEd(w![[ȏX#)k3yLLnkk.w=Vr?[kyyKOFJտou}㷸oru.~7\ \<\q K\R] \5wN몛~W \nKz'tlwޖlt6L:$\vOQ7ᜣviG̈́/>v%:KBr:9g:Ng8ǧ;ǯv|įr*|m9sY31pm[}}+/!+˞Ӿ!Ӿ9ݾ#վ;A``Sw5헃֤{TH2v)IIQv5V&I8أIW2I '#+ OJP&'\n~ .||M8\-|\&|\(v s YB^p.NâT!M>qӄaStºYBf!-n0Nۇ%GUi.}r\S6W:ڗuugui=N^1 q@Ԥ}HWE_|-;kxU={)^J^vCXQ(ⷢ. 1Q<&ăb=v=M(!v_{]Jnq[\ +}I0N'>#cg?q878,] gq8Z]|YO|YM,/>L8N]t}x3JYY]!U apsps9D(' ptv9 ; O;ujdaYQX,/d9 y$a3(lDa| #D)1(Ib0],' ĊRLjkb Ml*'> pL(·h8V^/'Lᬘ!tB?7Rq tڢK&Tz흊}gSQП~Bs-;vib[^=TyE*`x}w|`z_(Ɉ|'| ca[]ZtإkJʵsoD=f2 zz! b8NFްwEJk(T?(͌JS8 0'}HnKdPRJwcrEجglRAF%q~fWd+̺q ]+E%̡KGQ^&v8nw8::=~ގŞb^>:7Cul'h}p۽öb_]ݶb[7Zll]k'VU+ʋemb- t1`sM [c+rB8l!Ul3aX!6Z0l6D q~BPUlk+T5muֶjB[VYVQk+/ % mAa4% a2Tw$ 7;BChHZ9 GEۑ,sT::cMm)lGoa1Px1DX.,s; : +aʑ!tB/Y:}ϬIW=5cg47}⼩ﵿϜ/z gJ^J.@zu]/4oa)'_ΔOK,FCA^棩M*7UTESG"@D|B[#DZ̭ jעDGUBC&Nkq̀5$+[˩YFR4K.c ^K\R2VTan&XxK#k6krVq/ESFF.cu65x5IF-jCZKޅ݃}{؋x{/]zxvEvFVjٌv3ڌfm)SHw {8Ko!`Wa#1e>htg+PӅh:G': dt!+](To{4gО,^h8A5V4<,Їc<ODWK3R+h%x.{1̅K16fS3ڙhf f9d"k6!{^>*dO$C{=RTscƸhꢩwsSP& +g$2ʒUʓ]^36R&nc^܄&2"M27zxGg,QCm6оkxkxgC:%;Ta8,m#gX::Ac|4uԻѹчiXshFMSjx܎xގw2 Qǁ1w/0^_yd|I!2Ocj>C4>!{_>: r&XCx8g2U^棩ލ΍>L~>4}^}}d%OvgI#eBm_^*^^棩ލ΍>ό?Psh9dY{|v;+ƶ6jRf،f<7㽅dmd(GO9̝r-YȬd?2Gf#YȬzFXWH tB Nxu³ޝBV t%\ǩ0w{4gО,^4dxIND3D<&5IxHdH!0IPΚ 5jEkZɚjekla<L1 jԚhL&&^&~dĒ ֒>^ ˅yu-2ԉ6Q-e>|4<xԎB3 (]0e@eLZ ^"" Y*$2X XI*4ЦᑆW^EJVÒ"̧v>оKxs>/EJ>j8Ԃڎ4uQ9!Cup:ρ\˧>]0ՠ*cUoDMh*Gen&FFB5GI#lmmD.a:@{Դ h[6x2ڑ:8K*Q8q8AI4'ў^]0O\K B?"\_D?W~-nj`6̅yJ?D?/O* ЇY {Qh]EdBbX!Dm%LFEa d@Pb 9S˧>]05:cՠ*5UMF6dwU2Uj*%}lv0vQwѾn]!cY;a[-Mj6R؀<7&o #E ij詮QTYéRfCLgXhOM;jۢi-mjg;ۓсY-Xs'ߠx[<2Nu5=p3% j9 :x"KÑR} /f<^&M ʬQGa W&21efCQO}>a yh`1H>alpNpר5;2Uٝ6re>|c+L?2\s~Wz VwI I^NuNsPgL2?TjHW_r-&Sݯ1rCN00i"5&! "ޗ2\ Ex)B+x^>q ~\`< g|{< g>Ky.B3&F/hߢ!C Y~2G]> Ї1,ijFڧx |dLmXMNM5j*Ug5QZP[v.ޅԾ={؃<=2v.`'=alel l-jB&7x| Mdl!k+l+G7-L詥wA/mz=Z&dA69|u+@&0:RӁhڣmG{:dt& h%}pN1-;4ߡd}K)8I#|Ih=!KqpTaF(=M}k'tP3sUf?rϣ.|t G{R3!hF05!x%zI0NpŤ1I U՘ls LY*J?OOJ?U%@TLIs#K̽ g!,E~BYH? e2_Tza6bl&LfLE;xMsɘI,] 0/M$x}K /8W}<_u+@e, I6M ЇΘ^j Ї u Im 45^5w-2jU%}f=Ch݋xs/ î;`;c`+5[݌f3xlk3[J6ÎR}zԻ?]ןjla<LwX t3tB Nxu³3]H!+tԃ%a8GkƎ OR{ʿV/Ŝ$$y_{ W%b-9F=@JXUL;h5t H K  w Q(h(@5b%44Ex5óhIV+h!C=ڣx(G>BWd&|AG8P1Gx|x~'d#k?(ǃacybynM LȂls a&^G84ϡ}8'&ĸ>a >>MM` 0KB1ǫs`.K?A]s^$ SEN͢f:?~N1<3өF0 dxO5aU1e :!M7~ TcfCO}>adsv4vvL[ЊԶ@m s8@pT'ÒGѤ5tuDRd%e͆sϣ.|t Oh@@@I%}E,eT+eרQeU[ -6re>|s.E('~~'~ "\˥wex_u4)n^ :=u{<{'({oz++B&ȥ&ԑ)<'#\!;[-#1BsqKm$$+@f,C$FHb,TD[ JxU³"ɨ@Vy(KvR>+a)gd\ҋ1iE/ePw"tEdl̡f.CG*^x{sɚȞqU|& \%]']/IOPٿBclc8I?Nqҏ~c`-C0~@H?g 3~`xaQAc>q#H<q2#k'.I. .3++BcGkjS{ '8I"1B{A[j۠i5jg+[њ6dv:FXJM7j鎶=gwэЅΥ$yS<6^'/ȹ*rΊٿB݁fڝxk';AdmdoK*sU ڛTF[JxU³ޕɨLMd&Cz #dԡfj뢩g]q3Yu5KfLBX:4u>%uq8g]ٿBeW]f%Uxk+^Iƫded/uᎠ2Lƅօ/'N]dɔA2bKTcarIz8%vONU'"2WB}"ae9xԾ<_2Ɠ<:|8vKq>p:8W__ EЇ9h (īϟ.}QǽanEhzGzd$N2{p><@m4c^w2 ~K}k~&=m?|.s9gٿB!c'|J>4c?^܇>2>%%}4Ј[!>g=Q[lC#h cM95-m%Vx«-nIF CS#f%q8Wm6?6?̳ [:>ˁ\jG ;b-c̵ԶAmkuИRM}4:70cƞq}x.@EʼpY",vﶟfv~X$J\Qg<& 'Z ЌF4s)'%'y^Kv`Q4hwk(2vz /N(8-i8 4]]&Q}bDѧT]K+!:\R\}g@}Y,Z\ !pXfAAڛy 乒 e݄eE=~ݒx-%5ՒE3|-ٖߓtq<=f117x㹏^{d-燜~Τëg2Ζ5Kl!spf^^>zy=O\YbNQeA8$rvOk;m'x萣pߎngd.G(9z;ǻ궓G'NSy/8Y☢_o5|-'|9|59f47ۜ{]}.N>fۍ4i౑Fx/>YBڐjTnhb11^11e2eUȬD!uHxGMm&M❔Q/+jI|-{|ij nn&7d4?MIw Or >6rOI?i'M?i'mퟴwy[unֻ0ayV]X.k*SSOI?)'e|)'eT½}B!ХD'OT>}J)%T !]j}3π> 3}g.:nY- 7+ c ϕWX.&,+d_╤_$ퟤOIfOI?IL>!=f117x㹏^{dBClngóLg˚%s69\s3m/M/m^^<'c 1ǏI|!oonii5dޮ+,R,Ÿ>>}x^ "Y\Ku,r\mrm?M?~^<J"YW?Z悧kl7Z[֦a??x/zہt;J3J(Q;y,cBm85i8mMm'N^KtYg߭ ]c[5&lVk|5i?5Oky6!oV[iFhGxs+-26zj =ZCZ&4dh<Ҽ<332e5lF!mm&v M;m;v^SxN=Y$YV y|:^mTgjho7[SmT?:Ng ܬwfv0<^'c;/Uyǟ*xoʷZ园J_sx+ѧT>}D'O>%| PU!-}Ч_~}g@%,{ erpJAAV\{nIJ*^\Jjo2JVk`}nью㵏>{evWzrfmfͫg3e͒9p^\m.湙v>M/m/^^y=O\Y`NQC=p n7lc# <7_}{ =jBP h<Qs nvVYv5!^yJmn-e;X.x#fIJXQb՘K#w'fw8}xhiy:dގz|4,XඏG/^}d,u̅D\+-Un]LOϣby_%c+pyQF!fۭ4##VO>}"D'ODR}Jt@ޡBC5~[% 3O>3π>KY*\!pXfە4<y乒 e݈eE=~y~??V''Onmv1^xWYawPq^9Y鶇G7n={d̔5Kly!spf4O> TFTMCE_Co-authors~O1R~ p!TMCE_Figure_caption:$ & F SSx& #$./^S`CJO2 TF$TMCE_Heading of Keywords/Reference.. @&5;CJOJQJaJLOa2L s TMCE_Heading1$$ & F 4 @4 Footer  !NOq2N bS TMCE_Heading2 & F 7@&;NO12N \ TMCE_Heading3$$$@&a$OJQJNO1N 2 TMCE_References^`CJXOQX p!TMCE_Table_Caption & FS^S`POa"P sTMCE Heading of ABSTRACTTO1T ` TMCE List' & F ^`HOH p D2004Text$a$CJ_HmH sH tH 4@4 Header !NON J~ TMCE_Footer! $ CJOJQJ\O"\ J~TMCE_Footer_Even"$ $^a$;^JRO1R zTMCE_Body_text CharCJ_HmH sH tH 4U@A4 V- Hyperlink >*phRYRR v Document Map%-D M OJQJ^J\Oa\ `TMCE_TITLE Char&5;CJOJQJ_HaJmH sH tH POrP+D2004References'6CJmHnHufOf + D2004Heading1( & F"< 5B*CJ_HmH phsH tH BOB + D2004Heading2 ) & F"CJjOj + D2004Heading3* & F"x@& &6CJKHOJQJ\^JaJmH sH >O> )text +$a$CJmH sH tHO )reference item,$ & F 77x>T0[]Tf^7`a$ CJmH sH ^O^ ; literatura$-$ X<^`Xa$ CJmH sH lOl Econference title&.$ & F& h^`a$ ;mH sH   "$&(*,.02468:<>@BDFHJLNPRTVXZ\^`bdfhjlnprtvxz|~   "$&(*,.02468:<>@BDFHJLNPRTVXZ\^`bdfhjlnprtvxz|~͠        !!""##$$%%&&''(())**++,,--..//00112233445566778899::;;<<==>>??@@AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ[[\\]]^^__``aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~  "$&(*,.02468:<>@BDFHJLNPRTVXZ\^`bdfhjlnprtvxz|~   "$&(*,.02468:<>@BDFHJLNPRTVXZ\^`bdfhjlnprtvxz|~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~͠> ++++++++ + + + +o VE#(}08>zGGKO4X+btgFlnps}:)͠?cBR    y ap34Ajmvo >9ek_ 9 f h ((5*+--E//0O11222N334o56,6'<< =|==->>>>#?g?@@`AAAzG|GGJJMWNwNN OWOOPjPSQ RMS~STT>WX[\_ceelmKnMnqrsvyDy{}~?_w=M ؍s:Տ}N~~:)PH֛BĞϞўӞΠQ&Q&sQ&jQ&jQ&jQ&jQ&jQ&sQ&jQ&jQ&jQ&jQ&sQ&jQ&jQ&jQ&jQ&j~~s~s ~s~~s~ ~s~s~ ~s~s ~s~s~N~~s~s~s~s~s~s~s~s~s1#`Z01#v:~s~s~s~s~s~s~~s~~~.~1 ~.~s~~h ~h ~1 ~~s~1 ~.~.~.~.~s~{'~v:~s~.~1 ~1 ~s~~s~s&ʀ@&v: ~s~s~s~s~~~~.~1 ~s~s~h ~1 ~O~~s~s ~s~s ~s~s~s~s ~sL%>7L%v:~~sL%DL%v:~s~~s ~s~ ~s ~s~h ~h ~1 ~3~3~,~s~~s~~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:~v:Q&v:YQ&v:Q&v:Q&_Q&v:Q&v:Q&v:ap34Ajmvo >9ek_ 9 f h #$$%'((5*+--E//0O11222N334o56,6'<< =|==->>>>#?g?@@`AAAzG|GGGJJMWNwNN OWOOPjPSQ RMS~STT>WX[\_cee=fh=kkllmKnMnnqrsvyDy{}~?_w=M ؍s:Տ}N~~:)PH֛ABÞĞϞОўҞӞԞ՞֞מ؞ٞڞ۞ܞݞޞߞ  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ŸßğşƟǟȟɟʟ˟̟͟ΟϟПџҟӟԟ՟֟ן؟ٟڟ۟ܟݟޟߟ  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ àĠŠƠǠȠɠʠˠΠ 0 0 0a 0a 0a 0a 0a 0 0 0  0  0  0  0 4 04 04 04 04 04`040 0 0 000m 000 00o 0o 0o 0o 0o  009090909090909090909 0909 0990#0#0#0#(0#0(0(0(0(0( 00E/ 0E/ 0E/ 0E/ 0E/ 0E/0E/ 0E/ 0E/ 0E/ 0E/ 0E/E/06 0 6 0 6 0 6 0 6 0 60606 0606 06 06 0606 0E/E/(0`A0A0A 0A(0`A0G(0`A0J0J 0J 0J 0J 0J 0J(0`A0O 0O 0O 0O 0E/E/0MS0MS0MS0MS0MS0MS0MS0MS0MS0MS 0MS0MS0MS0MS 0MS 0MS 0MS0MS0MS 0MS0MS0MS 00r0r 00y0y 0y 0y 0y 0y 0 y 000000E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E000000000 00"0 0  "00a !0 0  !0 !0 0 0000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000y01 T"/13333367 *2]69+@GiMSYyiHmpKx|X_Ǘ2^BUXZ[]^_`bcefgijklnoprstvw|mh*<KM]KxM֦P )Fc.KhVY\adhmqux}~W͠T[^a<")+6!!!l,"$hq d @0(  B S  ?͠ _Ref43622410 _Ref43622472 _Ref43622484 _Ref43622991 _Ref506275365 _Ref409263479 _Ref27407829 _Ref26767275 _Ref409238242 _Ref26762786 _Ref409148253 _Hlt409268464 _Ref409141828 _Ref513605219 _Ref26767293 _Hlt513605587 _Ref505491008a4::}~|::P֛֛Π @`n@ԏ{M}||֛Π9dPp"Tr9u{or9Np{Tlr9}p{~p9p"Tp9p{Ԏp9p{Tp9p9ԏp{p9Tp{p" $^p" d^p"^p"$_p"d_p" _p"q",q"lqTTśś̜ߜߜ`ss~Π      ZZΛΛʜݜq|Π  B*urn:schemas-microsoft-com:office:smarttagscountry-region8*urn:schemas-microsoft-com:office:smarttagsCity9*urn:schemas-microsoft-com:office:smarttagsplace8 *urn:schemas-microsoft-com:office:smarttagsdate> *urn:schemas-microsoft-com:office:smarttags PersonName=*urn:schemas-microsoft-com:office:smarttags PlaceType=*urn:schemas-microsoft-com:office:smarttags PlaceName E1218200420064DayMonthYear  pAi  $303%S&SWW b bKnLn]nennn\d}ɐՐNW:<pr@AAĞΞ՞֞ˠΠ~XXllvv:ԏ:)P֞Π:::::::::apAmvo 9e#$GGIJOP__wž֞Π֞Π&pFt}F()* &7=f)!RC.I8DnJ8\mη\|34)I!Lu_ -!&J@^o(:*Gi*g6 .RCSj=.dUA!D`CD˞ J\> JloM<z IN{Q fpYhڪ rZvz ]$9M`8 faB H?b>b]bzficd{.od.0ChV4{n*@EHH*KHS*TX[\]^Jo(hHFigure  @^@`o(hH.. <^`*@EHH*KHEHOJQJS*TX[\]^Jo(hHFigure  @^@`o(hH.. <^`468>VcO>yYl)Yy>'yd~/:EhwI (c#%9&!&y%&u('z(()~*s,21`1M2a6;8 f9%;<+b<"=A= >~{>'?{?@W0A2A`AcAwCz3D;AEMI/M)@MgPQ Q_TS3UWmCW(WWlW X`}Z\[\*l]q]4^F`yo`]Ba|a"bxb&cle&fDf 7g/h1 heh Zi>jij,kgLk7n1popEGpPp*q r)"sAs@u+!wcwxgxAy@z|D|U}}~4g Gz+V-[v' rWg ~p/d()%>@]4g~!?:JlXk>Lfi|Z' 07X'`&P&2]"wZ#&L,Hszxw jHi;}}& e-KvhO7_~_5tpJ`S~dZ? (8k$_I%&Alr0e s,C6}*c>{4;?%Y"'TF8{2[ R}:U`eR)kp!0ip=\DO=[Vf&g5* r(kF }B6wkM/DG7sO3sEsIpPfL ATj{bS0yg~`mΠyT4  @9L͠PP@PPH@PP@UnknownGz Times New Roman5Symbol3& z ArialMFjTimes New RomancTimesNewRomanTimes New Roman5& zaTahoma?5 z Courier New;Wingdings#1hŚ&]K&#f(`B P`B P!>4dRR\] 3qHX,?[ 20ACCEPTABLE FORM FOR YOUR PAPER FOR THE TMCE 2002Industrial Design EngineeringNP&                           ! " # $ % Oh+'0(< HT t   4ACCEPTABLE FORM FOR YOUR PAPER FOR THE TMCE 2002 Industrial Design Engineering Normal.dotNP40Microsoft Office Word@F8O}@$1@X@D `B՜.+,04 hp   Delft University of TechnologyPR 1ACCEPTABLE FORM FOR YOUR PAPER FOR THE TMCE 2002 Title  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry FТ@WData 1Table WordDocumentSummaryInformation(DocumentSummaryInformation8CompObjq  FMicrosoft Office Word Document MSWordDocWord.Document.89q