There are two major schools of thought on how this data should be accommodated and incorporated into a BIM: the central repository concept and the distributed repository concept. The central repository concept is quite popular with architects and with the CAD vendors who sell software to them. The idea is that the data comprising a 3-D model of a building would be expanded to include all sorts of additional nongraphic data about the building, and all the data would be contained and maintained in a single database. According to this concept, the BIM would include all the quantities of all the materials and products needed for the building, so if the cost of each material were added to the data, the BIM could be queried for a detailed cost estimate. In similar fashion, all the necessary specifications data would be attached to the respective building elements in the BIM, allowing a complete set of specifications to be generated on demand. In theory, the advantages of a single-package BIM would be considerable, including greater efficiency because of the elimination of data duplication.Let's pause to ask a couple of questions here, and then try to provide some answers.Could specification documents and cost estimates as we currently understand them be eliminated and replaced by new functionality in a well-developed 3-D model?If not, could we add enough data to a 3-D model to effectively generate the specifications and cost estimate documents?The answer to the first question is negative, unfortunately. Central repository BIM proponents presume that, because a 3-D model contains objects representing building products with attributes that define their properties, there could be sufficient information in the model to eliminate the need for specifications and a detailed cost estimate. However, there are other factors to consider in both applications. Specifications cannot be eliminated as long as construction contracts require stable, human-readable documents that establish the legal requirements governing the obligations of the parties to the contract. A formal cost estimate might be eliminated on the owner's side of the table, but it is difficult to imagine how we would propose to eliminate the need for a detailed and stable cost estimate prepared by the contractor that results in a formal proposal or bid and subsequently generates a schedule of values for payment.
Figure 1: The idea behind the central repository concept is that the data comprising a 3-D model of a building would be expanded to include all sorts of additional nongraphic data about the building, and all the data would be contained and maintained in a single database. In theory, the advantages of a single-package BIM would be considerable, including greater efficiency because of the elimination of data duplication.Image: BSDView larger image
OK, then, if we can't replace these documents with the 3-D model, can we pack in enough data so the model can actually generate the specifications and cost estimate? Unfortunately, the answer to the second question is also negative. Even if the required products could be described using only the properties stored in the 3-D model, the specifications must contain other important information such as requirements for quality control measures, workmanship, auxiliary products not actually included in the model, and administrative procedures. The cost estimate also must include provisions for items and processes that are not actually part of the 3-D model. For instance, a detailed cost estimate must account for temporary facilities and earthwork that are not part of the finished building. It must also include various overhead costs and the cost of waste. The major difficulty with the central repository, or shared data concept, however, is that multiple software modules are needed to manipulate the data. It would be unreasonable to expect the 3-D CAD software to incorporate all the functionality of a detailed cost estimating program and a specification writing program. Consequently, separate programs would have to have access to the common database. Such a scenario would seem to be highly unlikely, especially if the various programs have been developed by separate companies, with expertise in specific areas.
This leaves us with the distributed repository concept. What exactly is it? The basic idea is that the BIM is actually a collection of separate databases maintained by different programs. These separate programs communicate in a way that allows them to exchange at least some of their data for better project coordination. However, the CAD program is not burdened by the need for elaborate cost computations and text manipulation, and the project data remains distributed and specialized for use by the programs designed to manipulate that specific type of data (graphics, text, or numbers). This software interoperability approach using distributed data is, we believe, the only viable direction for software developers in pursuit of better construction project coordination - at least for now.
Figure 2: The distributed repository concept states that the BIM is actually a collection of separate databases maintained by different programs. These separate programs communicate in a way that allows them to exchange at least some of their data for better project coordination. The CAD program, however, is not burdened by the need for elaborate cost computations and text manipulation, and the project data remains distributed and specialized for use by the programs designed to manipulate that specific type of data (graphics, text, or numbers). Image: BSDView larger image
How would separate software programs exchange or share data for better coordination? Would we want the data from one program to make changes in other programs, or would we simply want the data about what is happening in other applications to be available for information? Should the data exchange be in real time, or should it be available only upon request, in batch format? In theory, there are a number of possible ways to share information between applications:
- Transfer data from one application to another in order to make changes in the second application (active - one direction).
- Transfer data between applications in both directions to make changes in both applications (active - bidirectional).
- Transfer data from one application to another in order to inform the second application (passive - one direction).
- Transfer data between applications in both directions to inform each application of the status of other applications (passive - bidirectional).
- Compare data from multiple applications in a neutral context to verify correlations and identify conflicts (passive - multidirectional).
- Provide a look-up capability that allows any application to find corresponding data within any other application.
Each of these approaches has advantages and disadvantages. The one-direction schemes, however, are inherently limited and limiting. They would require work to be accomplished only in a specified sequence and therefore would give priority to one application over another. For example, information extracted from the CAD drawings in theory could "inform" the specifications or actually edit the specifications, but choices made within the specifications would not be made available within the CAD environment. In similar fashion, products included in the specifications could be made available to the cost estimate, or vice versa, but the transfer would not be reversible and would mandate what is to happen in the downstream application.
The bidirectional approaches allow more flexibility in work sequencing, but it's not difficult to imagine that data appearing within one program about project status in other applications could easily become quite confusing. And if the information from each program has the ability to make changes in other programs, the results could quickly become chaotic.
This leaves us with two approaches - comparing data in a neutral context and providing a look-up capability. Individually, these two approaches would have limited utility. Comparing data in a neutral context would not be especially helpful without the ability to highlight the specific location of conflicts in each application. The look-up capability would be cumbersome to use if there were no way to identify which areas were in conflict. Combining the two approaches would seem to offer the most reasonable way to approach the problem of useful exchange of data between disparate applications. Such an approach would be analogous to interference checking between CAD disciplines. Instead of highlighting the location of a structural member that penetrates a duct, the interoperable approach we are suggesting would indicate a conflict between the data in separate applications and would allow the user to assess the specific situation in each application. For example, if the cost estimate assumed composite floors and the drawings indicated post-tensioned concrete slabs, the neutral comparative environment would highlight the disparity, and clicking on the data would open a window at the appropriate location within each application.
A Brick is a Brick is a Brick
If the electronic interoperability we have been discussing is to work without the necessity for human intervention, there must be agreement between the applications on the meaning of the data that will be transferred. In other words, each application must agree that a brick is a brick is a brick. They must agree not only that a particular object is a brick and not a CMU, but also must agree on its particular attributes. The CAD environment will be most concerned about its dimensions, the specifications environment will be most concerned about its physical properties, and the cost estimating environment will be most concerned about its cost, but they all must agree that it is the same object in each program. Otherwise, electronic interoperability simply cannot work.
How is this agreement about the identity of specific objects to be achieved? If we draw a brick wall, specify the masonry, and include a brick cavity wall in the cost estimate, how can we automatically determine if we are talking about the same object in each case? The answer sounds deceptively simple. The objects in each environment must be "mapped" against a common organization, or taxonomy. In the absence of an established standard taxonomy, any two applications could be mapped against a common descriptive structure, and they would thereafter be able to communicate effectively. If the communication is to be extended beyond the initial two applications, however, each additional application would have to be mapped against the same data. Today there are a few construction software applications that allow data to be mapped against a list of objects. Linking the data in two applications then becomes a process that involves matching text strings such as those found in keynotes, tags, and element properties. If the strings match, the connection is made. If the strings don't match exactly, the connection is not made, and the information is not transferred.
Today, an architect could "hard wire" a set of keynotes from his 3-D CAD program to a set of specification sections in such a way that the presence of those keynotes on the project drawings would result in the same set of edited specifications. For example, a product called e-SPECS® from InterSpec is available that will work with AutoCAD®, AutoCAD Architectural Desktop®, and Autodesk Revit® to cull information from the CAD environment, then match it up with the options in a prebuilt Masterspec® checklist that in turn edits a set of Masterspec text files. The communication is in one direction only, however, and the connections must be mapped by each user.
Standard Taxonomy for Meaningful Interoperability
What is missing from the market at the moment is a viable standard taxonomy that every construction software application could use as a template for premapping its own data. Such a standard taxonomy would have to include properties and values, in addition to product names, in order to achieve meaningful interoperability. It's not enough to know that an object is a door or even to know its dimensions. To specify it or estimate its cost, we need to know what it's made of and how it's made. Is it wood or metal? Is it fire-rated or sound-rated? What type of finish does it have? Et cetera.
The outline for such a standard has been emerging for the past few years from the OmniClass™ Development Committee established by The Construction Specifications Institute (CSI) and Construction Specifications Canada (CSC) and subsequently endorsed by the International Alliance for Interoperability (IAI). Unfortunately, because the committee comprises all volunteers, the development of the standard has been languishing of late. See www.omniclass.ca for additional information on the current status of this standard.
So, what can we conclude from this admittedly brief overview of BIM as it affects specifications and cost estimating? We know that the concept of interoperability has a lot of adherents, and we know that a lot of people are working to achieve meaningful interoperability. After all, the idea does seem to hold a lot of promise. We can all imagine a not-too-distant future in which an architect can design a building in three dimensions, assign properties to the various building elements as the design is developed, and then "push a button" to have the software generate a detailed quantity takeoff of materials, produce a complete cost estimate, and print a finished set of specifications. Alas, that day is not yet here.
On the positive side, there are a few applications available today that have made a few steps toward true interoperability, and other developments are in the works. Our prediction is that useful interoperability between CAD, specifications, and cost estimating will occur within the next 3 years and will be characterized by a neutral interface that will allow comparisons between the data in each linked application. It will be possible to query the comparative data for conflicts and then click on a conflict area to see the location of the mismatch within the affected application. Underlying the interoperable system will be a standard taxonomy of data that will allow any building assembly or product to be classified, both by its name and its relevant properties. When such a system becomes available, the next challenge will be to change office practices to take advantage of the new technology. In our experience, getting design professionals to embrace the new technology will be almost as difficult as developing the technology in the first place.
Robert Dean is president and chief operating officer of BSD. He is responsible for day-to-day business administration and for new business development and is also one of the most experienced and knowledgeable experts on automated specification systems in the country. Susan McClendon, a registered architect, is executive vice president of BSD. She is project manager for BSD SpecLink®, which now includes CSI-DBIA's PerSpective®. She manages the ongoing data development and updating of BSD SpecLink and also manages the maintenance of BSD's website.
ARCHI-TECH welcomes comments on the distance education program, including its content, format, and process for AIA/CES learners.
Please contact Maureen Patterson at (319) 364-6167 or [email protected].
Stamats Buildings Media, publisher of ARCHI-TECH, is the provider of ARCHI-TECH'S AIA/CES distance education programs. Stamats Buildings Media's provider number is J683.
