Context -based 3D CAD configuration using object ... · 1 Introduction This is a master thesis in the ﬁeld design automation and 3D CAD conﬁguration at the Department of ManagementandEngineeringatLinköpingUniversity

Linköping University | Department of Management and Engineering

Division of Machine Design | Master thesis, 30 ECTS

Spring semester 2016 | ISRN: LIU-IEI-TEK-A--16/02594—SE

Context-based 3D CAD configuration using object-oriented programming – A case study within the construction industry

Gustav Carlberg

Master of Science program: Mechanical Engineering

Master profile: Aerospace Engineering

Erik Söderby

Master of Science program: Design and Product Development

Master profile: Product Development and Technical Design

Supervisor: Stefan Blomqvist

Examiner: Kristian Amadori

Linköpings universitet

SE-581 83 Linköping, Sverige

013-28 10 00, www.liu.se

AbstractIn this thesis the authors extend the capabilities of a commercial CAD configurator software to includesupport for the CAD software SolidWorks through the use of COM automation, object-oriented program-ming, design automation and knowledge-based engineering. On top of the configurator development,which is performed at a CAD software company, a case study with a company within the constructionindustry is carried out with the resulting software. The case study compares the company’s currentdesign process with a 3D CAD configuration process and highlights risks and benefits of changing themethodology. Due to lack of important functionality in SolidWorks the authors do not manage to recreatethe entire functionality existing for previously use CAD programs but find possibilities to automate manyelements of the design process and conclude that abilities to create context based configurations exist.The authors also manage to create flexible proof-of-concept configurations of products from a companyin the construction industry as well as providing a small library of reusable modules. The products ofthe company pose problems which have not been previously encountered by the CAD software companyin that they lack a defined hierarchy and that the included components have high degrees of interdepen-dence. The authors conclude that the configuration software can handle such problems if the previouslyused methods are altered but more functionality is needed if a user is to apply these methods efficiently.

SammanfattningI detta examensarbete utökar författarna funktionerna i en kommersiell CAD-konfigurationsprogramvaratill att inkludera stöd för CAD-systemet Solidworks genom användning av COM automation, objekto-rienterad programmering, designautomation och kunskapsbaserad ingenjörskonst. Utöver utveckling avkonfigurationsmjukvaran, vilket görs på CAD-mjukvaruföretag, genomförs en fallstudie med ett före-tag inom byggbranschen med den resulterande mjukvaran. Fallstudien jämför företagets nuvarandedesignprocess med processen för 3D CAD-konfiguration och belyser risker och fördelar med att ändrametodik. På grund av brist på viktiga funktioner i Solidworks har inte författarna lyckats återskapa helafunktionaliteten som finns för tidigare använda CAD-program i konfiguratorn, men hittar möjligheteratt automatisera många delar av designprocessen och drar slutsatsen att förutsättningar för att skapakontext-baserade konfigurationer existerar. Författarna lyckas också skapa flexibla konceptuella konfig-urationer av produkter från företaget i case-studien samt bygga upp ett bibliotek med återanvändbaramoduler. Företagets produkter har visats innehålla designautomationstekniska problem som tidigare intehar påträffats av företaget som utvecklar konfiguratorn, i form av att de saknar en definierad hierarki ochatt de ingående komponenterna har hög grad av ömsesidigt beroende. Författarna drar slutsatsen attkonfigurationsmjukvaran kan hantera sådana problem om de tidigare använda metoderna ändras menäven att mer funktionalitet behövs för att användaren ska kunna tillämpa dessa nya metoder på etteffektivt sätt.

Gustav Carlberg i Erik Söderby

Acknowledgments

Five remarkable years have passed at the East Sweden Mekka of Technology, Linköping University, in theMaster of Science programs of Mechanical Engineering (Gustav) and Design and Product Development(Erik). We have taken complete different paths during these years but somehow we ended up in the sameacademical area - therefore this thesis is a combination of two different philosophies of engineering anddevelopment methodology. We have many, many people to thank for this journey but in order not to be toolongwindy, we have limited our acknowledgments to actors involved in this thesis:

Our thesis supervisor Stefan Blomqvist for continuous support and guidance during the process.

Our thesis examiner Kristian Amadori.

Our thesis opponents Albin Mannerfelt and Sebastian Engdahl for both their constructive criticism and theconstant battle during the process.

The co-workers at XperDi AB, CEO Mehdi Tarkian, CPO Leon Poot and CTO Manokar Munisamy. Youhave been very helpful on a daily basis, especially regarding issues related to the programming part.

The co-workers at Design Evolution AB, especially Patrik Jensen, Robert Gerth and Mats Lundström whowere extra involved in our thesis. You have all helped us to reach a better result of the project.

Artem Taturevych and Deepak Gupta, who frequently answer questions at the SolidWorks forum. Your helpand support have been almost vital for some of our configuration functions.

All people at LEAD Incubator in Mjärdevi Science Park, both the management and representatives of theother start-up companies. It has been a blast!

Jan-Erik "Janne Bärs" Runge, who has been responsible for the After Work sessions at LEAD during thethesis period.

Gustav Carlberg Erik Söderby

Gustav Carlberg ii Erik Söderby

Contents1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Company Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.6 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Theory 42.1 Computer-Aided Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Terms and CAD related concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Top-Down and Bottom-Up modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Design automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 Geometry automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Knowledge-based engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Object-oriented programming and COM automation . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 COM automation - Link between CAD and third-party programming tool . . . . . . . 102.4.2 Classes and objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3 Inheritance and superclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.4 VBA and VB.Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Method 143.1 Methodology for software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Agile development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Methodology in this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 Structure and work process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.3 Communication between the Scrum actors . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.4 Example of tasks within a user story . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Execution 194.1 Overview of the project and included sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Work process based on the user stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 User story 1 - Customer needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2 User story 2 - Software learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.3 User story 3 - Implementation understanding . . . . . . . . . . . . . . . . . . . . . . . 224.2.4 User story 4 - Requirement specification . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.5 User story 5 - Finding and re-creating needed functionality . . . . . . . . . . . . . . . 254.2.6 User story 6 - Instantiate and delete components . . . . . . . . . . . . . . . . . . . . . 264.2.7 User story 7 - Replace component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.8 User story 8 - Adjust morphological parameters . . . . . . . . . . . . . . . . . . . . . . 294.2.9 User story 9 - Create group of components . . . . . . . . . . . . . . . . . . . . . . . . 294.2.10 User story 10 - Creating a method of configuration . . . . . . . . . . . . . . . . . . . . 304.2.11 User story 11 - General modeling technique . . . . . . . . . . . . . . . . . . . . . . . . 324.2.12 User story 12 - Modeling flexible modules . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Comparative study of different configuration approaches . . . . . . . . . . . . . . . . . . . . . 364.3.1 Process of the approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Result 38

Gustav Carlberg iii Erik Söderby

5.1 Programming structure: classes and objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Description of functionality and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 CAD models and parent-child relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Discussion 436.1 Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3 Result: The configuration software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.4 Context-based 3D CAD configuration within the construction industry . . . . . . . . . . . . . 45

6.4.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.4.2 Usage for the construction company . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.5 Using design automation and object-oriented programming in the design process of a product 456.5.1 COM automation and object-oriented programming . . . . . . . . . . . . . . . . . . . 466.5.2 CAD modeling that enables configuration . . . . . . . . . . . . . . . . . . . . . . . . . 466.5.3 Re-use of objects and models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.5.4 The chosen configuration method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.5.5 Risks and benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.6 Comparative Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.7 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Conclusions 50

Gustav Carlberg iv Erik Söderby

List of Figures1 Topology and morphology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Geometry Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Geometry Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Generative Model in KBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Design Expert System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Link between CAD data and knowledge base . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Example of objects within a class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Class structure in OOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Example of superclass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310 Project and sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611 The breakdown structure of Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712 Sprints and user stories in this project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913 CAD configurator structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2314 Design expert system in this project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2415 Reference management in a replace component operation . . . . . . . . . . . . . . . . . . . . 2816 wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3117 Corner module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3418 Beam module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3519 Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3920 Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4021 Example illustrating how the corner and beammodules can be used to construct the underlying

beams of a raft foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4122 Example of how the beam, corner and reinforcement modules look when instantiated together,

and how the modules react to a change in the context. . . . . . . . . . . . . . . . . . . . . . 42

Gustav Carlberg vi Erik Söderby

Nomenclature

API Application Programming Interfaces

CAD Computer Aided Design

CAE Computer Aided Engineering

COM Component Object Model

CTO Configure To Order

DES Design Expert System

ESS Expert System Shell

ETO Engineer To Order

FDD Feature-Driven Development

GUI Graphical User Interface

HLCt High Level Cad Template

KBE Knowledge-Based Engineering

MC Mass Customization

OOP Object-Oriented Programming

STO Select Variant To Order

UI User Interface

V BA Visual Basic for Applications

1 Introduction

This is a master thesis in the field design automation and 3D CAD configuration at the Department ofManagement and Engineering at Linköping University. The thesis work is conducted by two masters students,one studying mechanical engineering and one studying design and product development.

1.1 Background

In modern product development, Computer Aided Design (CAD) tools have become an integral part ofdesign, Computer Aided Engineering (CAE) and sales pitches. Despite its popularity, many companiesstruggle with the CAD process taking unnecessarily long, with many tasks being repetitive and differentdepartments having to redo large parts of the work for the models to fit their needs. Design automation isa field which for a long time has sought to improve upon these issues with limited success.

Another emerging field in several industries is known as mass customization (MC) and many argue that theemerging of design automation is a key enabler for implementing a functioning mass customization system.Some key concepts which describe how products or services are created are engineer to order (ETO), configureto order (CTO) and select variant to order(STO). The terms basically describe how much unique work is putinto each delivered product, where ETO includes the most work and STO includes the least. This projectfocuses on the construction industry, which for a long time has been dominated by ETO solutions . Thevarying nature of the industry have even led to people claiming that anything else is impossible outside ofprivate housing. Despite such claims, one of the companies involved in the thesis is making attempts to useMC principles as a mean of taking parts of the construction industry away from ETO solutions and towardsconfigure to order products. Since design automation is a key enabler of MC, the company has been tryingto implement such methods and this thesis focuses on developing an implementing a 3D CAD configuratorto help the company achieve their goals.

Developing a fully functional commercial software is not the main focus of this thesis project, instead focusis put extending an existing tool to support the commercial CAD software SolidWorks and developingfunctional methods of design automation in said software. As part of the development process, the methodsand functionality will be implemented at the third party customer in the construction industry, where thefeasibility of implementing both the newly developed parts as well as the existing configurator will be tested.

Gustav Carlberg 1 Erik Söderby

1.2 Company Background

This project is carried out at the start-up company XperDi AB which specializes in CAD configurator tools.The company is a continuation of research conducted at Linköping University by company founder Ph.DMehdi Tarkian and has a long term goal of redefining the way companies use computer tools in productdevelopment. As of now, XperDi’s main product is a CAD configurator which helps companies to automaterepetitive design tasks.

