Information exchange can be an issue common to any
area of modern life where computers are used to store and manipulate
information. The ability to efficiently exchange information increases
productivity and reduces errors. Recently, and in particular with the
explosion in the use of the Internet, this topic has emerged as an area
of particular importance. This article answers a number of questions
related to building product models and places them within the context of
fire protection engineering.
WHAT ARE THE PROBLEMS ASSOCIATED WITH CURRENT COMPUTER-BASED INFORMATION EXCHANGE?
Without a standard format for the content
and transfer of information between software tools, conversion
processes are necessary. Each conversion process may "devalue" the
information, as the content has to match the lowest common format.
Furthermore, ambiguities may occur in the data that cannot be resolved
during the conversion. The use of software tools across a whole range of
engineering disciplines means that interoperability between these tools
is becoming of critical concern.
Building product models provides a means in which efficient information exchange can come about.
WHAT IS A BUILDING PRODUCT MODEL?
Fully automated, one-time data entry and
seamless integration of project life-cycle work processes can be
identified as a significant trend for the construction industry that
have the potential to revolutionize the industry. The construction
process covers the complete life-cycle of the structure, from inception
to demolition. Fire protection engineering is only one domain of many
that make up the overall construction process. Additional domains might
include architecture, structural engineering, environmental engineering,
building services, and many others. Many parameters related to a
structure are common to a range of disciplines. These parameters may
include the building geometry and topology, the materials and components
used in the construction, and the location of the structure within the
In general, any product can be considered
to consist of a collection of "entities." A product model expresses the
type of entities that represent the product; the properties that are
needed to describe those entities and the interrelationship between
entities. A building product model is a product model that specifically
relates to buildings where entities may be physical objects such as
doors, windows, walls, etc., or more conceptual entities such as spaces
or processes. Within a building product model, a door entity has
specific properties (such as its dimensions and construction materials)
and the relationship with the wall in which it is located (its position,
Conventional software tools are not able to describe the
performance or properties of the entities and their component parts. A
common feature in all mainstream CAD packages is the ability to transfer
files in Data Exchange Format (DXF). However DXF files are only able to
represent entities as a collection of points and arcs. They are not
able to carry additional information or parameters such as density,
thermal conductivity, etc., in a standardized way. The new generation of
CAD tools over-comes these limitations through the use of
object-oriented technologies. Entities are described by using
properties, which could include geometric information that can be
rendered graphically, and other information relevant to that entity.
There is considerable work at an
international level, both within the construction industry and in
commerce in general, that is developing methods for storing,
transmitting, and manipulating meaningful product data in an open
environment. Without such methods, the construction industry will
continue to be at a disadvantage because of the lack of integration
between its various proprietary systems. Projects will continue to
require labor-intensive and error-prone manual interpretation with the
reentry of information at the interfaces between different partners and
across the boundaries of work processes.
WHAT IS THE IFC MODEL?
Many of the issues discussed above are
already being addressed through the International Alliance for
Interoperability (IAI), a worldwide group of engineering professionals,
software developers, and researchers who are developing a building
product model, referred to as the Industry Foundation Class (or IFC)
Model, that permits an object-oriented description of many aspects of
buildings and related services (Figure 1).
The IFC Model development began around
1996 and is an extension of a number of earlier projects. It is not
intended that the IFC Model should describe every aspect of a building
down to the detail required by all of the engineering disciplines
involved in the construction process. This would make the building
product model too unwieldy. Instead, it is designed to describe the most
common parameters that may be required.
In order to facilitate the inclusion of
additional properties, the IFC Model includes a mechanism referred to as
"property set definitions." This mechanism allows the IFC Model to
expand on the properties that characterize an entity beyond what is
included in the IFC Model. A property set definition allows for the
sharing of standard sets of values across entities and for the
definition of different property values within individual copies of an
WHAT DOES THIS ALL MEAN FOR FIRE PROTECTION ENGINEERING?
There are several potential ways in which
the development of building product models might enhance the work of
fire protection engineers, and some of these are discussed here.
Although some of these concepts are not necessarily new to fire
protection engineering 2 the latest developments in the technology allow these ideas to be implemented now.
Improved exchange of building geometry
Building product models will facilitate
the automated import of building plans into computer calculation tools.
Although some currently available computer calculation tools can read
CAD floor plans, their facilities are limited. For example, the SIMULEX
egress model 3 has the ability to read DXF files, but these
files generally need to be edited manually prior to using SIMULEX
because of the limitations of the DXF format. In the future, building
descriptions will be exchanged in such a way that computer models can
more effectively make use of the data.
Property set definitions
Manufacturers of fire protection hardware
could publish property set definitions on their Web servers using
industry-agreed-upon classifications for the specific products. The
property set definitions would contain essential information required to
characterize the product such as physical dimensions, performance
metrics, and listing documentation. The definitions may also include
optional characteristics and characteristics unique to a particular
manufacturer. Thus, for a sprinkler, we might want to provide details
such as the model number, dimensions, Response Time Index (RTI),
temperature rating, construction material, organizations that have
listed the sprinkler, etc.
Standards, codes, and certification
Instead of being static paper documents,
standards and codes could soon be published as dynamic electronic
documents. This form of publication could lead to the automatic
incorporation of relevant code requirements in the design process and
documentation. Furthermore, the electronic publishing of listings and
certification will allow up-to-date verification that a product meets
any specific regulatory requirements.
Fire test databases
Fire test results and fire-related
material properties can be published electronically. These data can be
imported into an electronic building model using property set
HOW MIGHT A BUILDING PRODUCT MODEL AND PROPERTY SET DEFINITIONS BE USED?
Let us imagine that a fire protection
engineer wants to assess a sprinkler system using a computer fire model
in order to examine specific fire scenarios using a building product
model and property set definitions. An architect has already created a
description of the spaces in a document that uses a specified building
product model. The fire protection engineer can use this document in
order to complete their assessment in association with other relevant
parties and then pass the revised document on through the design
process. Thus, the building product document grows as the design
proceeds, with new information being added as tasks are carried out.
In creating the fire scenarios, the fire
protection engineer might need the rate of heat release from the
furniture items that have been identified by the interior designer and
specified in the building product document. At this point, the fire
protection engineer could access a database of fire properties in order
to select an appropriate design fire for the furniture. The heat release
data are extracted from the database and appended to the furniture
entities in the building product document as a property set definition.
The computer fire model now obtains the building geometry and furniture
properties (which include the rate of heat release) from the building
product document. At this stage, the fire protection engineer might also
obtain additional properties from an HVAC engineer (such as air
movement due to the ventilation system), the properties of the
sprinklers they intend to use, and information from the AHJ relating to
any code requirements. Since the sprinkler manufacturers publish the
property set definitions of their sprinkler hardware in a format that is
compatible with the building product model, the fire protection
engineer can directly import the relevant performance metrics such as
the temperature rating and RTI into the computer fire model.
Once the fire protection engineer has
completed the modeling and decided on an appropriate sprinkler design,
the building product document can be passed to the sprinkler installer.
The sprinkler installer could then use an hydraulic design tool to
determine pipe schedules, again using the building product document to
obtain pertinent information supplied by the fire protection engineer
and the sprinkler manufacturer. The completed sprinkler network is added
to the building product document ready for the quantity surveyor to
generate bills of quantities. Again, this is done through the building
product document by efficiently identifying the required pipe lengths,
etc. Finally, the bill of quantities can be related back to the
sprinkler manufacturer in order that a contractor can deliver the
correct hardware to the construction site. Figure 2 illustrates the
above sprinkler design and delivery process showing the linkages between
The above description is only one way in which a building product
model could be used. The example describes a linear process, whereas
some tasks might take place concurrently or at different stages of the
design process. The important aspect is that a single document is used
throughout, where each participant in the process uses information
supplied by others and adds their task-specific data back into the
building product document.
WHERE ARE WE NOW WITH BUILDING PRODUCT MODELS?
The above hypothetical sprinkler design
scenario is still somewhere in the future. Some of the tools that are
required to realize the above scenario are already available or under
development while others are a considerable way off.
The IFC Model The current version of the
IFC Model (2x) includes details of the geometry and topology of a
building and identifies walls, windows, doors, furniture, and HVAC
entities, many of which are useful to fire protection engineers. The
model has a very limited set of properties relating to fire protection
engineering. For example, walls, doors, and windows can be assigned a
fire resistance rating; fire and smoke dampers are included in the
model; stairs can also be given a fire-resistance rating and declared as
exit paths; and insulation materials have a flammability-rating
IFC-compliant tools There is an ever increasing range of
software tools appearing that are able to exchange IFC documents. These
tools currently include CAD (Figure 3), thermal design, quantity
take-off, model consistency checker (Figure 4), and others. There are
also a significant number of tools in development or under test
including HVAC design, energy simulation and code checking, electrical
system design, and the list goes on. In terms of fire protection
engineering, very little has been done so far. Preliminary work has
already been undertaken at the University of Canterbury into a tool to
interface IFC Model documents to CFAST.
Codes and standards Currently in
Australia, there is a move to provide the next edition of the Building
Code of Australia (BCA) in an electronic form. This will allow automatic
searching of the code for particular clauses relevant to a discipline
or specific building component. It will mean that the BCA could be
viewed on-line such that all clauses relevant to a particular discipline
or subdiscipline could be easily extracted.
Property set definitions So far, there
is little work on developing property set definitions for fire
protection engineering-related components. Some work has begun on
providing rate of heat release information suitable for incorporation
into the IFC Model, 5 and it is hoped new initiatives will expand on this work.
WHAT DOES THE FUTURE HOLD?
There is still much work to do before
seamless electronic data exchange becomes widely available. The IFC
Model contains only a certain level of detail regarding many domains,
and there is only a limited amount of information that relates to fire
protection engineering. However, the IFC Model already has a rich
description of the fundamentals of buildings, and the development of
domain-related information is proceeding through international efforts.
Software tools that are IFC-compliant are now available, and many others
are under various stages of development. As more tools become
available, so will the demand that additional tools be able to exchange
IFC files increase.
The next release of the IFC Model will deal with
Facilities Management, Structural Engineering, Codes and Standards, and
Building Services. There is some work already being undertaken to
describe specific building products using property set definitions.
Other issues such as the contractual and legal aspects of using
electronic building models, the ability to concurrently share data, and
the development of a lexicon of building terminology are also being
At this stage, it is important that the fire protection
engineering community be aware of the developments in building product
models to avoid being left behind. Developers of fire-related software
tools need to assess whether they should be enhancing their programs to
read and write building product models such as the IFC Model documents.
Manufacturers of fire protection-related hardware might consider the
formulation of agreed-upon property set definitions. Regulators might
want to consider alternative means of publishing codes and standards.
The use of Information Technology and computer-based software tools will
continue to grow in both the construction industry and more widely.
Building product models and their associated technologies will play an
important part in integrating this growth.
The author wishes to thank Andy Buchanan,
University of Canterbury, and Robert Amor, University of Auckland, for
their helpful comments during the preparation of this article.
Michael Spearpoint is with the University of Canterbury.
- Liebich, T., and Wix J., (eds.), IFC technical guide, Industry Foundation Classes Release 2x, International Alliance for Interoperability, October 2000.
Mowrer, F. W., and Williamson, R. B.,
"Room fire modeling within a computeraided design framework." International Association for Fire Safety Science. 2nd International Symposium, 1988.
Thompson, P. A., and Marchant, E. W., "A
Computer Model for the Evacuation of Large Building Populations," Fire Safety Journal 24 (1995), pp 131-148.
- Industrial Use of the Building Modelling Approach. interop AEC+fm 2001, Sydney, Australia 2001.
Spearpoint, M. J., The development of a
Web-based database of rate of heat release measurements using a markup
language. 5th Asia-Oceania Symposium on Fire & Technology, Newcastle, Australia. 2001.