Experiences from implementing CANDLE using the VARKON CAD system

Size: px

Start display at page:

Download "Experiences from implementing CANDLE using the VARKON CAD system"

Dulcie Thomas
6 years ago
Views:

1 Experiences from implementing CANDLE using the VARKON CAD system Abstract Kjell Andersson Engineering Design Department of Machine Design KTH Telephone: Telefax: kan@damek.kth.se This paper deals with the implementation of the CANDLE design language by using the tools available in a commercially available CAD system, i.e. the VARKON system. First, a description is given of the theoretical concepts that CANDLE is based on as well as the main significant features of the VARKON making it suitable for this implementation. Further, the models defining the main branches in the CANDLE vocabulary will be described in terms of models to be implemented in the CAD system. One of the ideas behind CANDLE is to give a skeleton structure of the vocabulary with concepts on a rather general level that should be completed with more specific concepts for each application that is added. Keywords: Design language, systematic design, conceptual design 1. Introduction In recent years, there have been an increased interest to support early phases of design work. One of the reasons for this is that decisions made during this design stage has a great influence on and controls or limits the design space during the later design phases. Design work during these phases typically deals with a lot of non-geometric data. To be able to support the designer during these phases we must offer the designer a tool that can support handling with and recording of this information as well as being a decision making support. If we can avoid a number of tedious and costly iterations later during the development work there are much time and money to gain. For this reason there have been some systems proposed by e.g. Baumann [6], Bentz [7] and Andersson [1],[2],[3],[4]. This paper deals with an implementation of the CANDLE modelling language as proposed by Andersson.

2 2. The CANDLE modelling language In order to support design activities we need to have a good understanding about the environment in which the method will operate. There have been several research studies, e.g. [5], [9], aimed to describe a model of the design process. A design process model will, with its conceptualisation of the design process, give a template for how we should structure all the non-geometric data that is created during the early design phases. For the CANDLE modelling language, we have chosen the model of the design process described in the work by Pahl and Beitz [9]. The reason for this choice is that this methodology is pragmatic and easy to follow, which also is reflected by its contributions to the development of the VDI 2222 guidelines for the German industry. This methodology divides the design process into a number of phases, and describes the activities and results for each phase. The different design phases are: 1. Clarification of the task 2. Conceptual design 3. Embodiment design 4. Detail design CANDLE is directed on supporting the first two phases, namely Clarification of the task and Conceptual design. This conceptualisation of early design work made by Pahl and Beitz have been used as a base for the definition of a vocabulary for early design work. Upon this vocabulary a design modelling language, CANDLE [1], has been defined. Language Design Vocabulary words parts Syntax grammar valid configurations Utterances sentences designs Semantics meaning interpretations of designs as performances Figure 1 Similarities between language and design, after Coyne [8]. For the definition of CANDLE we utilise similarities between terms of languages and of design descriptions [8]. Contrary to Coyne, we will here use engineering concepts instead of parts, since conceptual design is more concerned with reasoning in terms of engineering concepts 1 than (physical) parts. With this modification we can use these analogies for the definition of a design grammar. The design grammar DG, is 1 Note the difference between engineering entities and engineering concepts. An engineering "concept" is defined as an element of thinking. This mental construct represents a material or immaterial object in the engineering domain. An engineering entity is an entity representing an engineering concept.

3 given by a 4-tuple <V,X,S,Ks>, where V is a vocabulary of engineering entities, X is a set of terminal symbols, S is a design start symbol and K s is knowledge about valid configurations of engineering entities. Given a design grammar DG and interpretative knowledge K i, then the design language CANDLE(DG) is given by the set of design description that can generated from DG, where each description has an interpretation I. The vocabulary V, is represented as engineering concepts using the Conceptual Graphs by Sowa [10] and structured in a taxonomy. The general structure of the taxonomy is influenced by the design methodology which it is based on. product_model entities designs partial_designs design_elements requirement_spec design_concept function physical_principles solution_principles attributes Figure 2 Major divisions of the vocabulary. Each engineering entity is defined by its position in the taxonomy in figure 2 and by its type description. As an example, consider the type description of the entity design_concept which is a general description of the result from the conceptual design phase. This entity is described in terms of other entities and relation between these entities. Additional information such as rules and constraints can be assigned to both entities and relations (syntactical K s and semantical K i knowledge) and is used by the design grammar and the design language (CANDLE). Readers interested in further details about the CANDLE design language are referred to [1], [2], [3], [4]. 3. The VARKON CAD system The VARKON CAD system [11] from Microform AB in Sweden has received a great deal of attention for its ability to efficiently create and use parameterised generic descriptions of products and for its flexibility for adapting it for different companies. This is one of the ideas behind the system, to offer a great deal of flexibility to its users so that it can be tailored for each customer. The system can roughly be divided into three different parts; 1) the drawing module which actually is just a drawing program, 2) the base module containing tools for interactive and parameterised design with variation of both 2D and 3D shapes 3) a module containing a macro language MBS which can be used alone or in combination with the drawing module or the base module.