Alongside XperDi, a third party company called Design Evolution AB, which is a consulting company withinthe construction sector is involved. This company was founded as a subsidiary of the larger company TyrénsAB, and is has its roots in research carried out by Ph.D Patrik Jensen and Ph.D Robert Gerth. Unlikemany other companies in the construction industry, Design Evolution offers solutions at a fixed rate and areaiming to deploy new tools in order to speed up their process and increase profitability.

1.3 Purpose

Configuration of construction products, such as houses and bridges, is today a very time consuming andrepetitive process. The purpose of this thesis is therefore to offer an optional way of performing the process,by using inputs from the research within design automation and object-oriented programming.

1.4 Aim

The project aims to develop 3D CAD configuration support for SolidWorks based on existing technologyand to investigate if the configurator can be used to improve the design process and work structure of acompany in the construction industry. On top of this, the project aims to deliver a master thesis that meetsthe requirements stipulated by Linköping University and contributes to the research within the area.

1.5 Project Objectives

The objectives are defined as follows:

Obj1: Can CAD configurator software support for SolidWorks, based on existing technology, be developed?

Obj2: Can products of a construction company be configured with the developed software?

Obj3: How can the construction company’s work process be improved by using the developed software?

Obj4: How well does context-based 3D CAD configuration of building products work, compared to otherapproaches?

Obj5: Can object-oriented programming contribute to a more efficient product development process?


1.6 Delimitations

Due to the scope of the project several delimitations has to be applied, in order for the writers to be able tocomplete all tasks in a satisfying manner. The most significant limitation is that the project aims to extendthe functionality of an existing product and apply the extended version rather then developing a new product.

• XperDi’s existing configuration logic will be used.

• The project will use XperDi’s existing user interface (UI) for the configurator.

• The project will not cover optimization or other design methodologies related to design automation.

• SolidWorks is the only CAD software used in this project

• Regarding CAD aspects the thesis has focused on the actual configuration, not how to create drawingsfrom it


2 Theory

This section will provide the necessary theoretical background to the conducted work. The background isdivided into three sections which correspond to the different sections of the project: Computer-Aided Design,design automation and object-oriented programming.

2.1 Computer-Aided Design

This section will describe theory and terminology related to CAD design, including different CAD modelingapproaches (Top-Down and Bottom-Up) as well as two central CAD configuration terms, morphology andtopology.

2.1.1 Terms and CAD related concepts

Throughout the thesis, many sections refer to CAD features. This term is used in the same way as used by[Jiang et al., 2013], i.e meaning the entities at the bottom of the geometry hierarchy. Examples of featurescould be extrudes, cuts, sketches or datum references such as planes, points and axes.

Two other terms which are frequently used are parents and children. When a new CAD part is created, anorigin coordinate system and three planes are automatically included. All features which are then added,depend either on one or more of the four base features, or on features which have already been created.This means all features in a CAD geometry are members of a certain hierarchy. For a certain feature, itemsplaced further up in this hierarchy are referred to as parents and items placed further down are referred toas children[Junfeng et al., 2013]. In some cases this naming is extended to ancestors and descendants foritems more than one step away from the feature.

Two important mathematical concepts related to CAD and general geometry are topology and morphology.Both words describe the state of a certain geometry and can also be used to describe changes. Figure 1illustrates the difference between a simple truss undergoing a morphological and a topological modification.

Figure 1: Illustration of a truss undergoing morphological and topological modifica-tions.

The upper change in figure 1 is purely morphological with the elements changing thickness, angles, andlengths. The lower part of the figure illustrates removal and restructuring elements which are topologicaloperations. The figure illustrates the difference in morphological and topological changes, but also give ahint at what the static states mean. The topology of an object is unaffected by continuous transformationssuch as stretching, it is however affected by discontinuous operations such as tearing or gluing. An exampleof this is that a coffee cup with a handle and torus (a shape often called doughnut) share the same topology,


if the bottom of the mug was torn out however, a new topology would be created. The morphology of anobject on the other hand is affected by all changes in geometry.

In practical terms related to CAD modeling, topological changes are generally made through adding orremoving features while morphological changes are made by re-evaluating existing features.[Tarkian, 2012]

2.1.2 Top-Down and Bottom-Up modeling

The process of creating a CAD model is usually categorized into Top-Down modeling and Bottom-Up mod-eling. In this case, bottom refers to the lowest level of the construction which often means all the subcomponents of a system or product. Analogously, top refers to the highest level of the product or system.

As an example, an aircraft modeled Bottom-Up would begin with designing things like beams, fasteners andpanels and then attempting to assemble them into a finished product. Modeling the same aircraft Top-downwould begin with a simple outline of the aircraft shape and continue by adding more and more detailedcomponents within the context of the original outline. The design of a mechanical product usually takesplace primarily in a top-down fashion. [Mäntylä, 1990]


2.2 Design automation

A key enabler for modern production and development techniques such as design optimization and mass cus-tomization is design automation [Tarkian, 2012]. Even though the concept is relatively simple in that it aimsto introduce automation to the design process, much like it has been introduced in fields like manufacturing,what it actually means and includes has varied significantly since the term was coined [Tomiyama, 2007] anddepends on who is asked.

2.2.1 Geometry automation

For the scope of this project, the most relevant branch of design automation is geometry automation, which isthe study of how various changes in geometry can be made as autonomous as possible.[Ledermann et al., 2005]proposes a division of different levels of design automation, and [Tarkian, 2012] extends this division slightlyresulting in figure 2, which describes various levels of geometry automation.

Figure 2: The various levels of geometry automation structured into a pyramid hierar-chy with the most general methods located at the top. Courtesy of [Tarkian, 2012]

The bottom layer of the pyramid depicted in figure 2 describes morphological relations, and is divided intoequation and script based relations. These methods of making a geometry parametric will dictate the shapeof objects, and is divided into simple equation based relations and script based relations. The methods arerelatively similar, the script based method is however more general in that it can include the equation basedmethods, but add discrete elements. An illustrating the lowest level could be to dictate the shape of a squarewith the equation: "H = W/5". A similar example illustrating the second level could be: "if H > 50mm, W= 10mm else W = H/5" which adds a script statement.


The script based activation state is often realized as a model containing all possible variants of a productgeometry and different parts of the model being activated or deactivated depending on the wanted productconfiguration. This type of modeling can be efficient for products with limited configurations but lacksscalability when it comes to more complicated topologies. The two top levels of figure 2 describe methodsthat use High Level CAD Templates (HLCts) . These methods are implemented by storing various geometriesin databases, and creating models much like building LEGOsTM.

[Ledermann et al., 2005] presents the concept of HLCts as a way of implementing discrete features withvarying geometries, such as the number of frames in an aircraft body, as simple parameters. HLCts areparametric geometries which are stored in a databases and adopt parameters from the context they areadded into upon instantiation. In this thesis, the word instantiation roughly translates to adding an instanceof a template into a context. [Tarkian, 2012] further divides the method into generic instantiation andassociative generic instantiation. The introduced difference being that the associative HLCts are createdwith dependence of an arbitrary context, which is replaced with the context of the product when the templateis instantiated. See figure 3.

Figure 3: Illustration of an abstract template being instantiated into a context. Theupper process describes generic instantiation and the lower describes associative genericinstatiation. Notice the reduced amount of parameters in the lower case. Courtesy of[Tarkian, 2012]

In many cases, the difference between the two methods is not significant, but when it comes to usingcomplicated geometries such as double curved surfaces as references, the generic instantiation suffers sincesuch geometries are hard to parameterize. The associative generic instantiation method however, is notaffected by the complexity of the context into which the HLCt is put. [Tarkian, 2012]

2.3 Knowledge-based engineering

In a Knowledge-based engineering (KBE) application, function requirements transform to engineered design,through a generative model. A generative model is where all the product’s knowledge is stored, includingrules regarding product structure and design standards, relations between product components and betweenfeatures in a component. [Rocca, 2012]

The generative model, illustrated in figure 4, will receive input parameters such as geometric dimensionalvalues, performance criteria and economical parameters and based on these inputs it automatically generatesan engineered product, for instance a 3D model with drawings and bill of materials. This means that different


Figure 4: A generative model transforms functional requirements to an engineeredproduct. Adapted from [Rocca, 2012].

instantiations and variants of a product can be generated from the same product model, by just modifyingthe input parameters.

In order to perform parametric modification of an assembly that represents a product and be able to handle allthe components and its relations, a system with well-defined architecture should be used. [Myung and Han, 2001]calls this kind of system for Design Expert System (DES), which is illustrated in figure 5. The user in a DESis only in touch with a Graphical User Interface (GUI), which is the highest level in this system. The GUIhas connections to all other elements in the system, such as a CAD system and belonging API, part andfeature libraries and - a very central element - the knowledge base. The knowledge base stores all informationabout the features and parameters in the components, relations between the components and configurationknowledge, such as assembly hierarchy and parts arrangement. Another element that can be usable in aDES is an Expert System Shell (ESS), which makes logical decisions based on knowledge defined by a user- for instance ’if this particular condition fulfills, then do that operation’.

Figure 5: Design Expert System, adapted from [Myung and Han, 2001]

The connection between CAD data, such as components or parameters, and the knowledge base is visualizedin figure 6. The knowledge base reads in information, for instance a dimension parameter, from the CADsystem, applies some pre-defined rules on the information and then produces a design object. The design


object can be a design parameter from a CAD model called ColumnLength, that has gone through somelogical operations in the knowledge base to fit its purpose, for instance a mathematical expression basedon other related design parameters - "the ColumnLength should be assigned half the RowLength plus tenmillimeter" is an example.

Figure 6: Link between CAD data and knowledge base, adapted from[Myung and Han, 2001]


2.4 Object-oriented programming and COM automation

According to [Pillay, 2007], Object-oriented programming (OOP) is "a set of tools and methods that enablesoftware engineers to build reliable, user friendly, maintainable, well documented, reusable software systemsthat fulfills the requirements of its users". This section describes the important elements of OOP andComponent Object Model (COM) automation and its functionality in a design process.

2.4.1 COM automation - Link between CAD and third-party programming tool

A majority of the major commercial CAD systems, e.g SolidWorks, has their own Application ProgrammingInterfaces (API). An API enables a wide range of automation features related to assembly structure, dimen-sional properties and other topological and geometrical information in the CAD systems. Some examplesare manipulation of parameters, constraints and relations for a geometrical feature and its connection toother features. This technology makes it possible for the users to customize the CAD system and the CADmodeling process. [Wang et al., 2006].

The automation can be performed internally in the CAD system by creating and storing knowledge, such asparametric rules and relations, in the CAD model. Despite these possibilities, [Wang et al., 2006] considermanaging the knowledge in an external programming tool a more flexible and powerful alternative. Thistechnology, to control one application (e.g CAD system) by scripts from another (e.g Programming tool)is called COM Automation. One major advantage with external knowledge management is that a userinterface can be created and linked to the knowledge base. The user interface is either integrated in theprogramming tool or an independent executable program and from there manipulation of operations withinthe CAD system is enabled. The logic is that an action in the user interface calls a programmed function inthe programming tool, which in turn activates an operation in the CAD system.

2.4.2 Classes and objects

