See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/301376475

Towards a Knowledge-Based Engineering Methodology for Construction

Conference Paper · September 2015

DOI: 10.1061/9780784479377.001

CITATIONS READS

2 640

1 author:

Marcus Sandberg
Luleå University of Technology
36 PUBLICATIONS   238 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

METOPIA - Methodology for Optimization, Integration and Automatization View project

All content following this page was uploaded by Marcus Sandberg on 11 October 2016.

The user has requested enhancement of the downloaded file.

 Towards a knowledge-based
engineering methodology for
construction

Marcus SANDBERG

Ph.D. Associate Senior Lecturer, Department of Civil, Environmental and Natural

Resources Engineering, Luleå University of Technology, Luleå, Sweden, P H (46)
920-493072, FAX (46) 920 49 13 99, Email: marcus.sandberg@ltu.se

ABSTRACT

The increasing industrialization and standardization of construction

opens up for the field of design automation, and possibilities to work with
several what-if-conditions and several product candidates instead of just one or
two during design. Design automation applications for building component and
infrastructural part design are starting to appear using software from the
manufacturing industry. A challenge is however to develop such construction
design automation applications since comprehensive methodologies are
missing. MOKA is a methodology for developing knowledge-based engineering
(KBE) applications originating from the aerospace and automotive industries.
KBE is a label for computer-based automation of routine design tasks. This
paper describes methodologies for developing design automation applications in
construction, compares these with the MOKA methodology and discusses the
opportunities and challenges of having a KBE methodology for construction.

INTRODUCTION

Some of the most important decisions are taken during construction

design as these decisions directly impact producibility or buildability. These
decisions depend extensively on design team experience, an experience that too
seldom is available to other engineers, as experienced people are busy with little
time to share their knowledge or these engineers get promoted and change
positions or project. Design automation applications can show the design
change impact on e.g. cost, equipment availability, staff capabilities and
buildability and also help designers reuse successful solutions from earlier work
instead of reinventing the wheel for every project. Thanks to automation it
becomes easier to generate several solutions and trying different what-if-
conditions than when done manually. An issue is that many construction
companies are not aware of the potential of design automation. Within the
manufacturing industry a lot of work has been done to develop design
automation applications see e.g. Verhagen et al. (2012). The term knowledge-
based engineering (KBE), has become a label for automating routine design
work within the manufacturing industry. It is named ‘knowledge-based’ because

1
knowledge from engineers is captured, formalized and implemented into a
computer-based design automation application. Typically design automation
applications feature both fully automated tasks as well as semi-automated tasks
that require user-interaction and often feature computer aided design and
engineering systems. Stokes defines KBE as ‘the use of advanced software
techniques to capture and re-use product and process knowledge in an
integrated way’ (2001). Automating chains of engineering activities is not new;
this has been used by engineers since the early developments of computer-aided
modelling and simulation (Dixon, 1995; Begg, 1984). Examples of KBE
applications from the latest decades are e.g., (Chapman and Pinfold, 1999;
Sandberg et al. 2005; La Rocca, 2012).
Examples of KBE-like design automation applications have started to
emerge within construction e.g. (Jensen et al., 2012; Sandberg et al., 2008), but
a comprehensive methodology for design automation application development
is absent within construction. Such methodology should be hands-on and
describe how to choose tasks to automate, how to capture knowledge, formalize
knowledge and implement the knowledge in a computer software. This makes it
hard for companies to know what tool to develop and how to develop it,
especially for companies with little or no experience in design automation, apart
from the usual hinder for change which is that most companies are too busy
with their everyday tasks. Additionally for researchers it is hard to reproduce
research and build on ideas due to lack of details in the papers regarding how
the design automation application was created.
For KBE applications development, MOKA (Methodology and software
tools Oriented to Knowledge based engineering Applications) is one of the more
comprehensive methodologies, (Stokes, 2001). A related methodology is
CommonKADS that focus knowledge-based systems development (de Hoog et
al., 1994) which is more general and sometimes more artificial intelligence
related applications. KBE applications usually have geometry, configuration
and engineering knowledge, (Lovett et al., 2000).
Since there are differences between the construction industry and the
manufacturing industry in terms of e.g. less process focus, less level of
digitalization, less standardization, MOKA cannot directly be adopted since this
methodology focuses how to support repetitive and routine design work which
requires high level of industrialization and standardization. This paper describes
methodologies and approaches for KBE and design automation within the
manufacturing industry and the construction industry, analyses these approaches
and discusses opportunities and challenges for increased use of KBE within the
construction industry.

