this, a 'what-if design support system can help in performing routine tasks and aiding designers and ... However, if a sheer process-oriented approach to product.
‘What-if’ design: a synthesis method in the design process D. Lutters, T.H.J. Vaneker, F.J.A.M.van Houten (1) Laboratory of Design, Production and Management, Faculty of Engineering Technology University of Twente, Enschede, The Netherlands
Abstract In integrating functions, information and control in the design and engineering cycle, the information content acts as a facilitator, whereas the processes involved actually effectuate the results of the development cycle. As combining processes in an effective and efficient manner becomes increasingly feasible, a more dynamic coherence between the processes involved is implied, calling for different control principles, whilst maintaining -and possibly increasing- flexibility. This increases the competency in understanding and utilising consequences of design decisions. Based on this, a ‘what-if design support system can help in performing routine tasks and aiding designers and engineers in understanding more complex challenges.
Keywords Information management, design support system, ‘what-it‘ design
1 INTRODUCTION In many companies, teams of product developers are concurrently involved in the design and engineering of one, but many a time, more than one product, or product family. During these design and engineering phases of product development, the members of the design teams take numerous decisions. These decisions are concerned with extremely diverging topics, implying that either the design team or co-operating specialists are not only able to survey all aspects involved in the project, but also that they are able to weigh the consequences of all those decisions at any given moment. In everyday practice, this may seem a clear infeasibility; nevertheless, design teams are able to cope with it because of their knowledge, experience and intuition -something that can not be grasped by any computer. This, however, does not imply that computers can not support design teams in their efforts to arrive at better solutions for the problems they encounter. However, if a sheer process-oriented approach to product development is applied, the dependencies between the tasks and functions related to all the members of the development team understandably become entangled to such an extent that extremely rigid process management methods have to be employed. This not only distracts the members of the design team from their actual activities, but it also causes an enormous overhead in communication and assimilation. In addition -the most important drawback by far- it hampers the activities that designers and engineers are best at: employing their creativity to solve unaccustomed problems. This is all the more true in recognising that the demands during product development unremittingly increase, and product developers therefore face more challenging tasks. In this respect, the limited intelligibility of the design process is of significant importance. Adequate execution of the development processes, purely based on design experience, therefore becomes an almost impossible job. As can be concluded from the above, the real contribution of members of the development team and their tools (e.g. [I]) is related to the adequate, conjoint and effective
enforcement of the design and engineering processes; including both the innovative work and the routine tasks. Especially these intuitive tasks show a considerable similarity in the way in which they are addressed and solved. Consequently, the structure of such tasks can be pre-formatted with a fair amount of certainty. This is attempted in so-called what-if design, where decisions are -in a more or less autonomous manner- supported by questions of the type ‘What happens if (see fig 1.). ...I
It goes without saying that it is a sheer impossibility to address such what-if questions from a procedural point of view, as the number of processes that will be involved will -even in the simplest cases- already floor every attempt to maintain overview over the entire development process. This implies that in addressing what-if questions, focus must shift from the processes involved to the actual product under consideration; or, more accurately: the information content that describes the development and the status of the product. Moreover, the denotation of this information content has to be available and practicable as well.
Figure 1: Overly simplified example of a what-if question.
1.I What-if Design It is very difticult to give a precise definition of what-if design. The closest comparison is what goes on in the mind of a designer (or engineer). During a development cycle, a designer well-nigh continuously deliberates over the various possible solutions that lie ahead. Every time he has to assess the consequences of the different options; both for the product under development as well as for the processes that are required to achieve the chosen solution path. Many of these decisions are concerned with a considerable amount of tasks, with the ever present danger of overlooking important details. What-if design aims at supporting the designer in tasks that are considered more or less routine tasks in a certain field of expertise, by taking care of the larger part of the basic explorations, surveying the information content involved and scrutinising the details. What-if design also tries to transgress the boundaries of the different disciplines in order to veritably achieve synthesis. Based on this goal, it additionally focuses on a more elaborate ambition: the support of teams by actually raising solutions; either automatically or interactively. Supported by a what-if system, team members can focus on what they do best: find creative solutions for the more challenging problems. In order to be able to hold an overview over the entire research area, two approaches are contrived at the same time: one analysing required principles from an applied point of view, and one examining a generic methodology that enables the overall functionality. Section 2 addresses the prerequisites for the application of what-if design; sections 3 and 4 deal with the applied and generic approach respectively. Section 5 deals with the manageability of what-if design in more detail.
2
PREREQUISITES FOR WHAT-IF DESIGN
If what-if design techniques would be developed from a process oriented point of view, it would be extremely hard -if not impossible- to find any sequence of processes that leads to the desired goal. The only way to achieve this is to describe - o n beforehand- all possible combinations of processes and their results; implying that all processes, and all effects they have on every possible departure point have to be pre-established. Setting aside the fact that this is a sheer impossibility, it would lead to an enormous loss of flexibility and transparency, moreover, it would create an overwhelming overhead of rules, process descriptions and prescriptions for the employment of these processes. This situation is comparable to finding yourself in a maze, where all intersections look the same; but what is worse, experience will not help you, because this particular maze changes each time you enter it.
3 AN APPLIED APPROACH FOR WHAT-IF DESIGN In order to understand the working methods related to what-if design, it is important to not only sketch the big picture, but especially to interpret the consequences of what-if design on all levels of abstraction, starting with studies in a limited domain. For such a domain, existing correlations can be established and rules can be deduced, that later on can contribute to the composition and verification of the generic methodology. In one domain -here e.g. the mechanical domain- a design aspect hierarchy can be developed. This hierarchy is based on an analysis of the design process, resulting in a hierarchy of the different aspects of products and the relations between these aspects. Based on the hierarchy, the aspects are divided into two groups, being driving and driven aspects (see figure 2). The driving aspects (influencing all other aspects) contain the information that, together with aspect specific context information, is used to define the driven aspects (influenced by only the driving aspects). Awhat-if question results in a change in one of the driving aspects. The applied change will then propagate trough the design, affecting one or more driving andlor driven aspects. After the attenuation of this propagation, the product architecture has changed into a new, valid state, based on which the what-if question can be answered. Many types of relations can be identified between the driving and driven aspects. The relations between the set of driving aspects and the set of driven aspects are one-directional and downstream. The information needed to define the driven aspects consists of information that can be deduced from the driving aspects and additional, not product specific, information. The relations between the four driving aspects are of a more complex nature. For example, changing the geometry (diameter of a hole) will induce the choice for a different tool (drill). And if the combination of the new diameter with the depth of the hole rules out drilling, other processes will have to be selected to produce the part. The mutual dependencies between these driving aspects can be simplified by assuming that the relations between function and process plan and between geometry and material are well-nigh invariably effectuated via the intermediary aspects. If these relations (the dotted lines in figure 2) are disregarded, also the risk of circular reasoning is prevented.
The situation becomes different if attempts are founded on an information based approach. In this case, the current status of the development project is already (and invariably) definite and known [2][3]. Moreover, using an ontology as a denotator of the information content [2], also the meaning of the information content is known and employable to govern the course of processes. In focussing on the information content, it is much easier to hold an overview over the current status of the product design and, more important, to govern and hold sway over changes and evolutions in the design process [2]. This imposes two important prerequisites on the environments in which what-if design is to be used: the information content must be disposable in a structured manner, and a workflow management approach must be available that can be grounded on the information content.
Figure 2: Product aspect hierarchy for what-if design.
3.1 Operating procedure Based on an architecture for applied what-if design [4], the actual mechanisms for what-if questions can be described. First, the set of required information is obtained from information management functionality. When a designer considers a modification to an existing product, he has a certain goal (improvement) in mind. In order to reach this set goal, one of the four driving aspects will change. A new PRIS (PRoduct Information Structure) will emerge that compares the new product configuration with the original one [4]. Not all changes made by the designer will instantly result in an ideal new PRIS, as restrains will occur on e.g. materials, production machines and fulfilment of functions. In general, a change in one of the driving aspects will initiate changes in other driving and driven aspects. If a check of the proposed change leads to conflicts within the other driving aspects, new non-conflicting variants of the design have to be generated. Consequently, three modules of the architecture have to conjointly find viable solutions: inconsistency detection, design variant generation and design variant ranking. Based on the information content, inconsistency detection will indicate problems or possible flaws. If an inconsistency has been detected, design variants have to be generated. When e.g. the driving aspect ‘material’ is changed from instance A to B, a subset of production processes can be composed. Each element of the production processes subset may have its own constraints on the shapes that can be manufactured. The geometry of the product has to change and with that, the extent in which the functions are fulfilled will change. A tree structure of possible design solutions, with a consistent PRIS, will emerge. Because also a different ‘route’ is possible (material - function geometry - process plan, see figure 2) a second tree structure will emerge, representing new design variants. When many processes and materials are available to the designer, the tree structures will grow to a substantial size. As it is impossible to examine all the individual design variants, a ranking algorithm is needed, in order to be able to focus the attention of the designer at the most promising design variants. Based on this approach, design variants can be generated and assessed, whilst guaranteeing the validity of the solution.
4 A GENERIC APPROACH FOR WHAT-IF DESIGN As the applied approach as described in the previous section is limited to one domain, and is also confined to a situation in which the processes that can be addressed are known, it will be extremely difficult to assemble a generic design support system. Therefore this research not only uses a bottom-up approach, but simultaneously tries to assure the genericness of the methodology by a top-down working method. From a top-down approach, what-if design can be seen as a request for the controlled evolvement of information in a certain direction. More precisely: what-if design hypothesises a certain status of the information content that deviates from the actual information content. This causes a A-state, which results in an ambiguity in the information content. The ontology will not connive at such a situation; the influence of this A-state on the other entities in the information kernel will be mapped. It is important to note that in this approach neither the actual information content nor the functionality of the processes involved is prescribed. If the ‘derangement‘ in the information content is known, the two sets of information that exist (being the initial status S and the changed status S+A) can be formalised as two
distinct representations of the information content -be it with different intentions. The current status of the information content S can be regarded as a valid representation of the current situation in the product development cycle. As the status S+A is purposely imposed on the system by a member of the design team to test a possible improvement, S+A can be equated to a desired situation. Although this desire can be temporary (depending on the fact if the proposed change is really an improvement), it can be considered as a goal to focus on. Here an important advantage of the integrated working methods of information management techniques comes forward: it is not important how and why a certain activity is carried out, all that matters is the information content it deals with [5]. In other words, in order to assess the possible improvement suggested by the team member, S and S+A can be used to initiate Engineering Process Support (see section 5.1). Based on the task networks and task chains generated within the workflow management procedures, a number of processes can be initiated to achieve a valid situation for S+A. This valid solution can probably only be reached by changing the related entities as well. As a simple example: if a change of the chosen material for a certain product design is proposed (S+A), this will probably influence the geometry of the product as well (see also section 3). Consequently, the related entities will have to accept a A-status as well. This again triggers workflow management, resulting in the initiation of design and engineering processes. Ostensibly, this leads to a stupefying chain reaction instantaneously saturating any manufacturing system. 5
MANAGEABILITYOF WHAT-IF DESIGN
Information management not only addresses the information content, but also caters to the denotation of the information and its context; therefore the chain reaction mentioned is confined. Additionally, the use of an ontology constrains the chain reaction: firstly, it helps to value the relation between entities, so dependencies are evaluated in a meaningful manner. Secondly, the ontology -togetherwith workflow management- holds knowledge of the mutual dependencies between entities, thus stringently limiting the number of variants that have to be assessed. There is no theoretical proof that these measures are efficacious in achieving a practicable environment for automated what-if design. However, it goes without saying that indications that are usually employed to assess the quality of a design remain unchanged if what-if design is used. Mentioned are for example design axioms like Suh’s design axioms [6] or the communication axiom: minimise the need for communication [2]. The more a product design meets these axioms, the easier it will be to employ what-if design. In other words, if a product design is robust, the ‘shock-wave’ caused by what-if questions will decay much faster than for other designs. Besides, a what-if based system can never leave the boundaries of what is permitted to ‘return’ to it in a subsequent step. This implies that after each change, the evolved value S+A will be assessed, leading to the early detection of impossibilities and even an indication for ‘weak spots’. As a consequence, the evolvement of the information content can almost be guided along preferred routes, thus strongly limiting the number of variant situations that have to be compared. Moreover, the propagation of variations in the information content can be limited as well.
5.1 Workflow management
The engineering process support (EPS) concept governing the workflow management of e.g. what-if questions is aimed at coordinating and supporting activities based on evolving information content [2][5][7].The concept has three main components, addressing process management, decision support and knowledge management. There is a strong correlation, as e.g. the construction of new process models is buttressed by historic information provided linking process management and knowledge management. The process modelling methodology, as it is defined within the EPS concept, presents a novel approach to the management of engineering processes. The process modelling functionality is part of the ‘process manager’ component (see figure 3).The methodology that has been developed for the generation of process models is based on linking task definitions to information content. Tasks Within the context of information management based systems, a task is defined as a systematic set of defined work to be done or undertaken in order to arrive at a specified result and to achieve a directed, predictable and desired evolution in the information content. A task can be defined independent of the level of aggregation, from which it is reasonable to argue that a task can consist of tasks that together can realize the work of the initial task. As a result, task composition and decomposition allow for the realization of process management functionality across different levels of aggregation. The execution of a task can be seen as a transition from a state established by a certain information content to another state, established by an evolved information content. Consequently, a task can be seen as a process that needs and yields information. In the ontology, a ‘task-blueprint‘ is available to aid in the definition of new tasks. This subset of the ontology is referred to as ‘task ontology’. A task is defined by the information it needs (input) and the information it yields (output). As a result, a task definition specifies the types of information entities together with their relations, for input and output. Task nefworks The individual task definitions can be linked to form task networks by mapping their respective inputs and outputs. In theory, when this is done for all tasks that have been defined within a manufacturing system, the resulting network will represent all possible process paths available to that system. As a practical application this linking of tasks enables the generation of specific goal oriented task networks. Such a network is represented as a graph consisting of tasks and information entities and it defines all possible paths from the process goal to the current state in information content.
The process goal is used as the starting point for the generation of a task network. The network is constructed by reasoning back towards the current information content of the product information structure, thus realizing an information pull methodology for process modelling. When tasks are executed, information is generated and, as a result, the state of the information structure changes. Consequently, the current task chain will be evaluated to determine if it is still the optimal process solution. This illustrates how the mechanism reacts to the evolution of the information content. The process models are generated and evaluated at run-time. 6
CONCLUDING REMARKS
In aiming at a design support system that facilitates implicit tasks and assists in more challenging tasks, real and adequate synthesis in development processes can be achieved. This integration is enabled in appreciating the role of information management and workflow management as foundations for what-if design. Basing the approach on the information content, rather than on process descriptions, allows for the aggregate application of e.g. ontologies and information based workflow management. In order to ensure the generic character of the what-if system, a domain and task independent working method are adopted; however, ensuring practicability of the approach, a more applied research is conducted simultaneously. Together, these will -in future researchlead to the implementation of a modular design support system for what-if design. The dimerous approach ensures that the system is not limited to certain domains, levels of aggregation or areas of interest. As the used methods are generic, and the all tasks can be deployed in a flexible and combinatorial manner, the system becomes a learning system, adapting to the growing and changing situation it is employed in, thus contributing to the requested synthesis in design processes. 7
REFERENCES Noel, F., Brissaud, D., Tichkiewitch, S., 2003, Integrative design environment to improve collaboration between various experts, Annals of the CIRP, 52/111 09-112. Lutters, D., 2001,Manufacturing integration based on information management, PhD. thesis, University of 583-1. Twente, ISBN 90-365-1 Westkamper, E., 2002,Platform for the integration of assembly, disassembly and life cycle management, Annals of the CIRP, 51/1:33-36 Vaneker, T.H.J., Lutters, D., Hittorf, G., Van Houten, F.J.A.M., 2004, ‘What-if-design’; An illustration of applicability in the field of mechanical design, Proc. of the int. conf. on Competitive Manufacturing, Stellenbosch, 4-6feb. Lutters, D., Vaneker, T.H.J., Van Houten, F.J.A.M.,
2004,‘What-if design’; A generic approach based on information management, Proc. of the int. conf. on Competitive Manufacturing, Stellenbosch, 4-6feb. Suh, N.P., 1990, The Principles of Design, Oxford Series on Advanced Manufacturing, Oxford University Press. Mentink, R.J., Van Houten, F.J.A.M., Kals, H.J.J., management for engineering environments based on dynamic process modelling, Annals of the CIRP, 52/1:351-354.
2003, Process
Figure 3: Functional components of Engineering Process Support.