[Wu, 2009] means that OOP in general has two central concepts; objects and classes. An object, which alsois known as an instance, is a thing that contains data and operations for adjusting the data and has statesand features that can be useful for the application. The object can be a function, or a variable containingan actual object or an application, such as MS Excel. An object is unique, all though it may have propertiessimilar to other objects. [Wu, 2009] draws a parallel to object in real life, for instance a cellphone. Acellphone is an object with certain states - it can be turned on and off - and features - it can make phonecalls, reach the internet and take photos - and the same goes with an object in an application. Every objectbelongs to a class, which defines the functionality of the object - what it can and cannot do. [Craig, 2007]describes further on that a class can be interpreted in four different ways:

• a set of objects

• a program structure or module

• a factory-like entity which creates objects

• a data type


One example regarding classes and objects: A class is called "Bicycle" and is a set of two objects; "Bike-1"and "Bike-2". "Bike-1" contains different kind of data, for instance name, type, geometrical dimensions,composition and price, and also operations that enables the data values to be adjusted and assigned. Thesame goes for "Bike-2", with the same data structure but with other data values, and the two objects aretherefore different instances of the class "Bicycle". An object cannot be an instance of more than one class- it strictly belongs to that class - and a class can contain unlimited amount of objects. This example isillustrated in figure 7, which shows how two objects belonging to one class share some important featuresand have one unique feature each [Wu, 2009].

Figure 7: Example of objects within a class. Adapted from [Wu, 2009]

According to [Clark, 2006], it is crucial to establish a well-structured system approach when developing aobject-oriented program. Firstly, the class structure should be modeled, based on the system’s functionalrequirements. The classes will implement the required functionality, by creating objects within them. Furtheron, it is important to define the purpose of each class, which kind of data and operations the classes areresponsible for. One derived example is a flight booking application that contains many classes, wheretwo selected ones are a "Flight class" and a "Customer class". The "Flight class" is responsible for all theflight operations, including objects that manages flight number, flight duration, departure information andseat reservation. All data, functions and other objects related to the customers, such as name, contactinformation, credit card type and a account creation function, are stored and handled in the "Customerclass".


It is also important to enable efficient and structured connection between related classes, since they mostlikely need to pass data back and forth. This relationship between classes is called association and forinstance, the seat reservation function in the Flight class needs customer data from several objects in the"Customer class". The class structure in OOP, including the association between classes, is illustrated infigure 8.

Figure 8: Class structure and association in OOP, a function object in one class receivesinformation from data objects in another class. Adapted from [Clark, 2006]

2.4.3 Inheritance and superclasses

Another widely used term in OOP is superclass. A superclass is a common base, high up in the hierarchy,from where classes (subclasses) inherit common features. This mechanism is called inheritance and whendealing with multiple objects that are different but share some features it is, according to [Wu, 2009], moreefficient than using single classes for each object.

One example of superclasses and inheritance is illustrated in figure 9; an aircraft has the same commonfeatures as "Means of transportation" - feature categories such as number of seats, speed and range - and istherefore a class of that superclass. Further on, "Fokker 100" is an aircraft model - an object belonging tothe class "Aircraft". As figure 9 explains, the class frame contains a component list with pointers to otherframes and in the "Fokker 100" case these frames are for the wing and the fuselage, which are parts of the"Fokker 100" assembly. [Rocca, 2012]

[Wu, 2009] derives another example, in this case regarding bank accounts. A saving account and a checkingaccount are two classes that share many features, they both belong to the superclass "Bank account" andhave inherited some of its features - supplemented with some unique features for each class.


Figure 9: Example of a superclass, based on an aircraft. Adapted from [Rocca, 2012].

2.4.4 VBA and VB.Net

Visual Basic for Applications (VBA) is a object-oriented programming language developed by Microsoft. Themain usage is to control objects in Microsoft applications, such as Excel and Word, but many other applica-tions can also be programmed and customized by coding in VBA. VBA enables a high level of automationin these application, e.g automate processes and sequences that are done manually in the application. Thistype of automation is called ’Macro creation’. A macro can, for instance, consist of an automated sequenceof creating an Excel chart and adding data from a database to it. [Chaudhary et al., 2002]

Visual Basic .NET (VB.NET) is, as well as VBA, an object-oriented programming language. The code syntaxand the way of managing object are similar between the two, but there are also some differences. VBA needsWord, Excel or other host applications to fill a function and cannot create stand-alone applications by itselfand be run separately in a context. VB.NET on the other hand does not need a host application to createexecutable stand-alone programs and is therefore a better option when developing something from scratch.Further on VB.NET is a much more powerful tool, with better debugging features and a larger code library.On the other hand it is more strict in terms of defining objects and classes and therefore more complex andharder to learn for a beginner. [Chaudhary et al., 2002] [Willis et al., 2004]


3 Method

This chapter will present the various methodologies used in the project. Section 3.1 defines the methodologiesand describes how they work, while section 3.2 presents how the methods where applied in the project.

3.1 Methodology for software development

In this section, agile software development in general and the main method in this thesis, Scrum, aredescribed.

3.1.1 Agile development

According to the Agile Manifesto, published after a meeting in February 2001 between 17 software developersdiscussing lightweight development methods for softwares, Agile development has twelve principles:

• Customer satisfaction by rapid delivery of useful software

• Welcome changing requirements, even late in development

• Working software is delivered frequently (weeks rather than months)

• Working software is the principal measure of progress

• Sustainable development, able to maintain a constant pace

• Close, daily co-operation between business people and developers

• Face-to-face conversation is the best form of communication (co-location)

• Projects are built around motivated individuals, who should be trusted

• Continuous attention to technical excellence and good design

• Simplicity

• Self-organizing teams

• Regular adaption to changing circumstances

One important characteristic of Agile development is the short iteration time, which normally lasts from oneto four weeks. One iteration contains the entire software development cycle, including planning, requirementsanalysis, design, coding and testing, and the goal is to have a functional version of the product after eachiteration. For each iteration the developers add new features or improve the present ones until the productis ready for market release. The team is usually cross-functional and self-organizing and is often responsiblefor the tasks that fulfill the requirements for an iteration. How to do it is the team members’ decision andnot up to people higher up in the company hierarchy.

An agile team shall contain a representative from the customer, who is appointed by the stakeholder and isavailable for the developers in case of questions between the iterations. This person is personally committedto the project and ensures that customer needs and company goals will be fulfilled.

Agile development is an adaptive (value-driven) method, which means that the team adapts quickly tochanges in the project, such as customer needs and new technology. Therefore agile teams set up short-termplans in the development and future events will be vague described and just contain information about whichfeatures that will be concerned.The other side of the spectrum is predictive (plan-driven) methods, in whichone plans the future tasks on a detailed level and has difficulties when the project requirements change.[Hazzan and Dubinsky, 2014]


Example of agile software development methods:

• Agile Modeling

• Agile Unified Process

• Dynamic Systems Development Method

• Essential Unified Process

• Extreme Programming

• Feature Driven Development

• Open Unified Process

• Scrum

• Velocity tracking

• Test-Driven Development

• Lean Software Development

• Continuous Integration

• P-Modeling Framework

• Pair Programming

3.1.2 Scrum

As a general method for developing software and configuration strategies, a method known as Scrum waschosen. Scrum is a common agile development method [Meyer-Stabley, 2014], in which the software featuresare developed in multiple working sprints which can be viewed as miniature projects. To structure thedevelopment, the work is broken down into epics, user-stories and tasks.

Epic, user stories and tasksEpics are wide statements which describe the overall vision of the project or company. These statementsare usually not relevant in day to day work, but work as guidelines for the entire development process. If acompany constructing airliner aircraft is used as an example, the statement "As a traveler, I want to travellong distances in a short time, in order to maximize my vacation" could be an epic.

To make projects more tangible, the epics are divided into smaller chunks called user-stories. User-storiesare often formulated according to certain templates, and a frequently used template is: As a "...." i wantto "....", in order to "....". In the airliner manufacturer example a user-story could be: "As a pilot i wantto be able to retract the landing gear, in order to have a safe landing". The stories can also be "told" bymore abstract entities. An example of this could be: "As a flight control system I want to know the angularacceleration of the aircraft, in order to maintain balance".

The lowest level of division is the splitting of user-stories into tasks. Tasks should be small chunks of workwhere it is easy to determine if the work is finished or not. In software development, it is considered goodpractice to aim for tasks to take one person a couple of hours and not allowing them to take more than afew days.

Working in sprintsIn opposite of epics user-stories and tasks, sprints are not a way of breaking down the work, but rather a wayto organize the way the user stories and underlying tasks are tackled. A sprint usually lasts between one andfour weeks and can contain one or several user-stories. A sprint contains the entire software developmentcycle, including planning, requirements analysis, design, coding, and testing, and the goal is to have afunctional version of the functionality described in the user stories after each sprint.

When a division into user stories and tasks has been performed, the stories are stored in a project backlog,and as a sprint starts, an appropriate number of user stories are taken from the project backlog and placedin a sprint backlog. Figure 10 visualizes the different backlogs.

Scrum rolesThree distinct roles are usually defined in Scrum projects. The first is a Scrum master which functions asa coach or expert, and assures that the methodology is maintained. The Scrum master is not a boss buta experienced adviser and shall always be available for the team when needed. Product owner is the rolethat represent the customer and its business interests. It owns the product backlog, which means it decides


Figure 10: The storage of user stories, in a project backlog and a sprint backlog

what kind of features the product or service should have and the priority of these features. The third role,the team member, is a part of the team that develops the product or service. The main responsibility ofthe team member is to complete tasks in order to fulfill the user stories and therefore generate value to theproduct or service. It is also responsible for planning and organizing the work, which tools and methods touse and how the features should be developed.

3.2 Methodology in this thesis

The main focus of this thesis is development of a CAD plugin software and for the development process, themethod Scrum has been used. As it is described in section 3.1.2, the Scrum method breaks down the projectinto epics, user stories, sprints and tasks.

3.2.1 Structure and work process

An epic story works like a vision for the project, in this case one epic is defined as "As a designer at aconstruction consultancy company I want to generate different CAD configurations of a house foundationwith short iteration time, in order to cut lead time for my customers". The user stories are more concreteand normally describes some functionality that need to be developed, for instance "As a designer at aconstruction consultancy company I want to be able to control, and adjust, the morphological parametersfor each component in the house foundation model, in order to make quick changes in the design". The userstory is then divided into tasks, where each one represent an element that is needed to fulfill the functionality.A task should not take longer than a couple of hours to perform and could in this case be "create a scriptthat automatically traces the location in the model for a component’s parameters and checks their values.The normal procedure for a function development task in this project is, as it is visualized in figure 11, asfollows:


Figure 11: The breakdown structure of Scrum, from epics, through user stories, totasks.

1. Manual testing in the CAD tool. This is a logical first step, because if it is not possible to do a CADoperation manually it can obviously not be programmed

2. VBA testing. The CAD tool in this project, SolidWorks, has a direct link to the programming tool Vi-sual Basic for Applications (VBA). This connection enables macro recording, which means that manualoperations in the CAD tool are recorded and translated to usable code. From VBA a programmedfunction can be created, debugged and tested quickly and easily, thanks to the direct link between thetools.

3. VB.Net testing. Next step is to test the function in VB.Net, which is the programming language thatthe configurator development company uses. VBA and VB.Net have very similar code syntax, but afew adjustments are always needed.