METHODOLOGIES AND APPROACHES FOR DEVELOPING KNOWLEDGE-

BASED ENGINEERING AND DESIGN AUTOMATION APPLICATIONS

MOKA. MOKA is the most comprehensive methodology for KBE application

development although other less detailed methodologies exist, e.g. (Lovett et
al., 2000). The focus of MOKA is to describe how to capture engineering

2
knowledge and implement it into a KBE application (Stokes, 2001). It was
developed to aid Europe to catch up with the USA and the Far East regarding
KBE applications for mechanical design. MOKA contains six phases which are
shown in Figure 1. CAPTURE and FORMALIZE are the most elaborated
phases although the other phases also are explained.

IDENTIFY

ACTIVATE JUSTIFY

PACKAGE CAPTURE

FORMALIZE

Figure 1. The MOKA phases, adapted from Stokes (2001).

IDENTIFY determines objectives, scope and a concept level technical

specification for the design automation application. JUSTIFY examines
commercial, cultural and technical risks. CAPTURE collects the raw knowledge
and structures it into the Informal Model. FORMALIZE translates the Informal
Model into the Formal Model. PACKAGE involves translating the MOKA
Formal Model into code for a KBE application. ACTIVATE involves
distribution, installation and use.
In the CAPTURE part ICARE (Illustration, Constraint, Activity, Rule,
Entity) forms are used to document engineering knowledge. A special
developed modeling language, the MOKA Modelling Language is used to
FORMALIZE the captured knowledge.

Approaches used in construction. Here the approaches used to develop a

number of design automation applications in construction are described.
Jensen et al. have developed a floor-slab application and argue that
manufacturing CAD software can be used for design automation within the
construction industry (2012). The approach used for the application
development is described as: Firstly a multi-skilled engineering team was
assembled that together with a building manufacturer defined constraints and
requirements for the building system. Secondly a modular system was
developed based on the constraints and requirements. Design rules was defined

3
and implemented into a floor-slab application. Lastly the application was
evaluated by undergraduate students.
Sandberg et al. presented a support tool for stair and structural floor
design and used a development approach that started with choosing a design
scenario and tool functionality, acquiring knowledge, formalizing the
knowledge into rules and implementing the rules into an application, (2008).
A decision support system for concrete building design method selection
has been reported by Chen et al. (2010). The support system was developed
according to the following approach: Firstly interviews with clients, developers,
engineers, contractors and precasters were done to collect data about how they
make decisions. Secondly this data was verified and formalized into
relationships that could be used to select method for concrete building design.
Artificial intelligence has also been used to develop decision support in
construction, e.g. Kaklauskas who presented an application for choice of
windows (2007). Firstly other decision support systems were analyzed which
guided the development of the presented decision support system that consists
of a database, database management system, model-base, and model-base
management system and user interface. The system was then tested for
usefulness.
Cheng et al. report on a tool for decision-making and assessment of
high-rise building systems (2008). Firstly the implicit decision-making
procedure was documented and therefore made more explicit. Secondly the
procedure was assessed and verified.
Attia et al. present a support tool for early design of zero-energy
buildings (2012). First barriers, requirements and expectations were identified
and then a tool was developed to meet these. The tool was then tested twice for
validity and usability respectively.
SEMPER II is an internet-based performance simulation tool for early
building design, (Lam et al., 2004). The tool is described extensively but the
approach or methodology used for its development is neglected rather saying
that it was developed using a bottom-up approach.

Overarching methods and principles for construction. Some papers suggest more
overarching frameworks for IT (information technology) implementation. As
part of their change management, Henderson and Ruikar suggest how to
overcome construction-specific factors that influence technology
implementation in construction, (2010). They suggest, among others, being
clearer about expected outcomes of the IT implementations as well as having
continuous communication, training and education in the organization.
Miozzo et al. presents an IT-enabled process strategy for construction
(1998). In their framework they analyze a generic construction process and
couples design process problems with suitable IT support.
Stewart et al. presents a strategic implementation framework for
information technology and information systems (IS) projects to increase the
digitalization of construction (2002). The framework contains of a six step
process: 1) SWOT factors, 2) SWOT analysis, 3) IT/IS (IS-information system)