4 Next I will give a short description of the main features of the CAD system making it suitable for this test implementation of CANDLE. In short, from my point of view, the main important features of VARKON are: It has a small program kernel It is easy to modify the menus It is suitable for parametric design It has a flexible macro language First, dealing with a small program kernel makes the iteration process of program coding and testing much faster and more efficient. Second the possibility to easily modify system menus and to replace them with whatever menus you want, have been very valuable to get a fast start with this implementation. Since this system is very well suited for parameterised design, the available macro language or model description language (MBS) is an efficient tool to use for building the vocabulary of CANDLE. However, it does not directly support the use of objects as an object oriented programming tool does. Nevertheless, using the MBS language it is possible to define the different results in terms of engineering concept as well as to define the user interaction for the support tool which will produce these results. If we consider the possibilities to represent a product model, we find at the top level when we start the system, that each new model has to be defined as a new job. All models that are created during the following design activities belongs to that job. These models are also stored as instances of modules in the Program Memory, PM. In this implementation I have used this job level to represent the product model. 4. Implementation of CANDLE using VARKON For this implementation I have used the MBS language as a means for describing the different generic modules containing descriptions of the results being produced during early design work. It has also been used for all other programming tasks such as all interaction facilities, i.e. windows, help texts, menus etc. Within the CANDLE modelling language, the taxonomies play a very central and important role. They serve both as a way to express different results during the design process as well as a way to get support and ideas about existing physical processes and solution principles that can be used for problem solving during design. To implement these taxonomies, at first the skeleton structure should be defined, which then should be completed with additional entities for specific applications. Since the MBS language by itself is not object oriented I have defined this tree structure by using data files containing class specific attributes specifying these relationships. A principle view of the implemented system is shown in figure 3 and the representation of the product model is shown in figure 4.

5 The Varkon CAD system The CANDLE system function DB physical principles DB solution DB Figure 3 A principle view of the system. product model 1:1 1:n 1:1 project definition requirement specification design concept Figure 4 ER model of the product model. 4.1 Requirement specification The result of the clarification phase is described by a requirement specification. This should be compiled of a comprehensive collection of information concerning the actual product where both criteria coming from the customer (or the market) and criteria from the company should be weighted together to a technical requirement. A well known method for taking care of customer requirements and translate these into technical requirements is the Quality Function Deployment, QFD method.

6 QFD Technical requirements tech_req Customer requirements and wishes weight Connection matrix Name Quantity Value cust_req Goals Name Quantity Value Figure 5 a) The QFD chart. b) ER model of tech_req and cust_req. In this implementation I have chosen to offer the designer QFD as a tool for making these translations. Of course these translations should be performed as a group activity with members from at least the market and design divisions in the company. The connection matrix along with the weigh vector is stored as a data file placed at a job specific directory and an instance of a QFD module containing the path to this file is created. Contrary to the earlier proposed representations of CANDLE I have not yet implemented any predefined format for the requirement specification. I have chosen to represent them only as two different types, technical requirements (tech_req) and customer requirements (cust_req), which are illustrated in figure 5 b). This means that the requirement specification will be composed of a number of customer (cust_req) and technical requirements (tech_req). 4.2 Design concept The activities starting after the requirement specification has been compiled are very varying depending on the type of product that you are dealing with. This demands a great deal of flexibility of the computer support so that the designer can choose the appropriate tool for the considerations that he finds necessary. The activities performed during this phase will result in a design concept containing some intermediate results. The content can however be different for different products, e.g. you may not find it necessary to create a function model or a physical principle model before you search for and select a feasible solution principle. 0:n design concept 0:n 1:n function physical principle solution principle Figure 6 ER model of the design concept.