4. When the function is fully developed, it will be implemented in the configurator code document. Thatproject has a certain structure and the function has to be designed to fit in with the hierarchy and theoverall functionality.

In some cases, step 2 in this process is skipped. For minor functions, step 3 is also not necessarily and thecode is written directly in the configurator code document.

A sprint normally lasts 2-4 weeks, contains a couple of, often related, user stories and should result in apresentable solution. For instance, the first sprint of this project contained user stories about defining needsand wants from the customer - the construction consultancy company, understand the logic and structurein the configurator code document and develop some basic functionality, in order to present to the customerhow this software in the future will look like.


3.2.2 Roles

In the thesis project, the Scrum master role is held by company founder Ph.D Mehdi Tarkian. The secondrole is a product owner, who in this case is the Chief Technology Officer of the construction consultancycompany. The authors of the thesis holds the role of developers, which are responsible for creating contentand developing features of the software.

3.2.3 Communication between the Scrum actors

The developers have briefly stand-up meetings daily with the Scrum master, in order to ensure the qualityand relevance of the current work. The communication with the product owner is less frequent, this actoronly get informed about the work progress when a major feature is finished or if some initial requirementsare changed or adjusted.

3.2.4 Example of tasks within a user story

Below an example of how the tasks to fulfill a user story could look like. The chosen user story for theexample is the one where the instantiation function was developed, which was one of the greatest challengesin this thesis.

"As a developer of the API software I want to have a function that enables inserting copies of certaintemplates of components, in order to be able to develop configuration operations for the API"

This user story included following tasks:

• Define the logic of the instantiation process

• Save an instance of a component template and save it with a new name

• Find and store all the needed references for the instance

• Find and store a reference’s child features

• Find and store a reference’s parent references

• Change references in an instance from its own to references in the context

• Select and store the inserted component’s parent component by clicking on it in the CAD model tree

• Ensure that an instance cannot be inserted wrongly, e.g only on pre-defined parent components

• Error management when something has been wrongly inserted

Almost every task includes manual testing in SolidWorks, macro recording and testing with VBA, beforethe results can be implemented in the API using VB.NET. A task takes normally a few hours to perform,even though some tasks are much more time consuming than expected.


4 Execution

The work in this project is divided into sprints, which each contains one or a couple of user stories (US).The execution of these sprints, which summarizes the development work in this thesis, is described in thischapter. The entire project is based on an epic story, which describes its vision and the purpose of why thisproject is needed:

4.1 Overview of the project and included sprints

This section presents the sprints included in this project and also the sprints belonging user stories. Theuser stories are described more detailed in section 4.2.

Figure 12: Work sprints and included user stories in this project

Sprint 1 - Gather customer needs and get familiar with the configurator software

The first step of this project was to meet with the customer - the construction consultancy company - andgather information about their design process and their needs. Further on, this sprint included the writersgetting familiar with the Solidworks API, programming in Visual Studio using VB.Net and the code structureof the configurator tool in which the development takes place.


• User story 1 - Customer needs

• User story 2 - Software learning

• User story 3 - Implementation understanding

Sprint 2 - Develop basic functionality for the API

This sprint aimed to develop functions that are vital for a 3D CAD configurator, such as add, delete andchange components in a product. First when these functions were implemented in the API, the specificsolutions in the case of effectively generating drawings could be addressed.

• User story 4 - Requirement specification

• User story 5 - Instatiation function

Sprint 3 - Develop specific configuration functions

When the instantiation function was fully developed, focus was to create configuration functions from therequirement specification. Functions such as add, delete and change component in an assembly and alsomodification of parameters were in this sprint developed. Many of the functions need access to the instanti-ation function and therefore the importance of fulfilling User story 5 was very high. It shall be added thatthis sprint only contains functions for configurating the components. Functions such as automatic drawingand BOM generations will be developed in a sprint later on.

• User story 6 - Insert and delete component

• User story 7 - Replace component

• User story 8 - Adjust morphological parameters

• User story 9 - Create group of components

Sprint 4 - Create parts and methods for the customer

To prove the developed configuration methods can be applied in real scenarios, the system was tested on aproblem posed by the company in the construction industry. The problem concerns configuration of geometryin a raft foundation for a house in a way that allows for the result to directly generate drawings and be usedin e.g finite element method modeling. For the naked eye, a raft foundation looks like a simple concrete plate.Underneath the plate is a structure of concrete beams that take the loads of the buildings weight which aretransferred down through the load carrying walls of the building. These beams in turn hold various types ofarmament to make them tougher and less susceptible to cracking.

• User story 10 - Creating a method of configuration

• User story 11 - General modeling technique

• User story 12 - Modeling flexible modules


4.2 Work process based on the user stories

In this section, all the user stories are explained - what they aim to, how they are performed and the resultsof them

4.2.1 User story 1 - Customer needs

ExecutionTo figure out customer need the developers and the Scrum master visited the construction consultancycompany. The meeting gave insights in their design process

80% of the customer’s design work in CAD is with 2D drawings, which differs from the manufacturingindustry, where mostly 3D models are used in the design process. The customer starts with an architectdrawing, adds symbols that represent all the components in the product and in the end a building drawingis created and can be delivered to a contractor. The adding symbols part is often very time consumingand many operations are done manually. Therefore the customer is looking for another, more efficient,way to generate building drawings and want to try the same methodology as product configuration in themanufacturing industry; to configure the product with components in 3D and generate drawings from theconfigured 3D model.

SolutionThe construction consultancy company delivers building drawings to companies building houses and infras-tructure. The process of generating these drawings is very time consuming and requires many manual,repetitive activities - therefore the company wanted a tool that enables an effective way of generating draw-ings, with as few repetitive activities as possible. The customer demands are more detailed described in therequirements specification in 4.2.4


4.2.2 User story 2 - Software learning

Following softwares were expected to be the main tools when developing the API for the configurator:

• SolidWorks (CAD system)

• VBA (Programming language)

• VB.Net (Programming language)

• Visual Studio (Programming tool)

• Trello (Scrum software)

The authors had, before start of this project, knowledge about programming in VBA, but the experience inthe other four items was very low - therefore a initial learning period was necessary.

SolidWorks is the tool and host application in which all geometry and belonging parameters are created. It isalso in that tool the configuration of the product is made, executed through scripts written in VB.Net. Theentire configurator tool is made in visual studio using VB.net as language. This includes all CAD relatedsoftware as well as the user interface.

VBA code handled in SolidWorks native programming interface worked as a complementary tool, due to itsdirect link to SolidWorks. SolidWorks enables macro recording, which means doing manual operations thatare as code in VBA. Therefore, VBA was an excellent tool to use for initial development of a function.

Trello is a Scrum software and was used to organize and structure the work process.

4.2.3 User story 3 - Implementation understanding

"Gaining an Understanding" can be done in many ways, and in this case it was done by slowly beginningto implement the first, and most basic features of the API while simultaneously following all processes andcode structures carefully. Further understanding was gained through discussions with the original developer.

The configuration application of the company contains many classes and sub-classes, which each has multipleobjects within and due to corporate secrecy these will not be explained in detail in this report. However, theconfigurator application roughly consists of one high-level block, in which generic operations for configurationare stored, three blocks called API classes - one for each CAD system and a database. As said, the high-levelblock is generic and not dependent on any particular CAD system and it triggers operations in the APIclasses. Examples of content in the high-level block are the user interface, configuration sequence logic andconnection to the database, wherein the components and their parameters and dependencies are stored.Each API class contains functions and other objects that trigger operations in the actual CAD system - for


instance in this project, an API for SolidWorks is developed and it is linked to operations in SolidWorks’interface.

Figure 13: Structure of the CAD configurator, with one high-level block, three APIclasses and a knowledge base

The class structure and association between classes are described in section 2.4.2 and an example basedon a flight booking application is illustrated in figure 8. A similar structure and association exists inthe configuration application, which can be seen in figure 13. In order not to reveal any corporate secrets,structure and content of the classes as well as the hierarchy and other elements, the system has been modifiedin several ways in the figure, but the concept and how classes cooperates are quite the same.

In a more holistic view, the whole configuration system is similar to the design expert system adopted from[Myung and Han, 2001], which is explained in section 2.3 and illustrated in figure 5. The only difference isthat no Expert system shell and its API have been used, though the operations that normally is handledthere, instead is placed in the CAD system API. The design expert system in this project is illustrated infigure 14.

4.2.4 User story 4 - Requirement specification

ProblemMainly two channels were used to set up the requirement specification; customer inputs and the currentconfiguration tool. The configurator has an API for the CAD system Catia V5 and despite it is mainly


Figure 14: Design expert system in this project

developed for products in the manufacturing industry and the case of this thesis is directed to the constructionindustry, several functions are relevant for this API as well. The required functions were then stored in theproject’s sprint backlog. To summarize the requirement specification, some functions, such as add and deletecomponents in an assembly, are generic configuration operations based on the current configuration tool andsome functions are specifically developed to meet a construction company’s wants and needs.

The first features to be addressed where the functions related to the HLCt database and the extraction ofparameters and references from the parts. This feature was attacked first, partly because it enables theimplementation of other features such as instantiation, and partly because it is a good place to start sincemany functions require that feature.

SolutionThe configuration software should include functionality that enables the user to:

• Insert components into the assembly

• Delete components in the assembly

• Replace components in the assembly

• Create and insert groups of components into the assembly

• Change value of the inserted components’ morphological parameters, e.g length, width, height


• Generate drawings out of the configured 3D models

• Generate BOM lists of the including components

Demands on the configuration software structure and the product delivered to the construction company:

• An architect drawing should be the input to the configuration

• By instantiation, the added component should adapt to the context of the assembly and use thecontext’s references

• A component should only be dependent on the parent component and not have upstream referencesto any other components

• The designer should be able to reuse parts to an extent as large as possible

According to the product owner at the construction company, the most time-consuming operations arerelated to the creation of the CAD models and the actual configuration of the components - to generatedrawings and add all necessary symbols and annotations to the drawings is relatively a quick and efficientprocess. Therefore, the development focus in this project has been on the configuration logic and the CADmodel library - the lack of drawing-related operations have, with this consideration, been a delimitation.

4.2.5 User story 5 - Finding and re-creating needed functionality

ProblemAn important enabler for the existing configurator design is functionality which enables CAD features to beput in some sort of container. The authors identified two potential candidates to be used. The first optionto be considered was feature folders, but the authors identified several problems such as features only beingable to be in one folder at a time. Instead a functionality called selection sets was chosen. The feature wasintroduced in SolidWorks 2015 and allows the user to make a selection of items and save it. The selectionset functionality has many attractive properties, but the SolidWorks API lacks full support for manipulatingthem. This fact was however possible to handle by significant amounts of "work-around" code.

The configurator was originally built around the CAD program Catia V5 which has a specific functioncalled Power copy. Another commercial CAD software, Creo Parametrics, has a similar function calledUser Defined Feature. These functions are similar and enable the creation of an independent instance of acomponent - a HLCt, described in 2.2.1, which can be inserted into an assembly and be modified withoutinfluencing the original component’s definition. Briefly that means that the same component can be reusedmultiple times and every instance can be modified individually. The SolidWorks option which comes closestto similar possibilities is called library feature but to the writers knowledge, it is not as flexible or genericas the functions found in the other CAD tools.