4
diffusion strategy ‘story telling’ 4) operational strategy, 5) implementation
strategy ‘action plans’, 6) monitoring plan.
Li outline success factors for knowledge-based support tools namely:
User involvement (e.g. support tool project initiation, user interface design),
problem difficulty (e.g. availability of expertise for the construction problem),
developer’s skill (e.g. ability to extract knowledge from construction experts),
shell characteristics (e.g. flexibility, usefulness) and management support (e.g.
commitment, encouragement from management to use support tools,
appropriate financial resources) (1997).

COMPARISON WITH MOKA

As seen in the previous section design automation application papers

rather focus on the resulting tool rather than the approach used during the
application development. The approach is often mentioned too briefly to be of
any use for repetition of the research or for guidance of industries that need
applications to be developed. The reviewed design automation papers from
construction are compared with each MOKA phase.

Identify. Parts of this phase are mentioned by Attia et al. (2012), Jensen et al.
(2012) and Stewart et al. (2002) although it is unclear how much focus lies on
stating clear business objectives, checking whether knowledge, needed for the
application, already exist and briefly how it could be captured, checking what
software and hardware that exist for the possible application and evaluating if
design automation is suitable at all. Sometimes the knowledge changes rapidly,
domain experts disagree on key points, experts are unable or unwilling to
describe their product or process knowledge, knowledge is vague and decision
are made in a subjective way why design automation is not suitable, (Stokes,
2001). This is particularly important for construction since the activities can be
unstructured and done in different ways for each project.

Justify. The Justify phase cannot be found at all in the cited references
although estimating the resources needed for implementation as well as
creating a plan probably have been done. One important part of Justify is to
gain managerial acceptance for the design automation application as well as
defining criteria for how to assess success or failure of the application. This
can imply measuring the current time it takes to perform the design task
manually.

Capture. Acquiring knowledge for the application is described, although

briefly, by several. Chen et al. (2010) mention interviews, Cheng et al. (2008)
documentation of procedures, and Sandberg et al. (2008) knowledge
acquisition. More details than that are not mentioned. Here MOKA offers
ICARE forms to collect your knowledge into what represents a so called

5
informal model. Here more forms or modification to the forms could be needed
to work better for construction. However, using the five current forms may be
enough time-demanding.

Formalize. Tasks that relate to the Formalize phase is formalization into

relationships (Cheng et al., 2008), development of modular system (Jensen et
al., 2012) and rule definition (Sandberg et al., 2008) but no further details are
described in the papers. This part is supported by the MOKA modeling
language which is used to transform the informal model into the formal model.

Package. Jensen et al. (2012) and Sandberg et al. (2008) implemented the
design rules into an application. But then again, the details are not described.
This phase is also very dependent on the chosen software and hardware system.

Activate. This phase includes finding debugs and enhancements of the

application. Attia et al. (2012), Jensen et al. (2012) and Kaklauskas (2007)
briefly mention test or evaluation as part of their application development
process.

CHALLENGES AND OPPORTUNITIES FOR A KBE METHODOLOGY FOR

CONSTRUCTION

The papers that were compared to MOKA partly had some similarities
although the papers had little details regarding method used to develop the
applications. Experienced researchers in the KBE and design automation field
usually have developed their own more or less systematic approaches to create
applications. A first step is for them and every researcher in this field to shift
focus slightly from the structure and performance of the applications to start
describing more details about how the applications were developed. This could
create input to a bottom-up development of a methodology. The research field
would also benefit from more details because this would make reuse and
building on previous research much easier. Reuse is seldom described in
literature but techniques and methods of the presented applications often seem
to overlap. Also sharing code is important for making reuse easier.
Since KBE is most suitable for standardized routine work, MOKA
probably works for construction design tasks that fulfill that plus the other
requirements such as knowledge availability, organizational readiness, hardware
and software availability. But before this can be stated, MOKA needs to be
tested for several design automation application development within
construction. Also doing a larger literature survey listing current approaches
used, is needed.
Will a generic methodology be used by researchers and companies? This
is an important issue, especially since the construction industry is known for
being slow to embrace innovative IT/IS applications, (Stewart et al., 2002).
However there are ideas to overcome obstacles related to IT changes in

6
construction, (Miozzo et al. 1998). One important part is to involve the future
users in the development and implementation phase of the application. This
could mitigate the fear of uncertainty and the resistance to change, (Henderson
and Ruikar, 2010).
It is hard to create a generic and detailed methodology that works for
everything. One idea is to enable every field of construction to have their own
specialization; buildings, roads, bridges etc. Also the level of standardization
and industrialization may need different specializations. A methodology could
have overarching parts that are shared between the specializations. The
overarching parts could help companies to start develop their own design
automation applications and the more experienced they become, the higher is
the possibility for companies to create their own specializations.

