Content uploaded by João Poças Martins
Author content
All content in this area was uploaded by João Poças Martins on Jan 16, 2018
Content may be subject to copyright.
LicA: a BIM based automated code-checking application for
water distribution systems
Authors
João Poças Martins, Faculdade de Engenharia, Universidade do Porto, Portugal
André Monteiro, Faculdade de Engenharia, Universidade do Porto, Portugal
Abstract
Recent advances in Building Information Modeling (BIM) technologies have resulted in
a rising demand for real applications of this kind of tools, in addition to the usual
standard functions. Building design code-checking is a task that has been found to be
suitable for automation, allowing for swifter, more rigorous and transparent procedures.
This paper presents research conducted at the University of Porto that has resulted
in an original method and a software application for the automated code-checking of
building water network designs. Although the methods are based on the main
Portuguese regulations, they may be adapted to other countries.
The paper presents a review of the core principles behind BIM-based automated code-
checking, and discusses the role of the IFC model as a viable format for the exchange
of data in a code-checking system, as well as current international automated code-
checking initiatives.
The authors conclude that automated code-checking procedures can be feasibly
implemented in the short term in some domains, and that they may provide a
significant incentive towards widespread BIM adoption.
Keywords
BIM
IFC
Building codes
Automated code-checking
Water distribution networks
1.Introduction
1.1.BIM
Building Information Modeling (BIM) technologies are often regarded as the next
generation’s approach to building design and information management in the
Architecture, Engineering and Construction (AEC) industry [11]. Based on an
"information rich" 3D model, BIM is seen as a significant improvement over the
traditional CAD approach [26].
Though there are already several documented successful applications of these
technologies in real projects, widespread adoption and continuous application of a true
BIM-based workflow remains slow. Authors point out that the true benefits of BIM are
obtained when the technology is applied throughout, from design to demolition [11]. At
this point, two major problems arise. First, such a flow requires lossless means for
exchanging data between all the parties involved in the construction process. In other
words, seamless interoperability is required. Studies show that interoperability costs
are a major issue against BIM adoption, with tremendous costs reported [18]. Efforts to
address these problems include standard formats for the exchange of data between
systems, the most successful being the Industry Foundation Classes (IFC) [5], an
object-oriented interoperable format for the representation of building product model
data. Second, BIM adoption is not a simple matter of updating the software type. The
entire framework of the modeling process has to be altered to guarantee an adequate
workflow. This change, however, is not usually well received in work environments. The
lack of incentives for individual users to go through such a deep and intrinsic
adaptation without a guaranteed and concrete short-range outcome makes the idea of
a BIM-based workflow very hard to sell [26].
1.2.Code-checking
Every building within a jurisdiction has to go through a process of legal requirement
assessment, which is mostly based on a code compliance design check. The legal
criteria usually assume the form of numerical value constraints or spatial requirements
that may or may not require domain-specific analysis. The process of checking these
parameters is usually manual, even when supported by IT tools. Object-oriented and
parametric modeling provides a way to automate code-checking procedures in building
designs, as it is possible to associate parametric rulings to the elements that compose
the virtual model, allowing the computerization of otherwise manual procedures [21].
Therefore, for the purpose of this paper, automated code-checking is regarded not as
an end in itself but rather as a demonstration of the immediate benefits that can be
obtained by the users who voluntarily adopt this kind of technology. It is a driver for
BIM adoption.
1.3.LicA
LicA [41] is an application that performs the automated code-checking of the
Portuguese domestic water systems regulation (DR nº 23/95). The range of the
application is very specific, as it was developed from scratch based on the regulation.
Each code and specification of the regulation was submitted to a review process to
assess the modeling relevance and define the computerization methodology. It was a
declared intention to keep the scope of the application very narrow, to show that it is
possible to use aspect models to address specific needs within a BIM-based
interoperable environment.
Regarding this matter, two main subjects are addressed in this paper: (1) the
presentation of the developed application, LicA, from the definition of the model to the
application outputs and (2) an interoperability assessment, using the IFC as the chosen
exchange file format.
2.Regulation compliance in design projects
2.1.Related research
The process of reviewing and assessing code compliance in building projects usually
consists of a set of checking procedures meant to verify property and performance
values, spatial constraints and other criteria. These concepts are defined in local
regulation and organized as a set of parameters developed with the intent of
standardizing and accelerating the formal tasks. As the parameters are defined
concepts and their assessment in projects follows a predefined methodology, the code-
checking process is much given to automation, a topic that has been the subject of
earlier studies.
Fenves [15] initiated the research on the logical organization of the structures of rules
and regulations in the 60's. As a result of his efforts and the efforts of those who
followed him and continued his work, progress was made in this area, with many
advances being achieved over the years, including structuring of regulation data into
decision tables [15], logic-based approaches for predicate calculus [29] and design
standardization [42], and development of computer application based analysis
mechanisms [16,17]. During this time, significant progress was made in the building
code standardization field; however, the resulting procedures remained mainly manual
based.
Automated code-checking gained additional relevance as a research topic in the 90’s.
With the widespread adoption of CAD tools by industry professionals, the emergence
of BIM technologies as a paradigm shift and the development of the IFC standard file
format [20], and inspired by the constraint checking of designs in mechanical
engineering [2], researchers began to investigate the possibility of automating the
validation of building designs according to the enforced legislation. The first studies
were very specific. The same generic information flow was applied to specific areas,
such as fire escape and evacuation [38], structural design [19] or accessibility [23,24].
More recently, broad-spectrum studies have been requested and funded by
government institutions in a few countries, with the intention of implementing their
version of an automated code-checking system for their public contracts.
2.2.Definition
Various terms are directly related to the act of reviewing and validating building designs
according to local regulation. Code-checking [25], rule-based checking [12],
compliance checking [20] and constraint checking [37] are the most commonly used.
Different authors use different terms and definitions; however, apart from some minor
differences, their overall meaning is usually identical. In addition to the generic
definition, all the terms describe a passive process, i.e., it does not modify the design
at any point, as it is merely a review and validation methodology. The established
codes or constraints usually focus on global safety, comfort, accessibilities and building
performance specifications.
Automated code-checking adds to the previous definition the usage of software to run
a code, constraint or rule-based checking routine. Current tools that support the
process and are often associated with this concept include BIM and the IFC.
2.3.Requirements
A parametric object-oriented model is a necessary requirement for a truly automated
code-checking system. If the building objects in the design are represented simply by
geometric entities, such as lines or shapes, they will not be recognized as such by
code-checking routines. Users will be required to provide the parameter value input
manually. BIM applications address this issue by enforcing object-oriented modeling,
which covers some of the modeling requirements for code-checking purposes. It is
debatable whether manual parameter value input will ever cease to be necessary,
however BIM tools already represent a big advance compared to the traditional
approach by enabling automated checking of geometrical and spatial constraints [26].
An automated code-checking system can be [12]: (1) an application tied to a design
tool, such as a plug-in; (2) a stand-alone application that is independent from the
design application; (3) a web-based platform into which designs can be submitted.
Common to all the three cases is the fact that every compliance code must be
parameterized. Considering the local scope of building regulations, the
parameterization of every single compliance code for every single location would be a
tremendous, probably unfeasible effort. Code and design standardization are,
therefore, desirable requirements for successful automated code-checking. This aspect
is significantly important, as it not only reduces the development and programming
effort, but also fosters interoperability between the design and the code-checking
models.
Interoperability can be seen from two different angles. Software interoperability refers
to the exchange of data between two or more different systems. This exchange should
be as accurate and lossless as possible. This mandatory requirement is applied upon
the development of the code-checking tool. Although it is an ambitious goal it is a
requirement that can be measured and addressed before systems are deployed.
Modeling interoperability, on the other hand, is much harder to obtain, as it is enforced
by the user. It refers to the compliance between modeling design procedures. A typical
modeling interoperability problem is a set of slabs assembled as a stair but not
semantically modeled as such. The code-checking routine will therefore be tricked,
potentially leading to wrong, misguided results.
As the topic of automated code-checking is still in its early years, a consensus about
which system requirements should be absolutely indispensable is yet to be achieved.
In [20], emphasis is given to the codes, as the author underlines the importance of
having a simple and effective encoding process. For that, computer-programmed rules
must be easily understood by regulation authors, the rule database must be
independent of software (to prevent versioning problems), all development must be
compliant with open standards, and consideration must be given to the industry
process of model authoring. Visualization and interoperability issues are addressed in
[7]. An automated code-checking system must be able to interact with object-based
CAD systems and must be able to integrate other platforms. Desirable characteristics
of the visualization component include user-friendly reporting systems and 3D
visualization with references to location.
2.4.System
According to [12], an automated rule-based checking consists of four major steps: (1)
rule interpretation: the code-making process from human written rules to computerized
codes; (2) building model preparation: model creation assisted by BIM-based IFC-
compatible tools plus object extensions added to the original model for code-checking
purposes; (3) rule execution: where the rules and the model are brought together to run
the code-checking routine; (4) rule reporting: code-checking outputs in text and
graphic-based reports that may also include references to the source rule.
To run the code-checking routine, the system must extract information from the design
model. The "extraction" is the system's key function, as it determines its automation
degree. Extraction types or, in other words, information availability types, can
essentially be processed in one of three ways [12]: (1) the designer manually inputs the
necessary information. This approach partially defeats the purpose of automating the
extraction, though in some cases it is hard to apply a different approach when the
building codes are hard to program; (2) the computer is equipped with routines capable
of generating the new data necessary for the extraction, directly from the design model.
Once again, interoperability issues arise, as the code-checking model must be
compatible with the design model; (3) application of an analysis model that generates
complex information, such as structural stability information, and then applies it in the
code-checking routine. It should be noted that this system relies on one of the previous
approaches for information extraction. Even if the information extraction approaches
were formally separated, a comprehensive code-checking system will most likely
incorporate features from all of them.
Code-checking can be more than simply verifying compliance parameters. Constraint
solving [37] refers to the process of applying the constraints directly upon the design,
so that the system provides the optimal solution. In other words, the system renders a
code-compliant design instead of checking a user-submitted proposal. The system
enforces compliance instead of simply checking for it. This type of system is not yet
feasible in every domain, as it requires the processing of too much data. Not only there
are not systems currently prepared for it, but also manual check-based codes are not
meant for that kind of approach. In addition, constraint solving harshly limits the
creative process of design. This goes severely against the current design procedure, in
which the engineering usually follows the architecture, rather than the other way
around.
2.6.Initiatives
In [10], Eastman sets around the year 2020 as the goal for automated code-checking
systems to become a feasible reality in several countries. Although tools exist that
support this kind of system, a considerable amount of work is still required, especially
concerning the definition of specific object models for code-checking and the
structuring of standards and information flows.
A fairly recent survey on automated rule-based checking initiatives [12] took a
comprehensive look at currently developed applications of this kind of system, focusing
on the major cases. In the survey, five different case studies were reviewed.
The CORENET (COnstruction and Real Estate NETwork) initiative became the leading
automatic code-checking implementation, when back in 1995 the Singapore Ministry of
National Development funded the effort with the intent of "reengineering and
streamlining the fragmented work process in the construction industry, in order to
achieve quantum improvements in turnaround time, quality and productivity" [30].
CORENET consists of three platforms [4]: (1) e-Submission, an e-business system for
project submission and document approval; (2) e-PlanCheck, a set of IT applications
for automated code-checking of BIM-based building projects; (3) e-Info, a central
repository of building and construction-related information in Singapore.
The code-checking platform, e-PlanCheck, is responsible for the rule execution of BIM-
based models submitted in IFC. The IFC file format has been included in the code
programming process; however, mapping of the IFC schema for implementation of rule
checking is a major issue, [12] as many of the concept definitions required for code-
checking are not available [30]. To address this issue, e-PlanCheck was implemented
on top of FORNAX, a software platform developed by novaCITYNETS that extends
IFC model objects and builds additional intelligence to enable the implementation of
checking functions, i.e., it adds higher-level semantics that are relevant for code-
checking by encapsulating building components into a set of FORNAX objects, each of
which defines relevant attributes and behaviors [30]. The rule execution comprises
building code checks on building plans, mostly for spatial and accessibility
requirements, and building services, for MEP system requirements [12].
The Singapore effort in automated building code-checking was the earliest and is
currently the farthest along. As such, it served as the base point for other pilot projects
in Norway, Australia and North America [20].
Statsbygg is an organization that acts on behalf of the Norwegian government as
property manager and advisor in construction and property affairs [6]. The organization
is responsible for leading several BIM efforts, seeking to "contribute to increasing the
chances of theme-related analyses based on increased awareness and value in
building information" [13].
Initiated in November 2000, the ByggSøk Project aims to "deliver better and more
efficient public services and improve the industrial competitiveness through a nation-
wide standardization of zoning proposals and building applications" [6]. It consists of
three modules: (1) e-Information System, for publishing information required to prepare
a plan or application; (2) e-System for Zoning Proposals, for communication between
developers and the local government; (3) e-Building Plan Application Submission
System, for building application registration via the Internet. The work is ongoing and
currently focusing on the issues of classification, terminology and standardizing rule-
checking in construction at an international level [20].
One of ByggSøk's most promising real project-based pilots, the HITOS project,
adopted several of the lessons learned from the CORENET initiative, applying them in
two major features [12]: (1) spatial program evaluation, enforced thanks to the
management platform dRofus [9], which allowed the addition of specific building rule-
checking requirements that were not covered by the IFC; (2) building accessibilities
check, carried by Solibri Model Checker (SMC) [1], which relies mostly on universal
requirements, parameterized by IFC's geometrical constraints and SMC's code-
checking features. According to [33], Statsbygg found that the IFC-based universal
design checking implemented by Solibri could reduce common design failures or
deficiencies by 60 to 70%.
In Australia, the Cooperative Research Centre for Construction Innovation funded a
code-checking effort, DesignCheck, developed by the Commonwealth Scientific and
Industrial Research Organization (CSIRO) and the University of Sydney. With an
outline similar to that of the HITOS project system, the system architecture relies on the
EDM Model Server as the central platform, performing model management features,
rule encoding, and rule execution. EDM was chosen over SMC as the rule-checking
platform, as it provides a more flexible rule specification system, by allowing the
encoding of manually written rules into computer code in EXPRESS [8]. DesignCheck
focuses on accessible design regulations [12]. Although it has a structural design
similar to that of CORENET’s ePlanCheck, DesignCheck shows a substantial
advantage in supporting the code-checking during various steps of the design process.
The rule reporting, on the other hand, is inferior to CORENET's as all the results are
text based only [20].
At the same time, similar efforts were developed in the United States, with the General
Services Administration (GSA) leading the BIM implementation effort (GSA BIM
Program). In 2003, the GSA established the National 3D-4D-BIM Program. In late
2006, the GSA issued several BIM guidelines and, since 2007, all GSA projects
involving new construction are required to submit BIM data allowing spatial validation
review in the final concept phase [22].
GSA also funded a code-checking system for spatial validation in US Courthouses,
functioning around IFC and SMC [12]. The spatial program validation is now applied to
all GSA new construction projects [22].
Solely funded by the International Code Council (ICC), the SMARTcodes initiative aims
to develop a systematic way to represent paper-based codes into machine-
interoperable rules that can be used by model-checking software to identify items in a
design represented by a BIM and that are outside the bounds established by the
building code [12].
The encoding process is processed in Web-based software by applying tags to
electronic copies of building codes using a tag dictionary or ontology [20]. In other
words, the users pick up the desired written rule and the SMARTcodes builder
identifies key phrases and their logical role, then formalizes the phrase using terms
from a dictionary that describes properties associated with each term, the enumeration
of properties, data types and units associated with each property [27]. All the encoded
rules follow an IFC constraint compatible mapping. So far, SMARTcodes only deals
with IFC-compliant designs.
Rule execution for SMARTcodes is currently supported by Digital Alchemy's Solibri
Model Checker and AEC3's XABIO.
3.LicA
3.1.Outline
LicA [41] is a computer system that has been developed at the University of Porto
Faculty of Engineering (FEUP), Portugal, that performs the automated code-checking
of domestic water system networks projects, according to the regulations, codes and
specifications in effect in Portugal.
The main components are included in a single SQL Server database named LicA [34].
LicA's conceptual architecture is represented in Fig. 1. This database includes a set of
tables with all the objects needed to represent the network and calculation preferences.
It also includes hydraulic analysis tools and code-checking routines, developed in T-
SQL. Results are gathered in tables for post-processing. The database can be
accessed through ODBC (Open Data Base Connectivity), which enables the
integration of custom applications, including web applications, with this system.
Fig. 1 LicA's conceptual architecture - database, input and output elements.
A 3D graphical user interface named LiCAD has also been developed to provide input
and to display results. LiCAD outputs results both in graphical form, with the results
showing directly in the network model in color code, and as text descriptions.
The LicA database and the user interface were developed as separate applications to
foster further development and usage freedom. As databases usually have a larger life
span than user interface applications, separating the two is seen as a way of
preventing a few versioning and interoperability issues. SQL is a very stable and
interoperable format [31]. It eliminates the need to adjust the database with each
update and grants further interoperability, not only with new versions of the user
interface, but also with other applications, e.g., web applications. In addition, the user
interface functions can easily be accessed by other applications, if needed.
Interoperability was a major concern during the development of the application. Though
research on the IFC data model showed that it is a comprehensive way for building
product data model representation [11], it was not initially included in the application’s
specifications, mainly because of two reasons. First, the format is yet to be considered
an official standard in its entirety, either by normative entities, such as the International
Standardization Organization (ISO) [28], or by the users community [14]. Second, the
programming complexity made it an obstacle to be addressed at a later stage.
As the IFC was not to be supported as a built-in format in this first version of the
application, the intention was to create a new format that was solid and consistent
enough to perform flawlessly and that included all the relevant objects and properties
required to perform the code-checking procedures. According to Behrman [3], in the
absence of a comprehensive and complete standard, the primary goal should be
strengthening the existing, more domain-oriented one. Based on this logic, a bottom-up
approach was adopted in the development of a minimalist aspect model, strong
enough to answer its domain's specific demands, as opposed to integrating more
comprehensive features.
The database was developed from scratch according to the Portuguese building codes.
As the current building codes were developed for manual application, implementing
specifications as a set of parameters and rules is not always straightforward.
Ambiguities and other imperfections found in the regulations hinder objective data
interpretation by the computer, or require the manual interpretation of the design
information, which partially defeats the purpose of automating the code-checking
process. Detailed analysis of regulations for this purpose, therefore, reveals that fully
automated code-checking processes require improved, fully machine-interpretable
building codes. In the absence of such regulations, interpretation issues were
addressed in LicA by creating different categories for the compliance-checking results,
including a class for checks that were performed but that should be reviewed manually.
3.2.Data Model
A few major requirements were considered upon the development of the data model:
• The model should be strictly domain oriented. It should be simple enough to
allow easy data input by MEP engineers, with minimal additional information
from other design specialties.
• Excessive data input should be avoided;
• Subjective, human observation based data (such as "A is close to B") should
not be included in the model, although this kind of relationships is used in the
current building codes;
• The model should be complex enough to run property product model
descriptions and calculation routines needed for the code-checking process;
• The model database should include hydraulic analysis routines (such as
network water flow or network minimum and maximum pressure calculations).
Database tables are divided into four main types, according to their purpose:
• Input tables that describe the network, its components and properties;
• Output tables that display the results of the hydraulic and code-checking
analysis;
• Tables with text-based descriptions that are used to generate reports in
different languages;
• Tables that contain lists of admissible values of network components'
properties.
This organization provides an easy way to add and remove parameters if the regulation
requires updating.
3.3.Model description
3.3.1.Database
In the current version, the data model supports both hot and cold water networks.
Network representation consists of nodes and flow segments.
In the model, nodes serve different purposes. They may be simple geometric entities or
they may have other functions or modeling properties. Hydraulic analysis results are
computed for all the nodes in the model. All consumptions are associated with nodes.
Devices can include one or more nodes, each with their own hydraulic variables, flow
and pressure. Tanks are modeled as nodes.
Flow segments can assume the form of a pipe, a valve or a pump. Pipe classification is
determined according to the placement (inside or outside the building), thermal
isolation (existing or nonexistent) and material type. All the valve types in the database
are mentioned in the domestic general regulation for water systems.
Each device is explicitly linked to the architectural design by means of a property that
states in which space it is located. Although it would be possible to derive this kind of
relationship geometrically, this would require further information, to be inserted by the
user. As the system was developed to provide immediate benefits to the users who
voluntarily and independently adopt it [40], it was important to ensure that information
related to other domains should be provided explicitly, and not derived from another
building model that may or may not have been developed. Naturally, if a full
geometrical architectural model is available, it can be used to provide the necessary
information for this purpose, or to check the accuracy of the network model.
Information about the location of each device is a necessary requirement for the code-
checking procedures.
The domestic general regulation for water systems was an important reference in the
data model definition, although naturally it does not include every class of objects that
might be used in MEP designs. Some heaters and water tanks, for instance, should be
modeled using assemblies of already existing admissible objects.
Before the code-checking routine, the application runs a preliminary model-checking
routine to guarantee its integrity, and ensure that the minimum requirements are met.
LicA performs hydraulic analysis of the network, which can be done either as a part of
the design procedure or as a compliance-checking operation. Analysis procedures rely
on a Breadth First Search Algorithm to obtain hydraulic properties at successive nodes.
Fig. 2 Hydraulic analysis user interface - outputs.
Hydraulic analysis outputs include water flow, pressure, flow segment length and node
losses.
The LicA database structure is functionally independent from any external application.
It can, however, be accessed by other applications to receive input or provide output.
The database works as an information repository, providing mechanisms for data entry
that ensure structural integrity of the parametric model [36].
3.3.2.User interface
LiCAD is a graphical user interface application developed specifically for the LicA
database. Direct access to the database is made through an ODBC connection that
allows the user to run all the hydraulic calculation, code-checking and document
generation routines.
The document generation outputs include floor plan and section, as well as 3D views of
the network model, hydraulic analysis reports, quantity takeoffs and the code-checking
analysis report.
Fig. 3 Conceptual relations between LicA and LiCAD.
LiCAD was developed in Visual Basic 2008, using ADO.NET objects to access the
database. The user interface uses the DirectX-based technology WPF - Windows
Presentation Foundation, supported by most current display adapters. The use of this
presentation framework allows the application to browse and edit the model using a 3D
interface, using typical commands such as rotation, translation and zoom. Visual
representation of the network model consists of nodes and flow segments. The WPF
framework allows the representation of different properties through the attribution of
different colors and textures to each of them.
The user interface is divided in four different tabs [36]:
1. Model definition
In this tab, the user can design the network and navigate the model. The hot and cold
networks are differentiated by different colors and the element properties can be
viewed and edited. Both orthographic and perspective projections can be used to
display the model.
Fig. 4 Model definition user interface - 3D view.
2. Hydraulic analysis
This tab includes the commands to run the network hydraulic calculation routines.
Results, including flow, flow segment length and maximum and minimum pressure,
appear both in text and graphical form, in color code.
Fig. 5 Hydraulic analysis - flow viability assessment results using color code.
3. Code-checking
Similarly to the previous tab, the code-checking results are also displayed directly in
the model according to a color code representing the compliance or not to the
regulation requirements.
Fig. 6 Code-checking user interface - compliance assessment results using color code.
4. Maps and views
All the text-based reports are presented in this tab. The current version of the
application generates quantity takeoff, hydraulic calculation and code-checking reports.
Fig. 7 Documents user interface - table with flow property values.
Fig. 8 Documents user interface - table with code-checking results.
3.4.Software outputs
Visual outputs of the software can be divided between traditional views - floor plans,
sections and 3D views - and dynamic views, supporting both 2D (Fig. 9) and 3D (Fig.
4) perspectives.
Fig. 9 2D section view.
The application also provides text-based outputs, which include all dynamic texts
presented in the desktop and the database reports detailing the results of the hydraulic
analysis and code-checking routines (Fig. 10).
Fig. 10 Model definition user interface - dynamic text-based outputs.
The application performs quantity takeoffs automatically. There is no official standard in
Portugal for this specific task, although there are some acknowledged publications that
are usually followed as best practice guidelines [39], which were closely followed when
developing the application.
Takeoff documentation is essential to the construction process. Automating its
generation directly from a building model is a big step towards greater efficiency in
several construction tasks. In addition to increasing accuracy and reducing the time
that is required to produce documents, quantity takeoff is directly related to scheduling
and cost estimation, which means that those tasks would also benefit from its
automation.
3.5.Model submission
The submission procedure for code-checking can be performed using one of two
alternative methods: either the designer uses standard software applications to perform
compliance checks locally and submits the results, or the full design is submitted to the
authority's platform, which centralizes the code-checking procedures. The first
alternative has several disadvantages, including security issues and problems
concerning software distribution and versioning. The second approach requires the
authority having jurisdiction to maintain a stable code-checking platform; conversely, it
offers greater control and allows the development and upgrade of the software while
offering users a standard web-based interface.
XML has been the standard format for the exchange of data over the internet for over a
decade [32]. As the LicA database was developed in SQL Server and this system
allows database exportation in XML format, the preferred approach would be to submit
the model in XML, so that it can then be checked for compliance [34].
Fig. 11 Conceptual relations between LicA, LiCAD and LicaXML.
XML is a very interoperable format, however, it is more suited to exchange
alphanumerical data rather than actual product model data. A quick survey on the most
common BIM software shows that XML is not used as a data exchange format,
although it is possible to find variations of the format incorporated in some BIM
applications.
All the major automated code-checking BIM-based initiatives developed to date rely on
the IFC as the interoperability format between modeling software and model
submission platforms [12]. The ifcXML [5] - an adaptation of IFC schemas to the XML
programming language - shows that the XML can still be of use in this process, even if
indirectly.
With the development of both the LicA database and the LiCAD interface, the intention
was to create a system from scratch that ranged both the network modeling and the
automated code-checking procedures. In the early stages, in order to show that,
although recommended, BIM usage does not necessarily require the adoption of BIM
tools by all parties, it was considered important that the system should operate
independently, thus allowing individual users to begin experiencing some of the
benefits of this technology, and making it easier to justify the adoption of BIM-based
tools and procedures [36].
After developing LicA and testing its performance, broadening the application's scope
was the next step, and for that effect, assessing IFC compatibility a priority, as
modeling submission for code-checking would more than likely rely on an IFC
workflow.
4.Automated code-checking using LicA. Interoperability issues.
4.1. IFC workflow
An ideal BIM-based automated code-checking flow for LicA would start with network
modeling in a common BIM tool, such as Revit MEP, followed by model exportation in
IFC file format and, finally, model importation by LicA (Fig. 12). Model importation and
exportation are the main steps and the subject of an experimental test to determine this
flow's behavior in terms of interoperability.
Fig. 12 BIM - IFC - LicA workflow conceptual architecture.
IFC may be the most used format for interoperability purposes, but that does not mean
it performs flawlessly. This happens not only because it is hard for the format to range
every existing product representation for every purpose, but also because different
software houses use different approaches, which means that each BIM software will
have its own tools, its own functions and its own ways of mapping the IFC data
structure. As such, relying on the IFC format to achieve a comprehensive lossless data
flow can be disastrous if the parts involved do not take these constraints into account.
4.2.IFC schema
There are two major IFC modules that provide the needed resources to model a water
network system: the IfcSharedBldgServiceElements and the
IfcPlumbingFireProtectionDomain.
The IfcSharedBldgServiceElements schema includes defining concepts for type and
occurrence entities, performance history data and fundamental properties to define
building service systems, including the water network system. The
IfcPlumbingFireProtectionDomain schema serves as an extension to the elements of
the IfcSharedBldgServiceElements schema, defining mostly terminal objects, such as a
shower or a fire hydrant. These are restricted to this specific domain, as opposed to the
elements defined in the IfcSharedBldgServiceElements, which can be referenced by
different domains, namely the HVAC, the electrical and the building controls domain
[5].
These two modules define the more specific concepts of this domain in particular.
Naturally, they are not sufficient to generate a network model, as more generic
concepts are also needed. Concepts such as element placement, geometric
constraints or label tools are defined by much more generic entities within the IFC
schema.
4.3.Comparing the LicA and IFC databases - method
description and application results
The suitability of a given BIM application for an IFC-based automated code-checking
workflow depends on the performance of its data export translator. Some BIM
applications include features to compare the original, proprietary, model with the IFC
one (e.g. Graphisoft ArchiCAD), while other BIM applications allow the user to establish
his own rules to check whether or not the exported IFC-based model meets the desired
requirements (e.g. Solibri Model Checker).
Since the LicA database does not include IFC schemas, assessing the import
capabilities is only possible by comparing the two databases.
The method [35] used to compare the two schemas was straightforward. Using the
LicA database tables as the starting point, an exhaustive survey of the IFC schema
was performed to determine whether each LicA entity had an IFC match. While
performing this inspection, it was realized that the matching criteria varied, mostly
between three fundamental types: (1) perfect match, with both entities possessing
identical semantic meaning; (2) indirect match, to the entities that matched the same
class of element but lacked property definitions; (3) undetermined, to the entities that
found no match in the IFC schema. However, in this case, this does not invalidate the
IFC format as an exchange format for this type of element since in most cases, the
available IFC resources can be used to develop a modeling solution to overcome the
absence of a given entity. This criterion was applied to label each case with the
corresponding matching type.
In general terms, the results were pleasing. It was confirmed that the IFC schema does
provide a comprehensive set of entities for product model representation, ranging very
different domains with a significant amount of very specific, low-level objects defined.
Almost all elements needed to model the network, according to the LicA specifications,
had a direct match in the IFC schema [35]. These include the main physical objects,
such as flow segment objects, flow fitting objects, flow storage objects, flow control
objects and terminal type objects, abstract concepts of geometrical constraints and
element placement, and descriptive tools of measurement and labeling.
The indirect match status indicates that an element found a match at class level but
lacks the appropriate property set. This has been found in three major element types:
(1) valves lacked the correct definitions according to LicA specifications and, therefore,
the domestic regulations; though there are already some property sets defined for the
class "valve", most LicA valve types are missing and are essential to the compliance-
checking process; (2) element materials do not have defined property sets in the IFC
schema, as this is not the most common modeling approach. What usually happens is
that this parameter appears as part of the element description and does not possess
semantic value. In this case, LicA requires the material to be an "intelligent parameter"
with associated values, such as thickness or thermal and acoustic properties, which
means it has to be defined as a property set. The IfcMaterialResource module
assembles the entities necessary to create material objects; (3) zone elements are
similar to materials. IfcSpace already has many defined concepts to parameterize a
zone, yet it lacks the specific properties linked with the domestic regulations. It should
be noticed that the missing properties are all very specific and most likely vary from
country to country. In the absence of global modeling standards, it is almost impossible
for an exchange format to cover all the options available in construction, so the scope
should not go at micro property level.
Not many elements had an undetermined status, the majority being non-SI units and
some being network devices. These require further definition than just a property set,
as they have functions associated, and as such, a more extensive development effort
is required.
The results were also evaluated in relative terms, as a percentage. Taking into account
every single entity, 61% of them were direct matches, 29% were indirect and 10% were
undetermined. It should be noticed that these values only provide a reference point for
the degree of compatibility between the LicA and the IFC database. Successful IFC-
based data exchange depends on a higher number of factors besides entity
correspondence.
5.Conclusions
A newly developed application to perform the automated code-checking of water
distribution network projects in Portugal was presented. The application, LicA, consists
of two independent systems, the database and the user interface. The database
contains all the code specifications and routines necessary to perform the hydraulic
analysis and the code-checking. The user interface includes model definition and
browsing functions. It can also be used to display network schematics and results
tables.
Interoperability with mainstream BIM applications was not a major concern during the
development of the application. It was intended to be independent, to show that it is
possible to use BIM-based applications to address specific needs. As most BIM tools
have a comprehensive scope, the users are required to change a substantial portion of
their current workflow, leading to discouragement regarding BIM adoption. The goal
was the opposite, to create an incentive for the adoption of this process. After the
development and the successful testing of the application, the compatibility between
the LicA database and the IFC was the subject of a test, through object
correspondence assessment. The results were satisfying, as the IFC included most of
the needed object definitions according to LicA's specifications.
The research reported in this paper reinforced the belief that, although a truly
comprehensive automated code-checking is not expected soon, it is still possible to
use BIM-based applications for compliance tests in some domains. Nevertheless, it
must be kept in mind that automated, computer-based proceedings differ from manual
routines. Some adjustments must be made to input the necessary information. These
adjustments must be foreseen and structured in the form of standard workflows to
assure the consistency of the information exchange and the integrity of the checking
process itself. Work must also be done at building code specification level in order to
adapt the existing manual check-based codes to computable specifications, as the
redundancies and abstractions that depend on human interpretation, as well as
inaccurate spatial configuration, must be eliminated and reassembled as viable codes,
100% compatible with the programming and modeling requirements.
Acknowledgements
We would like to thank the European Regional Development Fund (ERDF), Agência de
Inovação (ADI) and the National Strategic Reference Framework (NSRF) for the
funding of our research units.
References
[1] D. Alchemy, Solibri Model Checker, (2011).
[2] R. Anderl, R. Mendgen, Modelling with constraints: theoretical foundation and
application, Computer-Aided Design 28 (3): 155-168 (1996).
[3] W. Behrman, Best Practices for the Development and Use of XML Data
Interchange Standards, CIFE Technical Report, Stanford University, 2002.
[4] buildingSMART, The CORENET project in Singapore, buildingSMART Case
Studies (2006).
[5] BuildingSMART, IFC Overview, buildingSMART, International home of
openBIM, Model Support Group, Imprmentation Support Group (2011).
[6] ByggSøk, eGovernment in the field of zoning, building and construction,
National Office of Building Technology and Administration (2011).
[7] L. Ding, R. Drogemuller, J. Jupp, M.A. Rosenman, J.S. Gero, Visualisation and
Information: Automated Code Checking, Clients Driving Innovation International
Conference (2004).
[8] L. Ding, R. Drogemuller, M. Rosenman, D. Marchant, J. Gero, Automating code
checking for building designs - DesignCheck, Cooperative Research Centre
(CRC) for Construction Innovation Information and communication technologies
- improving efficiencies (2006).
[9] dRofus, Statsbygg with dRofus and TIDA as key planning tools., (2011).
[10] C. Eastman, BIM handbook a guide to building information modeling for
owners, managers, designers, engineers and contractors, John Wiley and Sons
Ltd, New Jersey, 2008.
[11] C. Eastman, T.S. Jeng, A database supporting evolutionary product model
development for design, Automation in Construction 8 (3) (1999) 305-323.
[12] C. Eastman, J.-m. Lee, Y.-s. Jeong, J.-k. Lee, Automatic rule-based checking of
building designs, Automation in Construction 18 (8) (2009) 1011-1033.
[13] E. Eberg, T. Heieraas, J. Olsen, S.H. Eidissen, S. Eriksen, K.H. Kristensen,
O.Christoffersen, M.A.T., F.M. Lê, Experiences in development and use of a
digital Building Information Model (BIM) according to IFC standards from the
building project of Tromsø University College (HITOS) after completed full
conceptual design phase, Report by Statsbygg (2006).
[14] B.A. Ellis, Building Information Modeling: An Informational Tool for
Stakeholders, Government/Industry Forum, Federal Facilities Council (2006).
[15] S.J. Fenves, Tabular decision logic for structural design, Journal of Structural
Engineering 92 (ST6) 473–490 (1966).
[16] S.J. Fenves, J.H. Garrett, H. Kiliccote, K.H. Law, K.A. Reed, Computer
representation of design standards and building codes: U.S. perspective, The
International Journal of Construction Information Technology Vol 3 (Page 13-
34) (1995).
[17] S.J. Fenves, R.N. Wright, F.I. Stahl, K.A. Reed, Introduction to SASE:
Standards Analysis, Synthesis, and Expression, U.S. Department of
Commerce, National Bureau of Standards Report NBSIR 87-3513 (1987).
[18] M.P. Gallaher, A.C. O'Connor, J.L. Dettbarn, J.a.L.T. Gilday, Cost Analysis of
Inadequate Interoperability in the U.S. Capital Facilities Industry, National
Institute of Standards and Technology (NIST), Gaithersburg, MD, USA (2004).
[19] J.H. Garrett Jr., S.J. Fenves, A knowledge-based standards processor for
structural component design, Engineering with Computers 2 (2) (1987) 219–
238.
[20] D. Greenwood, S. Lockley, S. Malsane, J. Matthews, Automated compliance
checking using building information models, Cobra 2010 - The Construction,
Building and Real Estate Research Conference of the Royal Institution of
Chartered Surveyors Dapuhine Université, Paris, 2-3 September 2010 (2010).
[21] M.D. Gross, Elements That Follow Your Rules: Constraint Based CAD Layout,
Proceedings of Association for Computer Aided Design in Architecture
(ACADIA) Tuscon, AZ (pp. 115-122) (1996).
[22] U.S.G.S.A. GSA, BIM Guide For Spatial Program Validation, The National 3D-
4D-BIM Program Office of the Chief Architect, Public Buildings Service, U.S.
General Services Administration (2007).
[23] C. Han, J. Kunz, K. Law, Building design services in a distributed architecture,
Journal of Computing in Civil Engineering ASCE 13 (1) (1999) 12–22.
[24] C. Han, J. Kunz, K. Law, Compliance Analysis for Disabled Access, Advances
in Digital Government Technology, Human Factors, and Policy, WilliamJ.
McIver Jr., AhmedK. Elmagarmid (Eds.), Kluwer, Boston, MA (2002) pp. 149–
163.
[25] C.S. Han, J. Kunz, K.H. Law, Making Automated Building Code Checking A
Reality, Center for Integrated Facility Engineering, Stanford University, CA,
USA (2003).
[26] I. Howell, B. Batcheler, Building Information Modeling Two Years Later - Huge
Potential, Some Success and Several Limitations, The Laiserin Letter (2005).
[27] ICC, SMARTcodes Frequently Asked Questions, International Code Council
(2007).
[28] I.O.f.S. ISO, Industry Foundation Classes, Release 2x, Platform Specification
(IFC2x Platform), ISO/PAS 16739:2005 (2011).
[29] D. Jain, K.H. Law, H. Karwinkler, On processing standards with predicate
calculus, Proceedings of the Sixth Conference on Computing in Civil
Engineering, ASCE, Atlanta, Georgia (1989).
[30] L. Khemlani, CORENET e-PlanCheck: Singapore's Automated Code Checking
System, AECbytes Building the Future (2005).
[31] F. Lampathaki, S. Mouzakitis, G. Gionis, Y. Charalabidis, D. Askounis,
Business to business interoperability: A current review of XML data integration
standards, Computer Standards & Interfaces 31 (6) (2009) 1045-1055.
[32] M. Libicki, J. Schneider, D.R. Frelinger, A. Slomovic, Scaffolding the New Web,
RAND, Santa Monica, Califórnia, 2000.
[33] K. Lindberg, M.A.T.L, Development of a new ICT-system for registration and
assessment of accessibility to public buildings, Property Management,
Statsbygg, BAS Conference (2006).
[34] J.P. Martins, Licenciamento automático de projectos - uma solução para um
problema de cooperação?, 1º Forum Internacional de Tecnologia da
Construção - TECCON 2009: Tecnologias associadas ao Processo do
Empreendimento de Construção. GEQUALTEC. Faculdade de Engenharia da
Universidade do Porto 10 - 11 December (2009).
[35] A. Monteiro, Avaliação da aplicabilidade do modelo IFC ao licenciamento
automático de projectos de redes de distribuição predial de água, Tese de
Mestrado Integrado, Departamento de Engenharia Civil, Secção de
Construções Civis, Faculdade de Engenharia da Universidade do Porto, 2010.
[36] A. Monteiro, J.P. Poças Martins, BIM Aplicado ao Licenciamento Automático de
Projectos, GESCON 2011, 27 e 28 de Outubro, Porto – Portugal (2011).
[37] R.A. Niemeijer, B.d. Vries, J. Beetz, Check-mate: automatic constraint checking
of IFC models, Eindhoven University of Technology (2009).
[38] F. Oxel, Life safety issues in hotel/casino occupancies, Proceedings of the 2nd
International Fire Research and Engineering Conference, Center for Fire
Research (1998).
[39] F.d.C. Pacheco, Dicionário Técnico de Construção Civil, Sindicato Nacional dos
Engenheiros Técnicos, Mafra, 1997.
[40] J.P. Poças Martins, V. Abrantes, Automated code-checking as a driver of BIM
adoption, XXXVII IAHS, World Congress on Housing (2010).
[41] J.P.d.S. Poças Martins, Modelação do Fluxo de Informação no Processo de
Construção, Aplicação ao Licenciamento Automático de Projectos, Dissertação
para obtenção do grau de Doutor em Engenharia Civil, Faculdade de
Engenharia da Universidade do Porto, 2009.
[42] W.J. Rasdorf, S. Lakmazaheri, Logic-based approach for modeling organization
of design standards, Journal of Civil Engineering 4 (2) (102-123) (1990).