This function is a major enabler in the project, due to its large scope. It included how to manage thereferences within and between components, how to control topological and morphological parameters andthe logic for most of the configuration operations, for instance in which order sub operations for adding ordeleting a component in an assembly should be done.

SolutionThe sequence logic for the instantiation function is as follows:

1. Activate the main assembly

2. Open and activate the HLCt part file

3. Reactivate the main assembly and insert an instance of the HLCt

4. Make the inserted component "virtual" which breaks the link to the HLCt file and saves the componentwithin the assembly.

5. Choose a parent component, which the inserted instance will refer to, by manually clicking on it in theCAD model tree. In cases where one parent has possible references, click on the specific feature whichthe component should refer to after clicking on the parent. This can be done in the graphics window.

6. Replace the instance’s original references with references from the parent component in the context,e.g segments from the architecture drawing

(a) loop through the context references, which are stored in a folder. The context references will laterreplace the old ones

(b) loop through all child references of each reference

(c) for each child reference, loop through its parent references. The parent reference represents theold reference

(d) replace every parent reference with the new reference from the parent component in the context

All these operation, except choosing the parent component, are made automatically by functions developedin the configurator and the API.

4.2.6 User story 6 - Instantiate and delete components

ProblemDue to the fact that instantiated components are meant to adapt to the context of the assembly and thereforeuse its references, issues can arise since removing a certain part not only affects the part itself. The concept


is similar to breaking a link in a chain - if one component is deleted without care it affects the references toother components and the assembly will fall apart because of missing references.

A component in the assembly can be deleted in two ways; a normal delete operation and a component changeoperation, which includes deleting the replaced component from the assembly. The normal delete operationhas simple logic - the component get selected in the model tree and then deleted - but when replacingthe component, much more logic had to be implemented in the delete function. To ensure that the newreplacement component will be inserted on the same spot in the assembly as the replaced component, theexternal references in the context for this component have to be stored before it get deleted. For instance,if a corner module component refers to an axis in the context, that axis has to be stored and used in theoperation of inserting the replacement corner module.

Each component has a geometrical set, which is a container where its references needed for instantiation arestored. In practice, when a component gets deleted and its context references are getting stored, followinglogic has been used:

• Loop through the component’s references in the geometrical set folder

• For each reference, perform a control if it an external reference and therefore a link to the context

• If it has, store the reference’s name in an array

Why not store the actual reference instead of just the name? The answer is that SolidWorks in many casesuses string variables in their programming operations. In the instantiation function, when the referencedescribed above is needed, only the string variable defining the reference’s name is needed.

SolutionThe issue with the two delete operations - how can the program understand if it is a component replaceoperation or a normal delete operation - is solved by implementing flags in a higher class in the configurationsoftware. The flags are simply integer parameters, which can be set to 0 or 1, based on which type of deleteoperation it is. If it is a component replace operation, the parameter will be set to 1 and a condition in thecomponent change function checks the value of the flag parameter - if it is 1, it stores the soon-to-be-deletedcomponent’s context reference and use that reference later for the replacement component.

Regarding the insert function, most of the logic derive from the instantiate function - the insertion logic isactually integrated in that function. The actual insertion is just a few lines of code, including logic for "addcomponent" and renaming the added component but all the functionality regarding reference managementcome from the previously developed instantiation logic.

4.2.7 User story 7 - Replace component


ProblemThis function is a combination of the instantiate and delete functions, because the operation logic whenreplacing a component is to first delete the old component and then add the new one. In 2.2.1 changestopological parameters were described and it basically means changes on an assembly level, for instance howmany pillars that shall be inserted, which type of pillars and where in the context they shall be placed.

As described in 4.2.6, the replace operation includes the deletion and the insertion functions. Firstly thecomponent that is about to be replaced gets deleted and its context references get stored in an array. Nextstep is the insertion of the new component, which uses the context references that previously got stored inthe array to fit into the assembly. If the soon-to-be-replaced component has children components in thehierarchy - for instance a reinforcement detail (child component) that is instantiated on a concrete beam -it becomes a little bit more complex. If the concrete beam got replaced, the configurator also deletes thereinforcement detail and other eventual children, stores these components’ context references in the arrayand then inserts the new concrete beam and the child components. The child components are the same, butneed to re-refer to the context. Therefore the need of storing the context references is crucial.

Solution

A simplified illustration of the process of the reference management when replacing a component can beseen in figure 15. Roughly explained, the part file of the assembly of the soon-to-be-deleted component getsopened and once there, three loops with belonging IF conditions are performed until the correct contextreference has been found. That context reference then get stored in an array and when the replacementcomponent get instantiated, it automatically uses that reference in order to be placed on the right spot inthe context.

Figure 15: Reference management in a replace component operation


4.2.8 User story 8 - Adjust morphological parameters

ProblemAs described in 2.2.1 morphological parameters decide the geometric shape of objects and this case it couldregard adjusting length, width and height for a wall in the assembly. The construction designer should beable to change these kinds of parameters after the wall is inserted, and without influencing other componentsin the assembly.

SolutionIn order to fulfill this user story, sub functions for following operations had to be developed:

• Find the location where in the CAD system the parameters of a component are stored and automaticallyadd them to an array.

• Make the parameters manageable from the user interface by implementing a generic naming convention

• Link the value of the parameter to a variable, which can be reached and adjusted in the user interface.

Further on, logic for the connection between the database and the CAD tool were developed. Some logicalready existed in the configurator software, but many functions were CAD software specific - they werepreviously suited for Catia V5 but needed functionality for SolidWorks. An adjusted parameter, such as adimension change in a component, needs to be updated also in the database, in order to enable re-usabilityin the CAD models.

4.2.9 User story 9 - Create group of components


ProblemGroup creations of components can save a lot of time for the designer, especially if the model structureconsists of many parent-child component relations (see figure 20). This kind of relationship is about how theinserted components refer to the context. If a inserted beam is referred to an axis in the drawing (the threadmodel), the drawing is the parent and the inserted component is the child. If also a reinforcement detail isinserted on the beam, we get two parent-child relations - or a ancestor-child relation. In some cases it canbe even more layers of component relations and therefore a group function can be very useful. The multiplelayers group of components can be created once and work as a sub configuration. This sub configuration canthen be re-used and inserted on another place in the context, instead of inserting each component step bystep again. For instance, a house foundation has a total amount of eight 90 degrees corners - which include acorner module (parent), a reinforcement detail (child) and a support beam (child). The designer instantiatesthese three in the context and creates a group of them. Then, he or she instantiates the entire group on theother seven corners - which means seven instantiation operations instead of 21.

SolutionIn order to develop this function, a couple of other sub functions have been re-used. One central sub functionis the "select parent" function, which previously has been operative in the insert component function. In thatfunction, the program requests the user to select a parent in the CAD model tree for the inserted component.The same goes with the group function; the program requests the user to select components in the tree thatshould be included in the group.

As well as the replace component function, so called flags have been used to determine what kind of in-stantiation operation it is. The reason is that the same instantiation function is used, regardless if it is agroup instantiation or a normal single component instantiation. These operations differs a bit regarding thereference management - in the group instantiation the components use the same context references as thecomponents from the initial group, while in a normal instatiation, the user manual choose the reference inthe model tree. The operation of storing and re-using the context references is handled by the same functionas in the replace component operation, described in section 4.2.7.

4.2.10 User story 10 - Creating a method of configuration

Introduction to the studied case

The studied case from the company in the construction company concerns the configuration of the variouselements of a raft foundation. A raft foundation is used in many housing applications and the most visiblepart of it is usually a concrete plate shaped like the house. Under the parts of the plate where walls are


attached, thicker concrete beams with various types of reinforcing rebars are placed to take the loads causedby the weight of the building.

A typical drawing of such a construction is divided into two parts. One specifying the measurements ofthe components, and one showing what kind of reinforcement to use and where to place it. The reinforce-ment is described using various symbols, often accompanied by annotations describing how and where theconstruction worker should place the rebars.

ProblemOne aspect of creating a method for configuring any geometry is deciding upon a general hierarchy. Inmany cases the hierarchy is rather obvious. In this case however, the problem is subtly difficult. Eventhough the geometries of a house foundation are simple in themselves, they depend heavily on each otherand the decision of which piece to put at the highest level of the hierarchy is not clear. In previous productsconfigured by the start-up company, the choice of which part to put at the top of the hierarchy has beenrelatively obvious and the developers have always managed to create modules which can be reused. Theconscious choices related to the product have then been made when the parts are instantiated.

One approach would be to put an edge beam as the highest piece in the hierarchy and have it serve as aparent for other edge beams and internal raft beams. Even after a lot of thought and several discussions,the authors could not think of a way to design modules that could be used in such a manner. The mainreason for this is the fact that the design of the existing configurator does not allow for parts have referencesto several parent parts. In previous examples with similar characteristics, parts which connect to each otherhave contained references for themselves meaning the user can chain together several parts to create thewanted configuration. At first glance this approach seems like it could be used, but problems arise due tothe fact that the shape of most beams in a given construction depend on at least two other, which eitherbreaks the parent-child structure in the configurator, or requires two parents.

SolutionTo find a solution, the authors chose to lift the topological aspects of the geometry to a higher level andcreate a wire-frame of axes as the module highest up in the hierarchy. This frame would be created by theconstructor as he or she makes the conscious choices of which parts of the building should carry loads. Anexample of how such a frame could look can be seen in figure 16

Figure 16: An example of how the information in the architect drawing can be reducedto a wire frame of the lines which carry loads

Initially this approach seemed unattractive since it would not be possible to create a reusable module ofthe wire frame. To make matters worse, the references for other parts can not be put onto the moduleautomatically. This means a constructor first has to create a frame of which lines carry loads and thenmanually assign certain combinations of these lines to selection-sets (see section 4.2.5) in order to create sets


of references for the parts which are subsequently added. Weather or not the method is feasible is discussedfurther in section 6.5.4

4.2.11 User story 11 - General modeling technique

The authors aimed at achieving associative generic instantiation (see section 2.2.1) when creating the mod-ules. To do this, all models where created by first making geometry onto which the references can be put.The modules made in this project mainly refer to two or three axes, which means the first feature to becreated was a sketch containing two or three lines that serves references for axes. All features which arecreated after the axes only refer to them.

When the modules are instantiated as described in section 4.2.5, the reference in the axes are changed fromthe placeholder-sketch to axes in the wire-frame causing the module to end up in the right place and takethe right shape. The sketch will still be in the component and thus in the assembly, it will however alwaysbe hidden.


4.2.12 User story 12 - Modeling flexible modules

ProblemAs written in section 4.2.10, the chosen hierarchical structure involves a wire-frame which outlines whichparts of the building should carry loads. During the project the writers has failed to find a way to automatethe creation of such a frame, mainly because the process of creating it involves making choices based onengineering knowledge. Instead the first level of generic components include various corner pieces, beamswhich can be used as either edge beams or internal raft beams as well as a slightly modified beam piece whichcan be used where two beams meet with a certain offset.