CONCLUSION

There is a need for a comprehensive methodology for developing KBE

(design automation) applications for construction. This would help companies
to create KBE applications but also help researchers to reuse other researcher’s
results. Current design automation research focus too much on the application
itself rather than describing the way the application was developed. Approaches
used are for a number of design automation research papers within construction
are compared with MOKA, which is a methodology for KBE application
development from the manufacturing industry. Results show that there are
similarities although it is hard to compare due to the lack of details in the
papers. This paper suggests trying MOKA for a several design automation
projects in construction to find out how well this methodology works. Also all
future researchers writing about design automation applications in construction
are encouraged to write more about how their applications were developed.
Then we can start collect approaches and modify MOKA into a useful
methodology for construction.

REFERENCES

Attia, S., Gratia, E., de Herde, A. and Hensen, J.L.M. (2012) Simulation-based
decision support tool for early stages of zero-energy building design, Energy
and Buildings, Online publication, Elsevier Science Direct.
Begg, V., (1984) Developing Expert CAD Systems. Koga Page, London.
Chapman, C. B. and Pinfold, M. (1999) “Design engineering - a need to rethink the
solution using knowledge based engineering”. Knowledge-Based Systems
12: 257-267.
Cheng, C.L., He, K.C. and Yen, C.J. (2008) Decision-making and assessment tool
for design and construction of high-rise building drainage systems,
Automation in Construction, 17(8): 897-906.
Chen, Y., Okudan, G.E. and Riley, D.R. (2010) Decision support for construction
method selection in concrete buildings: Prefabrication adoption and
optimization, Automation in Construction, 19(6): 665-675.

7
 Dixon, J.R., (1995) Knowledge-Based Systems for Design. Journal of Mechanical
Design, 117: 11-16.
de Hoog, R., Martil, R., Wielinga, B., Taylor, R., Bright, C. and van de Velde, W.
(1994) The CommonKADS model set, Report, University of Amsterdam
Henderson, J.R. and Ruikar, K. (2010) Technology implementation strategies for
construction organisations, Engineering, Consctruction and Architectural
Management, 17(3): 309-327.
Jensen, P., Olofsson, T. and Johsson, H. (2012) Configuration through the
parameterization of building components, Automation in Construction, 23: 1-
8.
Kaklauskas, A., Zavadskas, E.K. and Trinkunas, V. (2007) A multiple criteria
decision support on-line system for construction, Engineering Applications
of Artificial Intelligence, 20(2): 163-175.
Lam, K.P., Wong, N.H., Mahdavi, A., Chan, K.K., Kang, Z. and Gupta, S. (2004)
SEMPER-II: an internet-based multi-domain building performance
simulation environment for early design support, Automation in
Construction, 13(5): 651-663.
La Rocca, G. (2012) Knowledge based engineering: Between AI and CAD. Review
of a language based technology to support engineering design. Advanced
Engineering Informatics, 26: 159-179.
Li, H. (1997) Determinants of knowledge-based expert system success in
construction engineering, Building Research & Information, 25(2): 101-106.
Lovett, P.J., Ingram, A. and Bancroft, C.N. (2000) Knowledge-based engineering for
SMEs – a methodology. Journal of Materials Processing Technology, 107:
38-389.
Miozzo, M., Betts, M., Clark, A. and Grilo, A. (1998) Deriving an IT-enabled
process strategy for construction, Computers in Industry, 35: 59-75.
Sandberg, M., Boart, P., and Larsson, T., (2005) Functional product life-cycle
simulation model for cost estimation in conceptual design of jet engine
components. Concurrent Engineering: Research and Applications, 13(4):
331-342.
Sandberg, M., Johnsson, H. and Larsson, T., (2008) Knowledge-based engineering
in construction: the prefabricated timber housing case, Journal of Information
Technology in Construction, 13: 408-420.
Stewart, R.A., Mohamed, S. and Daet, R. (2002) Strategic implementation of IT/IS
projects in construction: a case study, Automation in Construction 11(6):
681-694.
Stokes, M., (2001) "Managing Engineering Knowledge - MOKA: Methodology for
Knowledge Based Engineering". ASME Press.
Verhagen, W.J.C, Bermell-Garcia, P., van Dijk, R.E.C. and Curran, R. (2012) A
critical review of Knowledge-Based Engineering: An identification of
research challenges, Advanced Engineering Informatics, 26: 5-15.

View publication stats