The Potential Impact of Building Product Models
Share |

The Potential Impact of Building Product Models

By Michael Spearpoint | Fire Protection Engineering

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.

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.



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 broad environment.


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, orientation, etc.).


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.


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 entity.



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 definitions.


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 each step.


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.


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 property.
  • 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.

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 investigated.


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.



  1. Liebich, T., and Wix J., (eds.), IFC technical guide, Industry Foundation Classes Release 2x, International Alliance for Interoperability, October 2000.
  2. 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.
  3. 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.
  4. Industrial Use of the Building Modelling Approach. interop AEC+fm 2001, Sydney, Australia 2001.
  5. 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.

© SFPE® | All Rights Reserved
Privacy Policy