SolutionFigure 17 illustrates how the corner modules are designed. The first module to be created was a corner pieceto be used where two beams connect and takes two axes as references. The module should handle blunt,sharp and perpendicular corners and should have two design parameters which correspond to the width ofthe beams that connect to the corner-piece. The geometry is constrained by forcing the lines that meet thebeam to be perpendicular to the axes, the lines that make up the outer sides of the corner piece to be parallelto the axes, and by forcing the axis to be coincident with the midpoint of the side that meets the beam.These constraints fully define the shape of the corner and by adding a parameter to the width of the sidethat meets the beam, the module is fully defined and takes the desired shape based on the reference axes.

Figure 17: Images of the designed corner module. The same module can be used forsharp, blunt or perpendicular


The beam part was modeled with the intention of using three lines as input when instantiating it. Oneline on which the beam part is to be placed and two lines which define the way the beams interacts withconnecting beams. The beam is modeled as a simple cuboid, that is extruded from the middle of the mainaxis towards the points where the main axis intersects the other two axes which are used as references. Thecuboid does however not extrude all the way to the intersection, but is interrupted by a plane which is offsetfrom the intersection by a certain distance which makes the corner of the cuboid coincide with a bisectorof the smallest angle. see figure 18. The design of the module allows it to always meet the corner modulelike two pieces of a puzzle since the trigonometric formula makes the corner of the beam coincide with thebisector of the smallest of the two angles. The same formula is used to calculate the offset of the left part ofthe beam, but this is left out to not clutter the figure.

Figure 18: A principal explanation of how the beam module is modeled. The blue rectanglerepresents the solid beam, and the dashed lines represent the three axes which are used asreferences for the module.

A selection of modules representing concrete reinforcement where also created. These could have beencreated in various ways, but since focus was put on achieving results which easily can be turned into usabledrawings, the authors designed them as adaptable sketches resembling the symbols used to in the drawings.If the configured geometry is to be used for structural analysis, a different approach might be needed, butthe authors consider this to be outside of the project delimitations.

These modules make up the most important pieces and many simple designs can be created using them. Tomake the study slightly more general, more modules where added, but will not be described in detail.

• A module handling intersection where a beam intersects another at an angle different from 90°

• A module handling situations where two beams meet end to end with an offset less than the width ofa beam. This module was created by simply changing the beam module to adding the value calculatedby the trigonometric formula instead of subtracting it.


4.3 Comparative study of different configuration approaches

In the traditional approach of projections and to generate drawings in the construction industry, mostly 2DCAD is used for the modeling work. It is a well-proven approach and thanks to the long experience of theengineers at the construction consultancy company in this thesis project, the lead time of generating drawingmaterial is relatively short. It has some flaws though, and several aspects have made the company keen onchanging the approach to work more with 3D CAD configuration. One major aspect is the amount of manualoperation needed when generating a drawing, such as putting all the drawing elements on the right place inthe drawing. Especially when a change of design in a component or in the assembly structure appears it isnoticeable - often it leads to many manual operation to update the drawing and sometimes is has be doneall from scratch again. Another aspect is that finite element method analyses and other calculations on theconstruction cannot be performed directly if there is not a full scale 3D model at hand. The new approachis therefore to first configure the entire product, for instance a building, in 3D and then use the 3D modelto perform the analyses and calculations and finally generate the drawing.

After completing the development of the configurator API, a comparative study was performed. The studyaimed to compare two different 3D CAD approaches of configurating products in the construction industry:

• Parametric configuration (generic instantiation)

• Context-based configuration (associative generic instantiation)

In figure 2 several different levels of geometry automation are described, including the topological levelsassociative generic instantiation and generic instantiation. The second approach, parametric configuration,is using the level generic instantiation when configurating a product, which means that all operations arecontrolled by parametric relations in the CAD models. The developed software in this project has enabledcontext-based configuration, by adopting the highest level in the pyramid; Associative generic instantiation.Instead of using parametric relations in the CAD models to control the configuration operations, it is alwaysthe context that control the operations. In this case the context is either the constructed wire frame orpreviously inserted components.

The approaches have been compared based on the same architecture drawing, representing a house foun-dation. This thesis describes the process of generating building/construction drawings based on that andhighlights advantages

4.3.1 Process of the approaches

In the initial phase, the process for the approaches is very similar. Following three steps are always includedwhen a project is launched:

• The designer receives an architecture drawing and creates a thread model in CAD with axes or sketchlines defining the construction’s geometry

• Configure and add elements, such as walls and beams, from the configurator to the thread model.

• Configure the added elements morphological if needed

When changes in the design appear though, normally when the building permit is adjusted, there are somedifferences. Similar for both approaches is that the first step is to update the thread model based on thedesign changes. In the next step, a major difference appears. With approach 1, parametric configuration,the dimensions for all components affected by the design change need to be adjusted to fit the new context.In Approach 2, the context-based configuration, these adjustments are not needed. The reason is that thecomponents have inherited the context’s references and if the context, for instance the thread model, hasbeen changed, the components will be updated automatically to fit the context. Therefore there is no need of


adjusting parameter values when dealing with a design change. Figure 3 describes more detailed the differ-ences between parametric instantiation (generic instantiation) and context-based configuration (associativegeneric instantiation).


5 Result

In this chapter the result for this thesis is presented, which includes the developed configuration software,the configuration hierarchy and the CAD models created for the case study. The result chapter also includethe programming structure, with classes and objects, that has been used in this project.

5.1 Programming structure: classes and objects

This project has not developed the entire configurator, but the API supporting configuration in the CADsystem SolidWorks. Due to confidentiality reasons the configuration software is not in detail explained butit has many classes for different purposes. A selection of the classes is listed below:

• Communication with database

• User interface logic

• High-level configuration logic

• Save management

Each class consists of objects, which mainly are functions that perform some sort of configuration or ad-ministration logic. In this thesis, mainly two low-level classes have been developed. Low-level means it isthe logic closest to the actual configuration, the operations in the CAD system - for instance insertion of acomponent. Following classes have been created in this thesis:

• Bundle class

• CAD API class

Both these classes already existed in the configurator, but they were developed for the CAD system CatiaV5 and therefore they had to be re-developed. Bundle class is the link between the high-level configurationlogic and operations in the CAD system and in this class the objects are mostly functions for instantiation,deletion, parameter adjustment and other configuration functions. Some objects are not functions but globalparameters, that are needed when several functions require the same parameter simultaneously or when thelogic needs a flag - for instance the deletion function, it need to know if it is a replace component operationor just a normal deletion function and bases the decision on which value the global flag parameter has.

Due to legal aspects stated by the major CAD companies, all the CAD specific code has to be public andgiven to the customer when a CAD plug-in is sold. Therefore, an additional class, CAD API class, hasbeen created. In the Bundle class, no CAD specific code is written - it just calls functions in the CAD APIclass when a CAD specific operation is needed. The functions in the CAD API class are almost withoutexceptions only one line of code and is always a direct link to a specific operation in the CAD system. Withthis partition in two classes, the company will protect the logic in the Bundle class for the public and alsofulfill the legal requirements of releasing all the CAD specific code.

Further on, each class has its own structure. In figure 7 under section 2.4.2, the class structure for a flightbooking application is illustrated, and it describes the content of a class and how classes and objects relateto each other. The configuration application has the same general structure, with classes that contain dataobject and function object and with relations between classes. Figure 19 illustrates how this structure lookslike - the content has been modified due to confidential aspects but the principal is the same. For instance, inthe configuration logic class there is a function object called "createConfiguration". This function needs dataobjects within the class, such as configuration name and number of components, but it requires data fromother classes as well - in this example the objects "componentID", "componentType" and "assemblyID" fromthe CAD class. To summarize, and without going into any confidential details, the configuration application


consists of a large amount of classes, which include function objects and data objects, and connectionsbetween related classes.

Figure 19: System structure of the configurator software, with classes and objects.Due to confidential reasons the content has been modified.

5.2 Description of functionality and functions

Following major functions have been developed and implemented in the configurator:

• Instantiation function - similar to the PowerCopy function in Catia V5

• Component deletion function

• Component replacement function

• Parameter adjustment function

• Component grouping function

These functions often share some functionality, for instance functions regarding name conventions and ref-erence management, and therefore several support functions have been developed - instead of writing thesame code over and over again in each major function. Below a selection of these are listed:

• Interactive selection of objects in the CAD model tree, for instance a parent for a component orcomponents for group creation

• Name and ID conventions

• Folder path management

• Reference management for a component, for instance choosing and storing contextual references

• Screenshot function


5.3 CAD models and parent-child relationships

The resulting CAD hierarchy of the created components can be viewed in figure 20. As of now, all classescontain only one module, but could easily be extended. As the figure explains, the configuration logic isintuitive and the designer knows in which order he or she can instantiate the components. For instance, thebeam component can only be instantiated on its parent, the wireframe and the beam reinforcement detailcan only be instantiated on the beam and so on.

Figure 20: The hierarchy of modules designed. As of now, the classes containonly one kind of module, this could however easily be changed


Examples of the how the found method can be used to configure essential modules such as corners and beamsand of how they respond to changes in the context they are placed in can be found in figure 21.

(a) The wire frame with corner and meeting modulesadded

(b) The wire frame with beams added

(c) The wire frame with corner and beam modulesadded

Figure 21: Example illustrating how the corner and beam modules can be used to construct the underlyingbeams of a raft foundation

Furthermore, figure 22 illustrates how the assembled product respond when a change, in this case a modi-fication of the upper left corner of the wire frame, is done. Even though it is not evident in the figure, thelengths of the beams have been adjusted automatically, as well as the distance to the point where the axesintersect having been automatically adjusted to fit the new shape of the corner module.


(a) Beam and corner modules instanti-ated at a perpendicular corner

(b) The same configuration where a mor-phological change has been applied to thewire frame

Figure 22: Example of how the beam, corner and reinforcement modules look when instantiated together,and how the modules react to a change in the context.


6 Discussion

After performing a thesis, there are many aspects and fields that can be discussed. Has relevant theorybeen included or should we have been covered other fields? Have we chosen the right methods for this kindof development project? In this chapter, these aspects are discussed, together with the result - the actualconfigurator software. Further on, two other central aspects have been highlighted; how suitable context-based 3D configuration is within the construction industry and how the usage of design automation andexternal object-oriented programming tools can improve the process of designing a product.

6.1 Theory

The theoretical study is divided into three categories; Computer-Aided Design (CAD), design automationand object-oriented programming. The reason of this choice was simple, the project was about developinga CAD configuration software with many design automation features and in order to succeed with that, weneeded to use an object-oriented programming tool.

It could be argued that we did not include theory about construction design methodology and guidelines,but the fact is that we have developed a software that is not aimed to suit just construction products butall kinds of products. Since the construction company involved in the case study was most interested in howto configure their products, and not construction specific issues such as creations of building drawings, themembers concluded that such a study would be outside of the delimitation.

The study of object-oriented programming was, on the other hand, an obvious choice. Before this thesiswe had very little experience about the subject and it was a huge part of the development work of theconfiguration software. Especially how to work with classes and objects was something we needed moreknowledge about, as well as COM automation and how to use a knowledge base in the system.