7 4.2.1 Functions Dealing with an abstract formulation of the wanted product function can be of a great help for the designer and help him to focus on the real problem that should be solved. This process of handling with function descriptions and composing them into function structures has been thoroughly examined by e.g. some German authors e.g. Pahl and Beitz [9], Baumann[5]. The approach taken in this implementation has been to offer the designer a tool to perform a kind of computer assisted abstraction process in order to find out the main function, described in solution neutral terms. This approach is based on the assumption that the product can be treated as a system and described in terms of inputs and outputs to the system Solution principles Since physical principles have not yet been implemented I continue with a discussion about solution principles. Two difficult problems to solve concerning solution principles are how we should structure and represent them. To start with latter, since I have chosen to describe functions in terms of a function name and of inputs and outputs to the system, the solution principles must be possible to identify on the basis of these terms. This means that a solution principle must at the very least have attributes defining possible inputs, outputs and functions that can be satisfied by this solution along with a geometric description and a description of connections between parameters controlling the geometry and the inputs and outputs to the system. What is the best way of structuring them then? The approach that I have chosen for implementing solution principles is to use a data file for representation of the structure and the attributes that are needed for searching through the data file for feasible solutions. When an appropriate solution has been identified and selected from the data file an instance of the corresponding module description is created for that solution. Among the attributes in the data file one attribute specifying the path to a bitmap symbol for the solution is included. One suggested usage of this symbol is to use it in a selection chart for selecting suitable combinations of solution principles. Solution principles Symbols Subfunctions Figure 7 Suggested use of symbols for selection of suitable combinations of solutions principles.

8 5. Summary, conclusions In order to be able to offer computer support for early design work we must be able to represent the information produced in these phase which to a large extent is nongeometric. In this paper I have based this discussion of computer support and resulting models, on the approach to the CANDLE design language by Andersson. Upon this basis a test implementation of CANDLE using tools in a commercially CAD system is currently being developed. The conclusions that I can make so far from this implementation are: The problem is not primarily the representation of the results in terms of different models. The difficulties lies in how to work with these models and how to enter data into them and to retrieve data from them. A key problem here seems to be how to structure the taxonomies of e.g solutions principles so that we can be able to identify and select solution principles which are solving our problem and here I want to be able to select among a number of predefined solutions but also from the solutions that have been created during the development of another product. References [1] Andersson K., 1993, A Design Language Based on Engineering Terminology, Ph. D. thesis, Department of Machine Design, KTH, Stockholm. [2] Andersson K., 1993, A Vocabulary for Conceptual Design - Part of a Design Grammar, IFIP WG5.2 Workshop on Formal Design Methods for CAD, Tallinn, Estonia. [3] Andersson K., 1993, CANDLE - A new Tool for Conceptual Design, ICED 93, Hague, The Netherlands. [4] Andersson K., Makkonen P., Persson J-G., 1995, A proposal to a product modelling language to support conceptual design, CIRP Annals Vol. 44/1/1995, pp [5] Andreasen M. M., 1980, Machine design methods based on a systematic approach - contribution to a design theory, Ph. D. thesis, Dept of Machine Design, Lund Institute of Technology [6] Baumann M., 1995, Anwendungsspezifische Erweiterung von Konstruktionssystemen für geometrisch-gestalterische Tätigkeiten unter Berücksichtigung einer systemneutralen Datenhaltung, WZL, TH Aachen. [7] Benz T., Funktionsmodelle in CAD-systemen, VDI-Verlag GmbH, ISBN , [8] Coyne R. D. et al., 1990, Knowledge-Based Design Systems, Addison-Wesley, ISBN [9] Pahl G., Beitz W., 1988, Engineering Design - A systematic Approach, Springer-Verlag, London. [10] Sowa J. F., 1984, Conceptual Structures: Information Processing in Mind and Machine, Addison-Wesley. [11] Varkon-3D reference manual 1995.

Authoring and Maintaining of Educational Applications on the Web

Authoring and Maintaining of Educational Applications on the Web Denis Helic Institute for Information Processing and Computer Supported New Media ( IICM ), Graz University of Technology Graz, Austria