Tip:
Highlight text to annotate it
X
The Future of Specifications >>Andy: Good afternoon. Welcome to the discussion
on The Future of Specifications. BIM, BIM, BIM! BIM seems to be everywhere, but do you
hear anybody talking about specifications? It's just not a discussion that's front and
center. Will specifications always be written by a separate task towards the end of design,
or can imagine specifications integrated within the BIM design environment?
The architectural engineering and construction industry is transitioning from paper to digital-based
deliverables, and specifications are perfect for the inclusion in digital deliverables.
[AIA Learning Objectives] Hello, I'm Andy Smith, architect and Solutions
Executive for Bentley Systems, and a member of the AIA/TAP Advisory Group. Following today's
webinar, we hope that you'll be able to lead a discussion within your firm to consider
project workflow requirements to support specification automation and discuss the concepts of integrating
specifications within the BIM Workflow. [Copyright Statement]
We'd like to remind you that we have invited three industry leaders to present today. I
have to remind everybody that these presentations are copyrighted and their contents cannot
be used without permission from the speakers. [AIA/CES Compliance Statement]
The "AIA Knowledge" is a registered provider with the American Institute of Architects
Continuing Education Systems. Therefore, through your participation today, learning credits
will be reported for AIA members. Also note that certificates of completion for both AIA
members and non-AIA members are available upon request. You should also note that the
AIA does not approve or endorse any products or services presented during this webinar.
[AIA/CES Reporting Details] As noted, all attendees will be eligible to
receive one learning unit for AIA continuing education, and at the end of today's program,
you will be e-mailed a form to apply for the continuing education credits.
[Acknowledgements] This webinar, the BIM Awards Program, Building
Connections, and other activities are funded by the sponsors of the AIA Technology in Architectural
Practice Knowledge Community. Therefore, we would like to thank our sponsors ARCOM, Newforma,
Graphisoft, and Bentley for their support. [Today's Speakers]
We're fortunate to have three industry leaders presenting today. Let me introduce you to
them: Rob Dean is the president of Building Systems
Design. He's an expert in automated construction specifications and responsible for the creation
of BSD SpecLink. He designed and managed the development of BSD LinkMan-E which provides
interlock ability between BIM and BSD SpecLink. Michael Brennan is president and co-founder
of InterSpec. He pioneered the integration of building information models and specifications
with e-SPECS technology. Prior to founding InterSpec, he developed a graphical information
system, engineering software and hardware systems for the Science Applications International
Corporation and the Department of Defense. Mark Kalin is president of Kalin Associates.
He's current co-chair of the CSI Sustainable Facilities Practice Group and past chair of
the AIA Masterspec Review Committee and CSI National Technical Committee. He's also past
president of the Specification Consultants in Independent Practice.
Rob, let's get started with our discussion. [Do Specifications Even have a Future?]
>>Rob: The first question to answer is: do specifications even have a future? As Andy was indicating,
things are changing in the industry, and BIM is, of course, one of the big changes that's
going on right now. Some people expect that construction specifications will go away altogether
as BIM becomes the real modus operandi producing construction documents. A BIM (Building Information
Model) in theory could contain all the information needed to construct a building, including
lots of information about every product that goes into the structure.
There are a few little problems, however. For example, specifications really include
more than product information. There are all kinds of administrative details, for example.
Where do we talk about sample submittals? Where do we talk about quality control requirements
associated with both the products and the installation of those products? Where do we
deal with things that aren't even shown in the building like temporary facilities and
controls? We also have an issue about legal documentation.
After all, contract documents, as we call them - the drawings and specifications that
are produced today - are legal documents that can be referred to subsequently, especially
in a courtroom. How would we handle those if all of the data about a building was encapsulated
in a BIM (Building Information Model) that could be changed at any time?
Specifications as legal documents will continue to be required. They could produce, let's
say, out of a BIM a snapshot, if you will, that would then be signed by everybody. But
there are problems with that as well. Where is that information going to be retained?
Where is it going to be formulated? How is going to be reported?
I will say that the future of specifications is inextricably tied up with the future of
BIM, and as we move more into the BIM era, there will be change in how specifications
are produced and updated. [What is BIM, anyway?]
Let's start with a quick definition of BIM. This is from the official National Building
Information Model Standard by buildingSMART alliance which is part of NIBS, the National
Institute of Building Sciences. That definition is "A digital representation of physical and
functional characteristics of a facility... and a shared knowledge resource for information
about a facility forming a reliable basis for decisions during its life-cycle; defined
as existing from earliest conception to demolition." A basic underlying premise of BIM is that
it is really a collaboration. Lots of different people at different phases of the project
are going to be inserting, extracting, updating, and modifying information because every stakeholder
has a different set of goals. The BIM is a shared digital representation founded on open
standards for interoperability. Notice that in this definition, there hasn't
been anything said about 3D Cad or 3D models or anything of the sort. It's "a shared digital
representation founded on open standards for interoperability."
The facility life cycle starts off with programming, moves into design (including the production
of contract documents), then into the building phase, and then of course operation of the
building which is what we're dealing with most of the time. One of the big advantages
of BIM is supposed to be that the facility managers are going to have an opportunity
to use this model throughout the operation of the building, leading to renovation and
ultimately to decommissioning and demolition. [BIM is more than 3D modeling. How is it different?]
It's true that there are 2D and 3D CAD program out there today that store information about
materials and products other than those properties that are needed to present the objects graphically.
That is absolutely true. But, there are lots of properties that would be needed for a complete
specification, and for that matter, for cost estimating and scheduling that are not relevant
to graphic representation. If we stuck them in a 3D CAD program, we would
really start to affect the speed and operation of the software. I think those of you who
are doing hospitals, for example, in BIM know how enormous those files are and how difficult
it is to deal with them currently. In Revit, for example, there are lots of door
objects provided in the software, and they deal with things like height, width, thickness,
and swing direction. Those properties are included, but they don't include a lot of
information that would be needed to prepare a detailed cost estimate or to produce detailed
specifications. For example, with the model objects that are
provided with Revit, we don't know whether the doors are wood or metal. That's pretty
basic. After all, wood doors and metal doors are specified in completely different sections
and they have very different properties, and they certainly have very different costs.
The drawings, of course, do not include all elements that would be needed for specification,
scheduling, and estimating. One quick example would be earthwork. Another example would
be temporary facilities needed during construction. And, of course, programming, specification,
and cost estimating tools don't include any of the graphic information that would be needed.
So a BIM (Building Information Model) has lots of information of various types that
really can be stored and manipulated in different places. There are two fundamentally different
ideas about how this data should be stored for use during a facility's lifecycle.
There's a centralized data concept. This is kind of a traditional idea that the CAD program
is going to contain everything needed about that building. There is another idea that
distributed data is the way to go. This is, of course, one that I'm advocating - distributed
data with linkage. This is kind of a traditional idea about how a BIM should work. Cost estimating
information is fed into a database; specification information is fed into a database. And all
of that information about a building - a project - is stored in one huge database, and the
CAD system is envisioned as the way in which this data is manipulated, accessed, and reported.
A little cumbersome, I think. A better way, and the way I think we're headed,
is that the CAD application maintains graphic information and manipulates the graphic information.
The spec application maintains the information needed to produce specifications. Cost estimating
application includes and up-to-date database of cost information and manipulation of that
information. What we have in the middle is a standard taxonomy,
a classification system for all of the information so that these various applications can talk
to one another in both directions. So the Building Information Model is really a distribution
of data that is managed by what I'm calling an interoperability manager.
[How Can Linkage Be Achieved?] So how does the linkage occur? How do we achieve
that linkage? When we talk about interoperability, CAD people talk about it in terms of disciplines.
They talk about the architectural drawings being interoperable with the structural engineering
drawings and with the mechanical drawings and with the electrical drawings.
When I'm talking about interoperability, I'm really talking about dissimilar applications
talking to one another. Here's what I believe. The applications need to be relational databases
in order to talk to one another, and the relevant objects - projects, assemblies, spaces - need
to be identified or tagged with unique identifiers. GUIDS are globally unique IDs. These GUIDS,
in turn, ultimately need to be linked to a central data repository, probably out on the
web somewhere, that is based on a standardized set of properties. So we need relational databases
to talk to one another, and we need - and this is really critical - something in the
middle that I'm calling globally unique IDs organized so that we're all talking about
the same objects. To achieve true interoperability, you've got
to have relational databases because the detailed linkage required to be useful requires access
to individual records. For example, in specifications, we can connect not only to individual paragraphs,
but also to choices that are imbedded within those paragraphs.
We cannot really deal very comfortably with flat files such as those that you would get
in a word processing system or in an Excel spreadsheet. You really need to be able to
access information at a much more detailed level, and that's why I think relational databases
are essential. Cost estimating is another example. Line items
in a cost estimate have specific costs associated with them. A brick is not a brick. There are
lots of different kinds of bricks. They are different sizes and shapes, but they're also
different compressive strengths, different weathering qualities, and so forth. We need
to know through a globally unique ID and through use of these Globally Unique IDs in relational
databases that we're talking about the same object.
I mentioned the taxonomy earlier. What I'm really talking about is a master database
of construction information. In that central database, every application that needs to
talk to another application could map their data to that central database so that all
applications would then be able to talk to one another. CSI has a number of standard
formats including UniFormat, MasterFormat, and OmniClass, that could form the basis for
such a globally unique ID taxonomy. [Is There Currently any Linkage?]
There is. There are architects out there who are using products that are on the market
currently to connect their BIM/3D CAD information with specifications and with cost estimates.
As far as I know, there are only two commercial systems on the market at the moment that demonstrate
a level of interoperability between BIM and specs, and that's e-SPECS by InterSpec and
BSD SpecLink-E and LinkMan-E by Building Systems Design.
[What They Have in Common] They have a lot in common. For one thing,
they both employ relational databases. They both employ a translator, or an interoperability
manager as I called it, between BIM optics and spec text. e-SPECS uses an approach called
mappings and a section checklist to bind BIM assembly codes to corresponding text in the
specifications. LinkMan uses a somewhat different approach
- a master database of assemblies and products that are linked to BIM elements by unique
names and to individual paragraphs in the specifications.
Another example of what they have in common is that they both provide keynotes to relate
the BIM elements to corresponding specifications. And they take slightly different approaches
to that. [How Are They Different?]
There are lots of other things they have in common and there are lots of ways that they're
different. How are they different? I think it's best explained by our owners [20:37 ?], and
I am going to turn it over to Michael Brennan, who is the president of InterSpec. Michael,
you should have the control. >>Michael: Thank you, Rob. This is Michael
Brennan from InterSpec, The Future of Specifications from Document Management to Information Management.
As Andy mentioned at the top, everyone is talking about BIM, but it's not just about
integrating the specifications with the building models. Much of the "I" in BIM comes from
the specifications. It's really about how we better access and use the information that
we integrate with the models and how we better manage the data that is mostly contained in
specification documents at this point. The future of specifications is really about
moving from a document management process to an information management process so we
can more efficiently access the data and specifications for all of the construction disciplines that
need it. There are many advances made in the preparation
of specs as we have moved from a paper based process to a digital based process. By and
large, the development over the years has been on better management of the spec documents,
not necessarily on the management of the data contained in those documents. We've developed
a number of good document indexing schemes like MasterFormat, UniFormat, and OmniClass,
for referencing the information. We have a well-placed structured standard for the presentation
of the specification information on section documents.
This is a tried and true system that has worked well for many years, but it is a system that
was developed in an era when the drawings were paper based or printed CAD drawings when
the reference to the specifications had to be by imitations or keynotes on
the drawing. This is still the way the industry works for the most part today.
Building Information Modeling (which Rob went through in great detail explaining, which
is great) which first started to gain traction a decade ago is transforming the design, construction,
and operation process into an information driven one, spawning such advancements as
automated engineering analysis, energy performance predictions, class detection, construction
sequencing, etc. It is now possible to better integrate the
drawings and specifications, as we have direct digital access to the visual context as well
as digital access to all of the components that make up the building, from the foundation
to the roof pavers and all the building elements and systems in between. And it's not just
digital access to a symbol or a pattern or a text callout of those elements as we did
with CAD. We now have detailed information about all of the building elements that you
can use in the development and dissemination of the specifications. We need to take advantage
of it. Advancements have certainly been made in terms
of integrating the specifications with the models. These are proving successful in better
coordination and development of the specs from the model context, and better collaboration
of the spec preparation process during design. But the access of the specifications for use
in estimating, bidding, purchasing, fabrication, construction, operations, etc., it is still
by and large through a text based documents. We're still using annotations and keynotes
to reference the specs from the models. There are some initiatives on the way to standardize
the spec information for direct data exchange among applications, like the Specifier's Property
Information Exchange that you'll hear more about later.
There are other systems that are using direct application-to-application proprietary interfaces
to accomplish this. But for the most part, the information is really locked up in a series
of text based documents, and the industry users still get the required spec information
from a project manual document. This is where I see the opportunity for the
long range future of specifications in better management of data that is contained in the
specification documents so that the information can be provided to the users in the format
and structure required - machine to machine where appropriate, from visual context in
the model where available, and from documents built up from the data when needed.
How do we get there? The specification information has to be structured as portable data that
can be accessed and formatted for a variety of applications and users requiring it. If
we want to pass the specification information to other applications, it needs to be well
structured so that both ends can interpret the data, and available for transport in the
data structure, like XML [? 26:07], for instance. Evolving standards like COBie and SPie will
help this process, but until they are fully adopted, we are doing this with proprietary
application programming interfaces. If we want to view this specification information,
we should be able to access it from the model context in the form we want through various
view templates. This is analogous to how some parametric BIM systems work today.
Plans, elevations, and section drawings are just different view of the BIM graphical data.
The views of the specification would be similar: different views of the spec data depending
on the requirements of the user that is accessing it. If the models are available to the user,
provide a spec view from the model context. Make it visual.
The development of the specification should be an integral part of the development of
the building designs. Drawings and specs have always been developed in parallel - or at
least they should be - but now we have the ability to truly develop them together with
a model context and access to the specification data which will facilitate the overall design
process. This does not mean putting all the extra information
in the models themselves. Rob pointed this out earlier. We get asked this question all
the time: "How much spec info should I put in the model?" The models are already large
enough with the geometry data and more. The specification information should reside external
to the models where it can be conveniently accessed by other applications and users.
We want to provide a reference to the specification from the model element and keep as much of
the data external, but have the model context and access to the model data for the spec
development. Specification data should be conveniently accessible to all of the construction
disciplines that need it. In the long term, we cannot continue to make
downstream applications and get a copy of the data set to provide locally inside their
firewalls. We would need to have the specification data available from shared online database
servers with convenient secure access to all that need it. We increasingly have widely
distributed project teams working on fast track projects all over the world where everyone
needs access to the project information as soon as it is available.
For example, our services group recently worked on the specification for a health care project
in California which was structured as an IPD project where the builders were located on
the site in California; the designers were located in Arizona; the specifier [28:43 inaudible]
on the East Coast; product consultants in California, Washington, and Texas; and the
engineering team spread across a half a dozen or so other locations. Convenient online access
to the information was absolutely critical, and this is becoming more common even on the
smaller projects. We did not have that level of integration
on that project, but as an example, it would have been much easier and more expedient if
we could have just provided the data access credentials and templates to the various users
and applications that required the spec information that was developed and then been able to pass
other information on for use in post-construction, facility management, and beyond.
Better access to the specification data will make the integration on the applications used
by the various construction disciplines more accurate and less time consuming to maintain.
In addition, online model and information access to desktop machines in the construction
trailers at job sites is fairly standard now, and the demand to have construction related
information available to mobile devices is increasing. In terms of the need to view the
information and specifications, this will further drive the need to have good contextual
references to the models with information specific to the construction components of
interest. Access to a 1,000-page specification manual on your smartphone to get some information
about the concrete slab will just not cut it.
The following is one example of how the view of the data might look:
For the contractor that needs information about the concrete columns on the job site
(shown in blue on the model), or perhaps the details about the slab-on-grade (again shown
in blue on the model), they should be able to access the specification and technical
data directly from the visual context as we're showing here for the slab-on-grade only, as
well as any other relevant information like installation details, product data sheets,
or other information that is contained in the specification (or referenced on the specification)
to the specific product, material, or element of interest.
This is certainly more efficient than lumping all similar elements together, as we show
on the model. All the concrete in the building that we can see from this view (in blue) reference
to a MasterFormat section - the Cast-in-Place section in this case - in parsing the desired
information from the Cast-in-Place PDF document. It's much more efficient if we can just focus
specifically on the data for the element of interest we're looking at, and we can only
do that if we have better control of the information that's currently contained in the documents.
These are just a couple of brief examples, but I think you can see that if we have better
and more discreet access to the specification data, we can accomplish much more with it.
The specification information is used to one degree or another by many industry disciplines,
and providing better access to that information to the project team members in the form they
need it, when they need it, and where they need it is the opportunity ahead.
BIM is certainly the catalyst that is transforming our industry, and the future of specifications
is really about helping to fulfill the promise of BIM.
Thank you. I'm going to pass this over to Mark.
>>Mark: Thank you. In my role as a specification writer, I've often wanted to shake the BIM
model and try and catch the spec information as it's dropped out. Unfortunately, as hard
as I shake, it doesn't come through. Where is this going? We've got a limited number
of spec writers. We've got people being trained on how to do designs and how to do BIM - maybe
not exactly on what the specifier needs. If we start from the basics, the old joke is
that I'll tell you everything I know in twelve minutes, and I suppose I can actually do that.
What's a Spec? The designer calls and says, "I want to use
a Mars ClimaPlus ceiling," and there's the texture of it and it has an NRC of .70. Maybe
that's where it contributes to LEED credits. So you turn to page two of the product literature
and you realize there are three corner shapes; there are seven sizes; there are seven grids.
[graphic] So until somebody makes that decision, it's
not really a spec, meaning that I know my role as a spec writer. It's to defend the
designer's design intent, and also to not confuse the contractor's estimator. They're
trying to big a job in a month. They look at it for a week; they estimate it in a morning.
It really does have to be as clear as possible. So we make all of these decisions and then,
as a good spec writer, I'll put that into a CSI three-part format spec - part 1, general;
part 2, products; part 3, execution. Here are the exact same words as the previous page
on the product literature, except I've added two more manufacturers. The first one was
USG 86985. Now we've got an Armstrong 1912 and a CertainTeed 122BF, and that is hard-fought
data. [graphic]
Why do I need the other information? It usually has to do with the fire and sound performance,
maybe the LEED criteria. The important thing is why the product was picked.
We take that exact same information - here's our part 3 execution of this spec and there's
a paragraph that says, "Level the ceiling to within an 8th of an inch and ten feet in
both directions." Where's that going to live in the model? How is that going to work?
[graphic] We take this same information - remember that
we were talking about the product literature, we were talking about the spec - and we put
it into a BIM model and we find that it's exactly the same words. Think of it as an
outline spec perhaps. The basis of design can be there. You can have 15,000 lines in
the model describing something. It's not a problem to list equals. It's not a problem
to list performance. [graphic]
And right now most of us are in the situation in our offices where we don't know that anyone
is going to look at this information later, and no one's paying us to put it in. So until
that model changes, nothing more may change as far as the architect's incentive to get
more information in the model. But it is changing because there are owners who are paying architects
to do this, and on and on it goes. As we look downstream from where we are, we
have to understand that old phrase, over 20 years, the cost of a building - 5% is the
initial cost of the building and 95% is the salaries of the people who work there. So
the architects do their best to look downstream because that building is going to come around
and around again. There are 105 million buildings in this country. 50-60 million of them are
more than 50 years old. We're going to be really busy.
[graphic] We start in design with schematic design and
design development drawings. I get involved as a spec writer during bidding, as many of
you do. You're involved with design and cost estimate. Then finally, we go to build the
document. The AGC, I'm told, is that the number one
trainer in BIM because the subcontractors get it. If you cannot have a Sawzall as your
number one job site tool, you're going to make more profit and the building's going
to open on time. Finally, the people who have to run the buildings
have developed a whole different priority. If you're the government (GSA owns 9,000 buildings;
the military owns 113,000 buildings) there is a huge incentive to make this work.
[graphic] [CSI and Its Formats]
Why does it all work? It all works now because it works in paper. We've got UniFormat; we've
got MasterFormat; we've got the national TED standard used by 4,000-5,000 firms; overlays
of different types, whether it's LEED or Green format; then there's OmniClass which is 23
tables. So there is a structure, and there are committees from the AIA, CSI, Building
Smart Alliance, and others that are really trying to just simply get a data dictionary
set in place. It's so critical so we can speak the same language.
[graphic] [Information Formats and Standards]
We've got our information formats. I fell in love with these as a spec writer. We know
when to use UniFormat and MasterFormat. We know OmniClass. So BIM, at some level, is
going to allow this all to happen in a less paper-heavy environment. As Michael said,
before, you'll be able to view things in any way that you way. For those of you who grew
up with CSI, you recognize this slide where you've got a difficult project manual, drawings,
addenda, and all the definitions. None of this is going to go away because our industry
is slow to change. Specifier's Property Information Exchange
(SPie) But two things have happened. There's the
Specifier's Property Information Exchange. It's been supported by the U.S. Army Corps
of Engineers, NASA, Overseas Building Operations, National Institute of Building Sciences, Spec
Consultants in Independent Practice, Construction Specifications Institute. It's trying to capture
design phase decisions in the model, and it's trying to catch product templates for the
manufacturers as well as from the manufacturers. Since 2007, there have been 300 property sets
- specifier's templates - on the NIBS website. They've evolved a little bit on time. (All
of this I'm talking about is free and downloadable.) The manufacturers are so trying to connect
with us, so trying to make sure that we use their products correctly that, as you go onto
the sites like McGraw Hill, ARCAD, Reid [39:53 ?], and others, you see hundreds and hundreds
of manufacturers with their information online. At this point it's not like the movie "Avatar."
It's like the TV show "The Simpsons." We're just trying to get enough data in there.
Construction Operations Building Information Exchange (COBie)
I don't know if everybody has heard of COBie (Construction Operations Building Information
Exchange), but this is really a driver. It was started by the U.S. Army Corps of Engineers
and NASA almost ten years ago to deal with a lifecycle capture of information - what
is it that's going to be in the model that somebody else is going to look at?
It really is the U.S. standard right now for the exchange of information. There are 20
software products right now that work with COBie. Perhaps it's just keeping track of
the fan size and the pump size and the serial number, but these are the things that cost
millions and millions of dollars in waste when we can't understand what's in our buildings
and why they work. Here's an example. We took 490 sections of
the Unified Facilities Guide Specifications and said, "What do we care about as a specifier?
What are the specifier's attributes?" This shows the COBie attributes. What's the name
on the product? What's the basis of design manufacture? Where is it located? A system
description. Perhaps something on sustainability. [graphic]
As we go further, we see in the Unified Facilities Guide Spec that there's a lot more information
that's there. In other words, if you go to the Steel Door and Frame section in the UFGS
and you want to know if the glazing type is in the spec, and you went to UFGS paragraph
2.13, you'll see that the choice are tempered and laminated.
[graphic] As a specifier, we know that there may be
50 choices on each one of these lines. But if we look at a fixed database of the UFGS
spec which, altogether, is 21,512 pages, this is what's in it now. To be fair, UFGS was
never really designed for BIM. It's been around for 40-50 years, starting out as the original
specifications for each of the different industries - but it's there. Whether you want the fire
label rating or you want the 4th century bullet resistance code, these are the things that,
right now, a specifier has to deal with, a designer has to deal with, to put that spec
out to bid. Here's another basis. Right now, [42:44 inaudible],
SEARLE [?], and buildingSMART alliance have populated three BIM models with attributes
so that people can see what it is they want to do and not do. We're a little bit in the
wild west, but having those 300 original sections and now 500 more sections from UFGS, and with
what Rob and Michael are doing with their systems, we're getting there.
Here's another UFGS SPie template for a commercial boiler. It starts out with a COBie guide,
which are things that are really important to the location and the model, and also to
the people who use the information that's there. The boiler section is probably 100
pages long. How can you condense it one page? Well, you do because you can always refer
back out to it. The specifier's role is really changing. Believe
it or not, in the '20s the best thing to do was to print these books. That's about all
we could do. But now in that model, we can have our lumber cut. We can change the light
level. We do our wastewater calculations. We can just get the owner a better building.
Now the information runs really deep and, at some level, gets terrifying because even
with something as simple as the example we used before with acoustical mineral fiber
ceilings, you've got, in Revit, a family and a type. You've got built-in keynotes - maybe
they're terrific; maybe your office as their own. There are probably five CSI MasterFormat
numbers that represent ceiling. There are six UniFormat numbers that represent it.
With your cost code, by the time you get down to that two-by-four tile, you've got an 095123300830
number that kind of roles off the tongue, and you've got seven credits that this ceiling
could contribute to if you're dealing with LEED. The information could go phenomenally
deep in orienting where you are what you're trying to do.
Construction, Construction Management So we've got a door, and each of those doors
can have element properties in a model. You can define those. You can use the defaults.
I know that the 300 manufacturers on ARCAD have links out from their models to their
website. How do you get it out? You create a schedule.
This is just a picture of a Revit model. There's a button called "Schedule." You pull out the
type of schedule you want, you build a database much like you do in Access. This is your home-grown
BIM connection to data. If you put good information in, you'll get good information out. If you
don't, of course, it'll just be gibberish. But the structure is there; there's nothing
holding you back. [graphic]
As a specifier, what I see now is that people are exporting schedules for markup so that
I can get them. Whether they do this as a PDF or an Excel spreadsheet, I can then, as
a specifier, give feedback to the design team to say, "I don't have enough information to
specify it -" maybe I do. But this is the information, ultimately, that the manufacturers
are going to need to deal with. There really aren't enough specifiers right
now, and according to the last issue of "Engineering News Record," in 2014 there are not going
to be enough architects or engineers either. We're going to come to a time when the manufacturers
and subcontractors are going to need to look into the model because it's their money that's
really at stake in making sure their products work for our buildings.
There are places to start. There are places where you can go to look and see examples
of this. You'll have to decide for yourself what in your best interest for your own project.
Remember that 5 million people are moving to cities every month. Now maybe most of it
is in the poorest countries in the world, but as architects and specifiers, we have
to have a way to go faster because the people are already born. We need to share that water
and air in buildings, and BIM, I think, is the only way that's going to happen.
With that, I'd like to change back to Andy and continue on our discussion.
>>Andy: Thanks, Mark. Thanks to Rob, Michael, and Mark for taking the time to prepare today.
Now we'd like to some questions. Our moderator is Mr. Michael Keene. Michael is the vice
president of Engineering Specifications at ARCOM. He has 41 years' experience in HVAC
design, specification, and contract administration, and has worked nine years with the MasterSpec
group at the American Institute of Architects. Michael, what questions do we have?
>>Michael K: We have several questions, Andy. Of course we won't be able to get to all of
them, but there will be an opportunity to respond to those that we don't get to.
How does bidding, especially government mandated competitive bidding, work into the BIM scenario?
>>Mark: The primary driver of data in BIM is the government. Part of the issue with
property sets is that in order for an architect to leave schematic design, leave design development,
leave construction documents phases of the project, they must enter data. Ultimately,
when you draw a window, you probably have a basis of design window. You may or not include
the name of that manufacturer in the government spec, depending on what you're using. But,
of course, your drawings can't include 20 different windows. You have to make an assumption
for just the flashing and pieces and parts. The government has found that this will work
very well for procurement, at the very least, with clash detection when things are loaded
up into NAVIS. Now there's co-checking software that will make sure you've got enough quarter
length, and you'll have your accessibility right and you can check whether there's insulation
in your exterior wall. So I think this feeds very well into federal procurement.
>>Michael K: Is the thought that these GUIDs that Rob was talking about would be registered
by some organization, such that a brick type ***, for example, would be registered by its
manufacturer and receive a GUID specifically for that product - sort of like an ISDN number?
>>Rob: We wanted to have such a system in place before we started our software development
for interoperability, but the standard does not exist at the moment. I think there are
a couple of possibilities. You heard about the SPie approach that Mark has actually invented,
I believe, and is working on. There are, as he and I mentioned, a number
of standards in place right now, including OmniClass, that could be expanded to form
the basis for such a classification and ID system, but it does not exist at present.
That's one of the difficulties. That's one thing that's holding us back toward achieving
real interoperability. >>Michael B.: As I mentioned in my presentation
briefly, until the standards are well formed and adopted, we and others are taking the
route of doing proprietary interfaces. If we can interface to one application from our
applications, or from one manufacturer to our applications, then we have to take what's
available to us today. If there's not a well formed standard, then we're doing that specifically
with just application-to-application proprietary interfaces.
Now that puts more work on all of us because we have to sit and actually have an interface
directly to that application, and when we migrate and have an adopted standard, I think
that will help us all. But until then, we can have the manufacturer list his particular
Revit object, for instance, if you want to use Revit as an example, and that can be interfaced
through something like the UniFormat code or other things. That's basically the way
that it's being handled today, at least on our end.
>>Mark: The buildingSmart alliance has 33 working groups with clever names like Spark-E
[?], HVAC-E [?], and Wall-E [?] where groups who have a lot at stake - for example, with
wall designations. It's unbelievable that in the United States there's no standard designation
for walls, but there needs to be, as Michael said, if we're going to move forward.
>>Michael K: If we're talking about the "future", why are we still expecting specifications
as paragraphs of text? I understand that these paragraphs are automatically generated from
a database; however, it should be presented differently as tabular [?] data with options
and sub-options. >>Michael B.: I'll take the first crack at
that. I absolutely agree 100%, and that's sort of the gist of my presentation that we
have to move from a document management process to an information management process so that
we can, again, present the data in the form that it's needed, whether visually or machine
to machine. Or if you need to have a contract document attached to a legal contract, then
it could be printed as it is today as a view into a database.
But I think that now that we have the model context and the ability to interface with
infinite [?] models directly - not just the design models, but where the models are used
downstream - we should be able to present very specific data to the user and not necessarily
from a text document. >>Mark: BIM cannot be a dumbing down. The
hard-learned lessons of the construction industry, this magic handshake we have between 1,000
sheets of drawings and 2,000 sheets of paper produced by six or seven disciplines to produce
a building that many trades will work on is a system that works regardless of your opinion
of the efficiency of it. To just go back to what Rob Dean said earlier
about linking out to databases where you can keep that little piece of secret information
about the difference between shop fabricated and factory fabricated as to whether or not
your roof will look good - we can't lose those things, so BIM needs to be handled in an intelligent
way that adds to what we have so we can go faster because our population and our country
require it. >>Michael K: The drafters are typically not
the people who make the decisions about materials and products. Won't either the drafting process
slow down while the decisions are being made or the accuracy of the specifications be jeopardized
by incomplete information the model? >>Mark: When the model is created, you're
often in schematic design. The people doing schematic design are often the most senior
people and the most capable people in the firm. They make a lot of decisions about floor-to-floor
height column spacing, preferred window, and preferred door, so that information can easily
be there in drop-down menus for the Revit people. Some in the office here call themselves
Reviteers. Yes, they know the roof is 3 1/2 or 7 inches
thick, but they really need to know is if it's a metal deck or a concrete deck. They
aren't being asked to learn that information, so the specifiers and the senior people in
the firm need to use these tools to make it available to them because each person has
to work to their strengths if this will work. >>Michael K: How do you deal with product
substitutions which seem to always be submitted by contractors and sub-contractors?
>>Mark: The same way you do now, and if somebody's going to do an as-built model, then they would
include the product actually included. I don't think that changes a bit.
>>Rob: I agree with Mark. You handle it the same way you handle it now. Hopefully, BIM
will allow us to handle it a little bit better, but one of the big issues that hasn't been
adequately addressed right now is the problem of propriety versus non-proprietary information
in the model. Up to a certain point, up to bidding, we typically want non-proprietary
for competitive bidding purposes. But in order for the model to be useful for facility managers
after the project is built, we really need to know exactly what was installed. As-builts
become more of a need, really, than up until now.
>>Mark: There are some design firms that are hoping to be the BIM architect of record for
building so that they get all the subsequent remodeling. There are other firms who don't
see that as part of their practice. There are many contractors who would like to be
the BIM architect of record. When you look at the big facilities programs, all of the
Fortune 500 companies have asset management tools that are graphically based, so now we
just need to tie them together and make that work.
>>Michael K: Do you see this eventually being integrated with business process modeling
as a way to consider and assess how enterprise goals and logistics influence design and specification
decisions? >>Mark: That's the dream, isn't it? You stretch
the model one more day [?] and you find out if your profit increased?
>>Michael B: I think if you have the discreet data available to you in a better form, then
a lot of those options will become available. As it is now with the data more or less tied
up in text documents, it's more difficult to achieve that.
>>Michael K: Legal elements of sharing BIM information was mentioned but could be better
addressed. >>Mark: The Boston Society of Architects had
a meeting with lawyers, architects, and BIM people. There's a little PowerPoint that could
be shared. The legal responsibilities are just where they are now because they're based
on case law and, of course, that case law was based on traditional methods of document
production. >>Andy: Michael, thanks for moderating the
Q&A session. I'd like to remind all of our participants that, to ensure that you get
your learning unit credit for today's program, please make sure that you complete the Webinar
Survey Report Form within the next five days. Finally, thanks for participating. If you
have a question about the TAP Knowledge community, please feel free to contact us at TAP@AIA.org.
I hope everybody has a great day.