Initially, a theoretical study within configuration development and strategies was performed. After a whilethough, we realized that we were not going to be involved in this kind of high-level decisions - the configurationlogic was already developed and the strategies were set, we were only up to develop the software to makethe configurator compatible for SolidWorks and construction products. Therefore, this part of the theorychapter has been removed.

6.2 Method

Since we have performed a software development project, an agile development method was a very suitablechoice. A major reason is that many changes happen in this kind of project, the customer might change oradd requirements and technology uncertainty might also lead to changes in the initial plan. Therefore, anagile approach with vague long-term planning and short adoption time when requirement changes appear wascrucial in this project. A more plan-driven approach, where basically the entire project is getting plannedin detail in the initial phase, would have made the development process very rigid. As a matter of fact, therequirement specification has been modified several times during the project due to changed customer needsand unexpected technical issues in the CAD system, and thanks to the choice of agile method, the adoptionof the changed circumstances has gone relatively fast.

The choice of which agile method that has been used can be argued, though. Why did we choose Scrum asmethod? One big factor was definitively the perspicuous structure, with working sprints divided into userstories and user stories divided into concrete tasks. The concept of using user stories for defining the requiredfeatured was also something we appreciated much. It gave an understanding of why the feature was neededand for whom it was developed - which in many cases was us in order to be able to create an actual program


feature. As said, the tasks related to the user stories were very concrete, which helped a lot, and the way ofexecuting task by task to fulfill a user story was methodical and easy to grasp.

Another agile method that we considered to use was Feature-driven development(FDD), which is very similarto Scrum in several aspects. It also breaks down a big problem into a list of graspable parts that should besolved in a short period of time - equal to a sprint in Scrum, has vague long-time planning and includes theentire software development cycle when developing a feature. In FDD, the required features also get definedin a manner that includes for whom it is developed and not only what kind of issue the feature should solve- just like with Scrum. The bottom line is that we could have chosen either of them since their are so equal,but we thought the whole method structure of Scrum was more clear and therefore we decided to work withthat one.

6.3 Result: The configuration software

First of all, we have not reached as far as we hoped and planned before the project launch. The reasonis almost entirely that the CAD system used in this project, SolidWorks, does not have an instantiationfunction. As mentioned in the execution chapter, Catia V5 has a function called PowerCopy and CreoElements has the User Defined Feature, which are both used for instantiation operations. Since SolidWorksmisses that functionality, we had to spend a lot of time developing our own instantiation function, whichlead to us not have time to develop functionality for creation of drawings.

With that said, the result of the developed configuration software has been satisfactory. The instantiationfunction included many operations, especially to make the reference management generic and work for allkinds of scenarios, and has now sufficient functionality for this type of case. The instantiation function, asit is written now, relies on creating external references between parts, and to our knowledge that is onlypossible with axes and planes. While this might sound incredibly limiting, we have managed to create severaluseful modules with such simple references since it is often possible to construct the needed features throughoperations such as intersect, project and other similar functions.

The other functions stated in the requirement specification, except the functionality of generating drawings,have been fully developed and work well.

Even though the construction consultancy company is actually selling drawings, they expressed that thebiggest bottleneck, the most time-consuming operation in the CAD process, was to create configurableCAD models and enable efficient configuration of them. Thanks to their long experience of creating drawingmaterial, operations such as creating a drawing, adding dimensions to it and other related actions are alreadyefficient. Therefore, the focus in this project has been on the 3D CAD configuration logic and the creationof smart, configurable CAD models.

Another thing that we aimed to do, but did not have enough time, was to create superclasses of the com-ponents. The concept is described in section 2.4.3 but briefly, a superclass is a class containing subclasses,which inherits the features of the superclass. In our case, a superclass could be a corner module for the housefoundation. The superclass gets created with all needed features, such as important references to connectthe component to a context, dimension parameters and topological parameters. If the designer wants fourdifferent corner modules in the component library, he or she does not need to define all these features for eachmodule, instead the modules inherit the features from the superclass. This concept could be very useful ifyou have several different variants of each single component class, therefore it would have been implementedin the configuration software if we had more time. Inheritance and superclasses are widely spread withinobject-oriented programming and and we believe it could be very useful in 3D CAD configuration as well.


6.4 Context-based 3D CAD configuration within the construction industry

In this section, the level of design automation is discussed. As described in section 2.2.1, the two highest levelsof automation are Associative Generic Instantiation (Context-based) and Generic Instantiation (Parametric)and these who have been highlighted and compared here. Further on, the discussion includes the suitabilityof this kind of methodology for a construction company.

6.4.1 Benefits

The most beneficial aspect of using context-based 3D configuration - instead of, for instance, parametricconfiguration - is that almost no extra work is needed when the original design is changed. And thesechanges are very common in the construction industry, often related to modification in the building permits.If the designer has completed all the drawing material and a change in design appears, he or she needs toupdate all the material. In the traditional approach, where most of the work is conducted in 2D CAD,many manual operations are required and in worst case the designer has to start from scratch again. Withparametric configuration, the need of extra work when the design has been changed is much lower but thisapproach also requires some manual operations in order to update the model and the drawing material. Thedimension parameters of the changed components have to been adjusted manually and additionally, thesecomponents might affect other components - which in this case also need to be adjusted. In the context-based approach, the components in the construction are linked to the context, which here is the threadmodel. So, if the thread model has been modified due to changes in the building permits or other reasons,the components will automatically be updated to fit the new context. An example of this is illustrated anddescribed in figure 22.

6.4.2 Usage for the construction company

The start-up company often advertise their product as a tool that speeds up the process of generating CADmodels. Modeling taking a long time is however not the main concern identified by the construction company.The most beneficial features of configurators identified by them are instead that the use of them makes theentire process of going from specification to product more strictly defined, thus minimizing the risk of issuessuch as communication mistakes or incompatible methods of working. A strictly defined work process shouldalso decrease the need of discussions of how to tackle a new problem and facilitate the handover of tasksfrom more experienced or qualified employees to newer or less qualified ones which is vital in creating anefficient company structure. A good example of how that could be done in the examined case would be anexperienced constructor taking the architect drawing and creating the wire-frame. The constructor couldthen hand this frame to a less experienced colleague for him or her to instantiate parts and create a drawing.

The construction company currently uses configuration software from a competitor to the start up companyand has managed to help several customers within it’s parent company to work more efficiently by providingthem with configurable modules and more defined methods of working. If the company where to acquire alicense of the CAD software company’s product, the direct benefits would be the ones described above insection 6.4.1.

6.5 Using design automation and object-oriented programming in the designprocess of a product

This section highlights in general how and what for object-oriented programming and design automationcan be used in the process of designing a physical product. The case study has been performed with focuson construction products, but here the scope is wider.


6.5.1 COM automation and object-oriented programming

In most cases, it is possible to create a design automation system without linking the CAD software toan external programming tool - the CAD system often have built in programming interfaces for creatingparametric relations and design rules. However, the functionality is limited. First of all, a programmingtool is obviously primarily designed to enable efficient programming, a CAD system is not. If the designautomation system exists in a large context - like in this project, with elements such as user interface,knowledge base and many other operations, the functionality in a CAD system is simply not sufficient. Inthe object-oriented language used in this project, VB.NET, it is easy to set up a connection to a CAD systemand when that is done, almost all operations in the CAD system can be controlled and adjusted by scriptsin VB.NET. From VB.NET, also connection to a knowledge base can be set up, a user interface can bedesigned and linked to the CAD operations, and many other related services can be controlled from there.Thanks to the system with classes and objects, such as functions and global parameters, described in section2.4.2, many objects can be re-used and all the major elements (User interface, Knowledge base connection,CAD operations etc.) can be categorized in different classes in a very structural way.

Another major advantage of using an external programming tool like Visual Studio together with an object-oriented language like VB.NET is the debugging functionality. For a programmer, it is widely known thatpractically nothing works the first time. The code has to be tested, adjusted, re-tested and it is often aiterative process to create a function that works. Therefore, it is crucial to debug the code in an efficientway, to systematically trace the code for errors. In a CAD system, the programming tool is comparable toa text editor. If the code works, it works. But if it does not, you will most likely not get a hint on whatis wrong. In a best case scenario, the program tells you in which line of the code the error has occurred,but that is basically it. In VB.NET on the other hand, you will always get information about where theerror is located, what the error is about and also possible solutions of the error. You can also debug thecode by stepping it line by line and thus see what is happening in the CAD system and the programmingobjects in each step. For instance, when a variable object has been created in VB.NET, representing adimension parameter in the CAD system, it can be controlled that the variable actually has got the rightvalue, by debugging line by line. When using loops and different conditions in the code, it simply goes wrongoccasionally and when using a real programming tool - and not the one integrated in the CAD system - youget full control over your developed functions.

6.5.2 CAD modeling that enables configuration

At a relatively early stage the authors concluded that the CAD software Solidworks is not really designedfor the kind of automation that was attempted, yet a result was achieved. This is mostly accredited to thewritten code, but a large enabler has been the rather special method of modeling described in section 4.2.11i.e starting every model by creating a placeholder for the references that will be used. The idea behind themethod was to imitate the way other CAD programs such as CATIA work and even though a significantamount of time has been spent reading scientific articles and less regulated sources such as the Solidworksforums, the authors have not found references to others working in this exact way.

This could pose a problem in teaching a customer how to create suitable modules themselves and we find itlikely that the start-up company would have to incorporate some form of consultancy service if the softwareis to be sold commercially.

6.5.3 Re-use of objects and models

When creating the modules, we aimed at creating simple geometries which are easy to make more compli-cated. The beam module for example could easily be modified to have completely different cross sections


without loosing any of its functionality. This means that the created modules should be reusable to a largeextent.

In general we believe much can be gained from applying a design philosophy where the process starts bydeciding on what to use a references, which logic should be included and how the module should interactwith other modules before creating any type of solid geometry. In that way, the design becomes more strictlydefined, and significant amounts of work can be saved.

6.5.4 The chosen configuration method

As described in section 4.2.10, the method developed by the start up-company had to be used in a differentway in order to achieve a satisfactory result. Initially we did not want to turn to this method, but afterdiscussions we concluded that the initial worries where unmotivated if the problem is viewed in a largercontext. The task of creating a wire-frame of the construction can be viewed as documenting the engineeringchoice of which parts of the construction is to carry the loads. Additionally, the creation of the selectionsets can bee seen as corresponding to making the conscious choices which have previously been made in theconfiguration stage since all beams could be instantiated automatically if an option such as "Instantiate onall references" existed in the configurator. In other words, the chosen approach can be viewed as using theapproach taken in previous cases backwards.

The authors consider the need to find a new way of working one of the most interesting challenges of thethesis as it exposes a gap in the developed methods that has only been seen in special cases before. Thiscould be viewed as a weakness, but if the configurator logic was modified to work "both ways", the authorsthink a more general and competitive tool would be achieved. It would however be important to investigateif the problem could have been solved with the existing logic, and to identify if similar issues arise in otherpotential market segments.

The most vital functions which the authors identify as missing from the configurator in order to be able toefficiently work "Backwards" are:

• A function which allows the user to automatically instantiate a given part on all places where referencesfor it exist.

• A function in which the user can automatically create new sets of references for existing modules in anewly created top-level part.

The first of these functions is interesting for many configuration application, but in the case of the backwardsmethod, the authors consider it crucial since the same work would often have to be performed twice withoutit.

