Content uploaded by Russell Gentry
Author content
All content in this area was uploaded by Russell Gentry on Sep 12, 2018
Content may be subject to copyright.
33rd International Symposium on Automation and Robotics in Construction (ISARC 2016)
A Process-Driven Representation Schema for Masonry Wall
Assemblies
Andrés Cavieresa, Russell Gentryb, and Charles Eastmanb
aUniversity of Oklahoma, bGeorgia Institute of Technology
E-mail: andres.cavieres@ou.edu, russell.gentry@coa.gatech.edu, charles.eastman@coa.gatech.edu
Abstract – The paper introduces a new approach for
the representation of masonry walls in Building
Information Modeling applications. The proposed
representational scheme addresses the different
types and levels of information required to support
the design and construction of masonry walls. In
particular, the paper proposes the concept of
masonry wall “region”, as a suitable abstraction to
represent the variety of view-dependent features that
characterize the life-cycle of masonry walls. At the
geometric level, a masonry region works as a
surrogate for the description of arbitrary
aggregation relations without the cost associated
with the explicit propagation of masonry units. In
this way, a higher degree of semantic expressiveness
can be achieved while keeping the design model
flexible and agile. The concept of masonry regions
motivates the formulation of a conceptual data
model as foundation upon which different masonry-
specific applications can be developed in the future,
along with the definition of model views necessary to
support masonry related data queries and exchanges.
The paper outlines the theoretical background
behind the concept of masonry regions and its
relationship with the Industry Foundation Classes
(IFC). Finally the paper introduces a proof-of-
concept implementation for a masonry wall schema,
and discusses the next steps in the research.
Keywords – BIM; Masonry; Representation; Levels
of Development; Design Process; IFC.
1 Introduction
Building design and construction processes are
being increasingly facilitated by new Building
Information Modeling (BIM) technologies. At the core
of these technologies there is a series of data models
engineered to enable the exchange of information
between different stakeholders. These data models
encapsulate and codify industry standard product
descriptions, enabling data exchange across software
platforms and from heterogeneous stakeholder
viewpoints.
In the context of a building material system such as
masonry, the conceptualization of the data model should
address the representation of more abstract features of
assemblies beyond structural aspects such as geometry
and material properties. Some of these abstract features
may be performance dependent, spatiotemporal, related
to cost, ownership, production status, etc. When a given
stakeholder viewpoint – which includes the role of the
stakeholder and the design activity in question, for
example, a structural engineering performing lateral
load analysis – is applied to a model, a domain-specific
model view needs to be derived from the source model
so to support the activity [1].
Currently, the most mature material-specific BIM
data models are for structural steel – with the early
standardization of steel shapes forming the basis for the
steel components used in buildings today [2]. Almost a
century after steel shapes were standardized, the first
computational data model for structural steel was
released as the “Logical Product Model” by CIMSteel
[3]. Since then, material-specific models for precast
concrete [4] and cast-in-place concrete [5] systems have
been developed.
The Building Information Modeling for Masonry
Initiative (BIM-M), organized in 2013 in North America,
has developed a roadmap for establishing the
requirements for masonry-specific data models, to
support design, procurement and construction of
masonry buildings [6]. The second phase of the
roadmap, recently completed, focused on the
development of data requirements for masonry units and
masonry walls. In addition, the initiative has completed
an extensive set of masonry-building case studies,
focusing on the information needs of architects,
engineers, material suppliers, and mason contractors [7].
As part of the initiative, two preliminary data models
have been proposed. The first is a data model for
Conference Topic
masonry units, which is follows the functionality of
databases of hot rolled steel shapes promulgated by
AISC and the BSI [8]. Unlike structural steel however,
the Masonry Unit Definition model or MUD is extended
to include material properties, color, and texture, in
addition to geometry. The second data model, called
Masonry Wall Definition (MWD) aims towards a
specification of masonry wall models that explicitly
capture key relationships at the assembly level. As
introduced earlier, it is important to point out that the
complexity in the representation of masonry assemblies
stems not only from the geometry of a wall and the
properties of its units, but also from more abstract
relationships that need to be formally described in order
to provide computationally support to a variety of view-
dependent tasks. In particular, one of the main
challenges is the development of a flexible
representation that could enable incremental levels of
design information, geometric or otherwise, without the
need for explicit instantiation of individual units. In this
way, more informed exploration of alternatives would
be facilitated by avoiding oversimplifications embedded
in current representational approaches, and without the
cost of excessively detailed geometric models.
The present paper focuses on the main guiding
principles of the Masonry Wall Definition data model.
Brief references to the Masonry Unit Definition (MUD)
data model will be provided when needed. More
information on the MUD model can be found on Sharif
et al. [9].
2 Masonry Wall Definition model
The problem of representing masonry walls in a
machine-readable format is considerably different than
the representation of masonry units per se. For instance,
the MUD model is internally-focused to provide
comprehensive information about units, but little
information about the context in which the units are
applied. Masonry walls on the other hand are defined
wholly by their context – the functional, engineering
and aesthetic requirements dictate the geometry of the
walls and the masonry is configured to fulfil these
requirements. The overall geometry of a given masonry
wall can be defined in terms of its start and end points,
as well as its base and top reference planes. As an
assembly however, a masonry wall can be characterized
in several different ways simultaneously. Besides the
self-evident parts such as the masonry units themselves,
and other discrete accessories, a masonry wall can also
be characterized by features such as openings,
protrusions, niches, cut-outs, indentations, inlays,
corners, etc. Furthermore, some of aspects of the
assembly may be more abstract and context-dependent.
For instance, a particular load-distribution pattern or a
special sequence of erection entails different types of
relationships. Each of these serves a specific purpose
and therefore needs to have its own set of domain-
specific properties and attributes.
The representation of these abstract and context-
dependent features in turn requires a formal definition
of modularity as well as different aggregation patterns
that are relevant for masonry construction. In this way
the model not only “looks” like a masonry wall, but
more importantly, provides a consistent source of
information regarding constructability and performance.
Currently however, the representation of masonry
modularity and aggregation patterns is limited to
bonding and coursing. Moreover, these are typically
represented in an oversimplified manner, by using a 2D
pattern or “hatch” which is applied to the surfaces of
wall objects to denote a masonry composition, but
without explicit description of abstract and context-
dependent features of the entire assembly. This
limitation not only reduces the scope of automation that
could be implemented otherwise, but affects the ability
of teams to detect conflicts in timely manner, and
ultimately, to make better design decisions.
By recognizing the importance of this problem, the
goal of the Masonry Wall Definition project is to
establish the nature of these assembly properties along
with the best methods to represent them. For that
purpose, information requirements of typical masonry
workflows identified by Lee et al. [7] were used as
starting point for the definition of those properties.
However, the iterative and incremental nature of the
design process raises a number of problems.
First, in the early stage of design, the design problem
is generally ambiguous and requirements are still ill-
defined [10, 11]. During this stage, several candidate
building shapes and geometric relationships are
explored without committing to any specific semantics
of construction or materiality. As the design process
moves-on, generic objects are replaced by more specific
ones such as walls, doors, and windows. Once masonry
is adopted as material of choice, some of these objects
have to be moved, sized or deleted from the model. At
this point the designer may have little interest in
tracking the location of specific masonry units. All that
matters is some level of coordination with an underlying
modular system that is consistent with the type of
masonry chosen.
As the design is refined, the issue of constructability
comes into play, imposing the need for more specific
information. The concept of Level of Development
(LOD) in BIM was introduced to guide the amount and
fidelity of information to be added to a building model
as design proceeds. According to the LOD Specification
[12], model elements are represented with a range of
information granularity, from the most schematic
33rd International Symposium on Automation and Robotics in Construction (ISARC 2016)
representation (LOD 100), to the most detailed (LOD
500). At the early stages of design, walls are represented
at LOD 100, without the need to indicate wall
thicknesses and material types. At some later stage in
the design process, the wall may be identified as a
masonry wall, with specific masonry units, bonding
patterns and reinforcement information. This may
correspond to a LOD 400. At this point, the global
geometry of the wall and the local geometry of masonry
units have to be resolved in various situations. In
particular, the way that masonry units relate to certain
boundary conditions of the wall needs to be represented
explicitly. This is necessary for example to calculate the
number of masonry cuts, custom units or other types of
components required to resolve special situations along
the wall (e.g. reinforcement, barriers and insulation,
etc.).
One possible method to represent such type of
conditions is the explicit propagation of masonry
components by means of algorithmic procedures and
parametric rules [13, 14]. However, this leads to a
second problem. BIM parametric applications are
known to be computationally-intensive and the
performance of any parametric-modeling software
degrades as the number of parametric elements in the
model increases, which in turn cause negative
implications in the design process itself [15]. Since it is
likely that a masonry building will have tens or even
hundreds of thousands of masonry units, plus all
relevant accessories, it is simply not efficient to model
each unit, even if the procedure is automated.
Furthermore, it is rather questionable that exhaustive
modeling of every single unit would be actually an
effective approach in supporting conventional design
workflows. From a more pragmatic point of view, the
aggregation of masonry units according to some
functional or aesthetic criteria may provide a more cost-
effective approach without losing significant precision
or expressiveness.
From these observations it became evident that a
different type of representational strategy was needed to
model masonry walls more effectively. In particular, it
became clear the need for a process-centric
representation, so that the iterative and incremental
nature of the design process could be not only supported
but promoted. This means not only that the
representation needs to be flexible enough as to support
the use of different levels of information at different
stages of the design process, but more importantly, to
support the transition between design stages and levels
of information. The need for a flexible, process-driven
design representation has been discussed extensively in
the past from different perspectives [16 - 18].
Within the context of the MWD project, the strategy
adopted was the conceptualization of a new type of
abstraction. This abstraction is intended to mediate
between the monolithic representation of masonry walls
and the exhaustive propagation of individual units. Such
an intermediate abstraction was called in the research a
masonry “region”. A masonry region is geometrically
represented by a solid object that can be created by
decomposition of larger solids – a wall or another
region – by means conventional solid modeling
operators (e.g. subtraction and intersection). From a
semantic perspective however, a region describes a
view-dependent aspect of feature of the wall assembly.
In particular, a region denotes geometrically an arbitrary
aggregation of masonry units. Such an aggregation may
include components and accessories connected or
functionally associated to the units. In prior work we
have discussed how regions may be associated to
specific stakeholders as well as with different design or
evaluation tasks. Altogether, this information
characterizes the context under which region definitions
may be created [19].
Part of the motivation behind this formulation is that
certain types of information requests between parties
could be satisfied through the derivation of regions. In
this regard, the conceptualization behind masonry
regions is consistent with the principle of targeted
interoperability within specific use case scenarios [20,
21]. In the case of masonry walls, and masonry
buildings in general, the use cases in which view-
dependent information may be requested typically
involve analysis of some sort related to structural or
energy performance evaluation, detailing, quantity take-
off, construction planning, etc.
In the remaining of the paper the main principles
behind the concept of masonry regions will be
introduced. These principles form the basis for the
Masonry Wall Definition data model under
development. The requirements for the representation of
regions within a wall are enumerated below. We
provide specific, and somewhat limiting requirements at
this time so to facilitate the implementation of an initial
proof-of-concept software application.
2.1 Masonry wall regions
An example of a brick wall with region
decomposition is shown in Figure 1. The regions are
represented as solid partitions of the wall, each implying
a specific aggregation of masonry components. As
discussed before, the criterion for the aggregation is
view dependent. In this case, boundary conditions for
window openings and corners may be necessary for the
specification of insulation and water barriers, estimation
of unit types (e.g. half-units) and sequence of erection.
Conference Topic
General definitions and rules for the decomposition of
masonry regions are the following:
1. A region is the geometric representation of an
arbitrary masonry wall feature. Masonry wall
features may be a bona fide portion of the wall
with a clear, identifiable shape and function (e.g.
an arch, a pilaster, etc.), or a fiat portion of the
wall defined according to some arbitrary criteria
(e.g. bricks to be laid by crew per day, damaged
bricks to be replaced, etc.). Masonry wall
features are discussed later in section 2.3.
2. A masonry region is bound by horizontal lines
of masonry courses. The first and last courses
are the outermost horizontal boundaries.
3. A masonry region is bound by vertical lines in
coordination with the masonry bonding pattern
and head joints. Thus, a region may contain
only full and half masonry units. When a wall in
running bond id represented at LOD 400 or
higher, the vertical boundaries are staggered
lines that follow the overlapping of the bond.
The first and last edges of a wall are the
outermost vertical boundaries.
4. The largest possible region within a wall is the
wall itself in its whole. In conjunction with the
minimal region (see definition 5), the maximal
region provides the basis for modular
coordination for a given unit type, along with
the context for which rule for boundary
conditions can be established.
5. The smallest region is the size of a half unit.
This is called the minimal region, representing
the basic module required for dimensional
coordination. In some cases, niches, recesses or
other type of feature can be depicted using a
minimal region representation.
6. The masonry within a given region must all be
laid according to a specific bonding pattern.
However, it is possible to decompose a region
further into sub-regions, which can have
different bonding patterns.
7. Regions may be rectangular, trapezoidal or
triangular, so that gables and other forms can be
represented.
8. Regions may be defined also through the
thickness of the wall, to accommodate walls
with multiple wythes of masonry.
9. Within a given region a set of rules can be
established that control the placement of
masonry-specific components, such as vertical
reinforcement, bond beams, grout, wall ties,
weeps, etc. A given rule set applies to a region,
and if the rules change, a new subdivision is
required.
Figure 2 Possible region decompositions for L-type
corner. Control joint establishes a hard boundary.
Figure 1 Decomposition of wall into regions associated to
opening and corner conditions. The window opening
region can be further decomposed into regions for the sill,
lintel and jambs.
33rd International Symposium on Automation and Robotics in Construction (ISARC 2016)
10. Parametric constraints can be associated to
regions to control their placement and the
geometric behavior of its boundaries, as well as
individual parts within the region.
11. Parametric constrains and rules may enforce
that a wall be “in-coursing” and “in-bond” in
relations to its neighbors, boundary conditions,
or other type of requirements. These rules may
include geometric tolerance criteria to adjust the
thickness of mortar joints to fit masonry units
into regions where possible.
12. Masonry wall corners at L- and T- shaped
intersections form their own type of region.
Therefore a complex sequence of walls can all
be controlled geometrically from a single
“anchor point”, from which the masonry pattern
is established. Figure 2 shows an example of an
L-type corner region.
2.2 Relationship between regions and LOD
In a design workflow certain activities can only
occur if the right type of information is available in an
appropriate format. In a BIM enabled workflow, the
information required typically involves the exchange of
only a subset of the entire model. For that reason, the
concept of Levels of Development (LOD) was
developed, in order to ensure that the required levels of
information are present in the source model to support
different design activities across different design stages.
The concept of region representation was developed
to support incremental LODs as well as the existence of
different LODs simultaneously in the same model. This
is particularly relevant for masonry, given that in some
circumstances it is necessary to model individual units
and accessories explicitly (e.g. virtual mock-ups), while
at the same time keeping a more generic description in
other areas of the model.
At LOD 100, masonry regions are very generic. By
default, only the maximal region may be defined,
coinciding with the overall geometry of the wall.
However, as soon as LOD 200 is required, the wall can
be decomposed into more specific, view-dependent
regions. For instance, the insertion of new masonry
features into a wall, such as openings, corbels, pilasters,
recesses or quoins, to name a few, are all associated to
specific forms of region decomposition. This
decomposition process is intended to be automatic,
similarly to the functionality provided in some pre-cast
concrete BIM applications (e.g. IDAT pre-cast module
for Revit) [22].
At LOD 200, each region may have associated
different masonry unit types, coursing and bonding
patterns. Also, as part of this characterization, the
behavior of the masonry at different region boundaries
must be established in a coordinated manner. Typical
examples for vertical boundaries include: “preserve
running bond with adjacent regions” and “insert half
bricks and establish control joint” (see Fig. 2).
At this point it is possible to generate a custom hatch
(2D surface pattern) for each region on the masonry
wall. These patterns can be used for manual verification
that the masonry wall bonding and coursing are correct.
The hatch representation is computationally lightweight
– and might well be sufficient for much of the early-
stage architectural design process.
The act of placing and correcting the architectural
hatch on walls is not trivial. This may mean that overall
building dimensions need to be adjusted, or that the size
and location of doors and windows need to be changed.
Or it may be that alternative masonry units will be
specified to meet the overall building geometry. In some
situations it may be possible to adjust the width of the
head and bed joints – or allocate the dimension
mismatch to vertical and horizontal control joints. Once
the masonry patterning has been established, and the
patterns accepted, the masonry wall can be considered
to be at LOD 300. For structural masonry, LOD 350 has
a specific definition as outlined in the 2015 BIM Forum
Specification [12]. In the structural layer of the walls,
the following elements should be included in the model:
bond beam and lintels, reinforcing and embedments,
and jambs sections. These are key elements included in
automated clash detection and trade coordination.
Finally, the propagation of individual masonry
units into the BIM model, if required, occurs at LOD
400. The region concept supports the selective
placement of masonry units into the model on a region
by region basis. Therefore, if certain regions require
more complex detailing, then only those regions may be
promoted to LOD 400. The masonry units in the MUD
can be instantiated in the model and propagated either
manually or algorithmically. The specification of
placement rules according to local coordinate systems
(Fig. 3), allows the masonry units to be merged with the
hatch pattern at either the wall face or wall centreline, as
appropriate.
Figure 3 Insertion of masonry units into masonry walls.
Conference Topic
The ability to specify different LODs in the same
model and to explicitly propagate masonry units into
specific sub-regions only when needed is a useful
capability (Figure 4). Indeed, we expect that such
approach would facilitate a more effective exploration
and evaluation of alternatives without significant
compromise in computational performance.
2.3 Masonry wall features
The implementation of masonry specific BIM
applications entails first and foremost the definition of
conceptual data models that capture the properties and
relationships that are relevant for most use case
scenarios and design workflows. As mentioned before,
this need has been initially addressed by the BIM-M
initiative with the development of the MUD project,
which focused primarily on a conceptual model for
masonry units. The next step in MUD is to include
within the same conceptual framework the definition of
masonry components and accessories that are most
commonly used in masonry construction.
However, the computational representation of
masonry walls requires more than the definition of
individual masonry units, components and accessories.
In fact, masonry walls need to be characterized as being
composed not only of discrete, off-the-shelf collections
of parts but also by a series of intermediate aggregations
that result from particular arrangements of masonry
units. These aggregations conform functional and
aesthetic features of masonry walls, such as wythes,
veneers, corbels, recesses or inlays to name a few, that
that are intrinsic to masonry construction. Figure 5
provides a classification of typical masonry features
identified by the research. Since different masonry
features imply different combinations of components,
sequences of erection, equipment and skill, they also
play an important role in construction planning and cost
estimation. Therefore, the semantics of masonry
features was recognized as key in the specification of
the masonry wall data model.
At the most general level, a masonry feature may be
seen as being part of a wall, having a relative position, a
shape, a set of internal masonry units as well as internal
components and accessories, a bonding pattern and a
function. Notice that a masonry feature may contain
internal sub-features.
As discussed in section 2.1, regions are geometric
abstractions of masonry features, similar to the notion of
bounding boxes. By decoupling the representation of
masonry features (i.e. the “real-world” entity of interest)
from its geometric abstraction, a greater degree of
modelling flexibility is provided. In particular, regions
play a dual role as both place holders for further
addition of geometric detail, as well as implicit form of
aggregation of masonry components. This approach is
intended to facilitate not only the transition from lower
to higher LODS, but also the inverse, from higher to
lower LODs. Such a representational capability is
considered relevant to support more effective design
iterations, by making it easier to designers to go back to
a previous stage and explore alternatives.
3 Proof of concept schema
The conceptual data model developed for masonry
walls was preliminarily implemented as a XML Schema
and imported into SketchUp as a proof-of-concept. The
proposed semantics for masonry walls, masonry wall
features and masonry regions were formalized using
IFC 2x4 definitions as main reference framework [23]
This approach aims towards future compatibility with
Figure 5 Schema definition for masonry wall feature types.
Figure 4 Different LODs assigned to masonry regions.
33
rd
International Symposium on Automation and Robotics in Construction (ISARC 2016)
the IFC standard, and the reusability of existing
definitions related to walls in general. For example, the
semantics of IfcWallElementedCase was found to be
more appropriate for the description of masonry walls,
especially in situation where Levels of Development
need to be higher than LOD 100. As a consequence,
masonry walls can be treated explicitly as assemblies,
while the allowable set of element parts (i.e.
IfcBuildingElementPart) can be extended and
customized further to meet the information requirements
of masonry-specific workflows. This provision also
facilitated the characterization of masonry wall features
as subtype of IfcBuildingElementPart, thus keeping the
consistency of relations established at different levels of
the assembly hierarchy.
Finally, IfcBuildingElementProxy provides the basic
framework for the semantic characterization of masonry
regions. In particular, this is an IFC construct intended
to serve as spatial place holders for future allocation of
functions and exchange of undefined geometries. As
such it can have associations to different placement
objects, shape representations and material definitions,
as well as spatial containment, element compositions
and property sets. This is precisely the goal behind the
conceptualization of masonry regions, which may be
created during early design stages without a precise
meaning or associated function. The process of region
generation, by geometric decomposition of larger solid
objects is also consistent with the exploratory nature of
conceptual design which is arguably top-down.
Within the envisioned software functionality, a region
can be assigned a LOD value, the type of masonry wall
feature the region denotes (i.e. isAbstractionOf relation),
along with other inherited and specialized properties
(Figure 6).
4 Summary and Conclusions
The semantics of masonry construction and
particularly of masonry walls are largely missing from
current BIM applications. In order to provide better
computational support, BIM applications need to go
beyond representational approaches that oversimplify
the complexity involved in masonry assemblies. Instead,
a more sophisticated approach is needed, where
information requirements that are unique to masonry
workflows can be more effectively satisfied. To do so,
the representation of masonry walls needs to be
approached from process-centric perspective, with the
goal of allowing incremental levels of design
information without compromising computational
performance nor the ability of designers to explore
alternatives. These conditions imply the need for a more
expressive representation to cover multiple stakeholders’
perspectives. At the same time the representation has to
be flexible, so that different Levels of Development
(LOD) may co-exist in the same wall model.
This paper outlines the underlying philosophy for a
compact but extensible representation of masonry walls
intended to address these issues. At the core of this
representation lies the concept of masonry region, which
is a geometric abstraction for wall features that are
meaningful from a domain-specific perspective. Since
masonry wall features denote particular aggregations of
masonry units, a region serves as geometric proxy for
such aggregation. In this way different levels of
geometric detail may be added selectively to different
features of the wall, independently from their non-
geometric aspects.
The paper introduces the early stage of development
for a proof-of-concept implementation of a schema for
masonry wall using IFC as conceptual framework. The
proof-of-concept was encoded as XML Schema and
imported into SketchUp for preliminary evaluation. This
consisted in a number of masonry cavity wall models
that were built at different LODs in order to compare
modelling efforts against information content. While the
evaluation is still preliminary the exercise provided
some valuable insights. For instance, the use of regions
facilitated the addition of geometric detail up to LOD
500 (i.e. units and accessories) at selected locations of a
masonry wall while keeping overall modularity. This
was seen a more efficient way of adding resolution
where needed, while keeping the model workable.
Similarly, geometric detail could be deleted from
specific regions, while keeping semantic consistency
with the overall assembly. This is an important
functionality because the ability to transition back and
forth between LODs may potentially facilitate the
exploration of design alternatives, especially in the
context of masonry construction.
Figure 6 Masonry cavity wall modeled in SketchUp at LOD
350. Regions are created by top-down decomposition and
assigned to predefined feature types by means of the
“isAbstractionOf” relation. In this example the region
represents CMU blocks in the back-up wall containing MEP
ductwork.
Conference Topic
Future work will focus on further refinement of the
proposed masonry wall schema. This will involve
development of prototypes, systematic testing and
validation. For this purpose collaboration with both the
masonry and software industries is critical.
5 References
[1] Lee Y., Eastman C., Solihin W. and See R.
Modularized rule-based validation of a BIM model
pertaining to model views. Automation in
Construction, 63: 1-11, 2016.
[2] Standard Specification for Structural Steel 1896.
Association of American Steel Manufacturers.
Steel Construction Manual Shapes Database,
Version 14.1. American Institute of Steel
Construction, 2013.
[3] Crowley A. J. and Watson A. S. Representing
engineering information for constructional
steelwork. Microcomputers in civil engineering,
12(1): 69-81, 1997.
[4] Eastman C., Sacks R. and Lee G. Development
and Implementation Of Advanced IT in the North
American Precast Concrete Industry. ITcon
International Journal of IT in Construction, 8:
247-262, 2003.
[5] Barak R., Jeong Y. S., Sacks R. and Eastman C. M.
Unique requirements of building information
modeling for cast-in-place reinforced concrete.
Journal of Computing in Civil Engineering, 23(2):
64-74, 2009.
[6] Gentry R., Eastman C. and Biggs D. A Roadmap
for Developing and Deploying Building
Information Modeling (BIM) for the Masonry
Industry. Atlanta, Georgia USA, Georgia Institute
of Technology, Digital Building Laboratory, 2013.
[7] Lee B., Haymaker J., Gentry R. and Biggs D.
Developing a Framework for BIM for Masonry
through a Systems Modeling and Case Study
Approach. 12th North American Masonry
Conference, Denver, Colorado, USA, 2015. The
Masonry Society.
[8] Structural steel sections. Specification for hot-
rolled sections. British Standards Institute. BSI 4-
1:2005.
[9] Sharif S., Gentry R., Eastman C. and Elder J.
Masonry Unit Database Development for BIM-
Masonry. 12th North American Masonry
Conference, Denver, Colorado, USA, 2015. The
Masonry Society.
[10] Cross N. Designerly ways of knowing. Design
Studies, 3(4): 221-227, 1982.
[11] Schön D.A. Designing as reflective conversation
with the materials of a design situation,
Knowledge-Based Systems, 5 (1): 3–14, 1992.
[12] Levels of Development Specification for BIM
Models, BIM Forum, 2015.
[13] Cavieres A., Gentry T. R. and Al-Haddad T.
Knowledge-Based Parametric Tools for Concrete
Masonry Walls: Conceptual Design and
Preliminary Structural Analysis. Automation in
Construction, 20(6): 661-740, 2011.
[14] Bonwetsch T., Bärtschi R. and Helmreich M.
BrickDesign. Rob | Arch 2012: Robotic
Fabrication in Architecture, Art, and Design. S.
Brell-Çokcan and J. Braumann. Vienna, Springer
Vienna: 102-109.
[15] Eastman C., Teicholz P., Sacks R. and Liston K.
BIM Handbook, A Guide to Building Information
Modeling for Owners, Managers, Designers,
Engineers, and Contractors, John Wiley and Sons
Inc, Hoboken, New Jersey, 2011.
[16] Turk T. Phenomenologial foundations of
conceptual product modelling in architecture,
engineering and construction. Artificial
Intelligence in Engineering, 15, 83-92, 2001.
[17] Haymaker J., Kunz J., Suter B. and Fischer M.
Perspectors: composable, reusable reasoning
modules to construct an engineering view from
other engineering views. Advanced Engineering
Informatics, 18, 49-67, 2004.
[18] Mora R., Rivard H. and Bedard C. Computer
Representation to Support Conceptual Structural
Design within a Building Architectural Context.
Journal of Computing in Civil Engineering, 20,
76-87, 2006.
[19] Cavieres A. and Gentry R. Masonry Regions: A
New Approach for the Representation of Masonry
Walls in BIM Applications. In Proceedings of the
33rd eCAADe Conference, pages 585-595, Vienna,
Austria, 2015.
[20] East E. W., Nisbet N. and Liebich T. Facility
Management Handover Model View. Journal of
Computing in Civil Engineering, 27(1): 61-67,
2013.
[21] Venugopal M., Eastman C., M., Sacks R. and
Teizer J. Semantics of Model Views for
Information Exchanges using the Industry
Foundation Class Schema." Advanced Engineering
Informatics, 26(2): 411-428, 2012.
[22] IDAT GmbH, RevitPrecast,
http://www.idat.de/precast-concrete/products/revit-
precast-for-revit-structure/ (last accessed on April
27, 2016).
[23] buildingSmart, IFC 2x4 Schema,
http://www.buildingsmart-
tech.org/ifc/IFC4/final/html/, (last accessed on
April 27, 2016).