The second function would not be necessary, but if designed right, such a function would automate a taskwhich likely would seem very strange to a new user, make it more intuitive as well as remove error proneactivities such as entering text. Just as the first function, it would also have applications for the originalmethod where it could be used to assist users in setting up references when creating new classes of modules.

6.5.5 Risks and benefits

First of all, using object-oriented programming and implementing design automation in the design processis initially a time-consuming approach. Based on which level and scope of automation, the required timevaries but in most cases this approach includes operations that are normally outside of the designer’s areaof knowledge. With this said, using object-oriented programming and design automation in the productdevelopment process has a huge potential of cutting lead-time in the longer run. Once a design automationsystem, for instance the 3D CAD configuration software developed in this project, is implemented andestablished in the organization, the efficiency of the design process might be much enhanced. The system


can solve several repetitive and time-consuming operations that previously were performed by the designer.One example is to configure different components to a product. Without the design automation system,the designer has to insert component by component into the assembly in the CAD tool and assemble thecomponents with each other using mates and constraints. If the designer want to replace a component, forinstance from mechanical to electrical brakes in a car, he or she needs to delete the old component withincluded mates and constraints and then insert the new component - and create new mates and constraints.Additionally, the replaced component might be parent to other components, which also need to be re-referred.This is an issue many CAD designers have faced and is also an issue that can be solved by implementingdesign automation in the process. In this project, several operations mentioned in this example have beenautomated:

• Instead of creating mates and constraints when assembling the components, these automatically getreferred to the context and do not affect other components

• When replacing a component, the designer only needs to select the component in the CAD tool andchoose the replacement component in the database. The new component will automatically adopt theold component’s references and therefore there is no need of creating new mates and re-refer.

So, many manual and repetitive operations can be automated and a lot of time can be saved, but it is kindof technology free from all sorts of potential problems? The answer is no. One of the biggest risks is thatto much gets automated, that every single operation in the CAD system is controlled by a script. If toomuch is automated, the system will be very rigid and it will limit the freedom of action regarding coming upwith creative solutions. One must consider what is suitable to automate, which operations can be executedin a better way with help of automation. Pure routine tasks, that will repeatedly occur - such as refer acomponent to a reference entity in the context - are perfectly suitable for automation, but tasks that demandcreativity and are not similar from case to case are probably not. To automate to much might also lead toa very complex system with a complicated and unclear structure.

Another risk is that the present way of modeling in CAD will be insufficient. This kind of performingthe design process, to implement automation features and basically let the computer to do the work, makesdemands on how to model the CAD geometry. A component, such as a corner module for a house foundation,must be designed in a way that it can be used on generic level. It has to fit in the context, despite how thecontext looks like. For instance, the house foundation requires seven corner modules and both the angle ofthe corner and the dimensions differ in a couple of them. If you only want to have one corner module in yourcomponent library - which you probably want, though re-usage of a component is a central aspect in designautomation - and it should fit all the seven corners, you need to be thoughtful when designing the module.In this sort of case it is very important to refer the geometry correctly within the model, in order to makeit usable for all kinds of placements in the product. The bottom line is, if a company decides to implementdesign automation in their design process, they probably need to change the way of modeling the geometryin the components.

6.6 Comparative Study

At a relatively early stage, the authors chose to delimit the project to only cover topics related to designautomation and to avoid covering topics such as labor management and economy. This delimitation leadsto the comparative study becoming somewhat skewed to the authors favor.

To avoid being dishonest we want to mention that if aspects such as price and maturity of the commercialproducts used for CAD configuration are factored into the equation, the study would not look the same.


6.7 Future work

We aimed at designing the modules for the studied case to be as general as possible, some of them willhowever likely need further work and/or revision if they are to be used in new projects. An example ofsuch a task could be to add more logic to the beam module which the authors at a late stage of the projectrealized to sometimes be unable to handle cases where the wire frames morphology changes in a way thatmakes an angle change from blunt to sharp. In addition to revising modules, several new modules wouldbe needed in order to create a reusable HLCt library. Some examples of such modules includes a modulehandling transitions between parts of a foundation with differing heights, an elevator pit module and flexiblemodules used to make annotations.

A feature that we did not have time to implement in the software is superclasses, which we discussed insection 6.3. A future study of that subject would be interesting to take part of. The usage of superclassesis common in object-oriented programming, where sub classes inherit a superclass’ features in the form ofsubfunctions that inherit parameters and other features stated in their belonging class. If superclasses ofCAD components and superclasses in programming structure can be thoroughly compared and evaluatedacademically, the concept might get a breakthrough also in CAD design.

As we discussed in section 6.4.2, another perspective of CAD configuration is the actual process. We havemostly investigated the technical aspects, but much can be won if the process of configurating productsin CAD gets standardized and improved. In our opinion, automating CAD configuration operations iscomparable to the automation of production lines. Yes, it is two completely different things in completelydifferent scales, but the basic concept is quite the same. Before the production got automated back in thedays, a production job required technical or crafting skills to perform. One can assume that many engineershad such a job. Nowadays, the production lines are almost exclusively automated and standardized andthanks to that, the production jobs can be performed by less qualified personnel. Therefore, the engineersdo not need to be involved in this kind of work and can focus on more problem-solving kinds of tasks.That goes for CAD engineers as well - if the configuration process is standardized and easy to perform,less qualified persons can do it instead and the CAD engineer’s creativity potential can be utilized in alarger scale. Based on these arguments, it would be very interesting if the process standardization for CADconfiguration got covered in a future study.


7 Conclusions

SolidWorks is not as powerful as the competing CAD software Catia V5 and the lack of an integratedinstantiation function - which is crucial when a component should inherit the references of a context -makes it less suitable for context-based 3D CAD configuration. After the authors developed an instantiationfunction though, it was possible to re-create the context-based configuration functionality. The thesis alsoincluded the creation of conceptual CAD models, representing components in a house foundation for theconstruction company, in order to validate how well 3D CAD configuration with the tool developed by thestart-up company could work for them. The conclusion drawn was that in order to be able configure theinvestigated products, the methods used in previous cases had to be modified drastically and that in orderto be able to work efficiently with the new method, more functionality is needed in the configurator. Theproduct can be configured with the existing configurator, but the process requires significant amounts oftedious manual work.

If these methods where to be implemented however, the results would be positive. The developed softwarealong with the new method enabled the creation of flexible models, on top of this, time-saving featuressuch as change part and create component group functionality is included. With this tool, the designer cancreate a configuration of a house foundation in the first place, and if changes appear, for instance relatedto the building permits, it is easy to make modifications in the design. The designer can therefore focuson tasks that require more creativity, instead of on repetitive operations such as manually add, change ordelete relations between components in the model. The key to almost all configuration operations is designautomation.

Design automation can come in several different shapes but in this case the focus has been on topologicalinstantiation with automatic morphological adaption as well as morphological parameterization. If thesetwo methods are used, many time-consuming operations in the CAD modeling process, such as defining andadjusting the shape of a component, defining and adjusting the type and amount of components and wherein the context to place them, can be either controlled by a user interface or be performed automaticallythrough incorporated design rules and reactions.

In order to enable design automation and 3D CAD configuration of products, two central areas are beneficialto incorporate; COM automation and object-oriented programming. Usage of COM automation, whichbasically is to control automation objects such as SolidWorks via scripts in external programming tools,gives major advantages in several ways. Most significantly a programming tool is obviously designed toenable proper programming functionality, while a CAD tool mainly focuses on product design and whereprogramming is a additional feature. A programming tool handles code structure, code libraries, debuggingand testing of the code much better than a CAD tool and is most likely more intuitive to use. Thereforean integration of an external programming tool could be very beneficial when developing complex productswith many dependencies. Regarding the programming tool, this project has been performed with an object-oriented programming language. No other types have been investigated, but the object orientation suitsdesign automation and CAD configuration very well. Especially the perspicuous structure with classes thathave clear responsibilities - for instance one class for the user interface, one for the connection to the database,one for CAD operations and so on - makes the development work intuitive. It is also very efficient sinceobjects in the class can inherit the class features, and therefore objects such as functions and parameterscan be re-used and the amount of code can be reduced.


References

[Chaudhary et al., 2002] Chaudhary, R., Goel, T., and (Corporation), N. (2002). VBA professional projects.Premier Press, [Rocklin, Calif.].

[Clark, 2006] Clark, D. (2006). Beginning object-oriented programming with VB 2005 : from novice toprofessional.

[Craig, 2007] Craig, I. (2007). Object-oriented programming languages : interpretation. Springer, London.

[Hazzan and Dubinsky, 2014] Hazzan, O. and Dubinsky, Y. (2014). The Agile Manifesto. Agile Anywhere,page 9.

[Jiang et al., 2013] Jiang, J., Chen, Z., and He, K. (2013). A feature-based method of rapidly detectingglobal exact symmetries in CAD models. CAD Computer Aided Design, 45(8-9):1081–1094.

[Junfeng et al., 2013] Junfeng, J., Zhengming, C., and Kunjin, H. (2013). Construction of Parent-child Re-lationships among the Topological Elements in Feature-based CAD Models. JOURNAL OF COMPUTERAIDED DESIGN AND COMPUTER GRAPHICS, 25(3):417–424.

[Ledermann et al., 2005] Ledermann, C., Hanske, C., Ermanni, P., and Kelm, R. (2005). Associative para-metric CAE methods in the aircraft pre-design. 9:641–651.

[Mäntylä, 1990] Mäntylä, M. (1990). A modeling system for top-down design of assembled products.

[Meyer-Stabley, 2014] Meyer-Stabley, B. (2014). Agile! : the good, the hype and the ugly.

[Myung and Han, 2001] Myung, S. and Han, S. (2001). Knowledge-based parametric design of mechanicalproducts based on configuration design method. Expert Systems With Applications, 21:99–107.

[Pillay, 2007] Pillay, A. (2007). Object-Oriented Programming. School of Computer Science University ofKwaZulu-Natal, page 221.

[Rocca, 2012] Rocca, G. L. (2012). Knowledge based engineering: Between AI and CAD. Review of alanguage based technology to support engineering design. Advanced Engineering Informatics, 26(2):159–179.

[Tarkian, 2012] Tarkian, M. (2012). Design Automation for Multidisciplinary Optimization A High LevelCAD Template Approach.

[Tomiyama, 2007] Tomiyama, T. (2007). Intelligent computer-aided design systems: Past 20 years andfuture 20 years. Ai Edam, 21(01):27–29.

[Wang et al., 2006] Wang, Q.-H., Li, J.-R., and Gong, H.-Q. (2006). A CAD-linked virtual assembly envi-ronment. International Journal of Production Research, 44(3):467–486.

[Willis et al., 2004] Willis, T., Crossland, J., and Blair, R. D. (2004). Beginning VB.NET 2003. Wiley Pub.,Indianapolis.

[Wu, 2009] Wu, C. (2009). An Introduction to object-oriented programming with Java TM. Vasa.


Documents

Context -based 3D CAD configuration using object ... · 1 Introduction This is a master thesis in the ﬁeld design automation and 3D CAD conﬁguration at the Department of ManagementandEngineeringatLinköpingUniversity