Monday, January 29, 2007

e-SPECS Implementation Part 2

As I've mentioned in my first post about e-SPECS, connecting the design model data to the specifications is all about the Uniformat assembly codes. Well, most of my time for the next month or so will be spent combing through our entire Revit library...making sure every family and type within each family references the appropriate assembly codes set forth by our specifications department. They have completed customization of the Uniformat assembly codes and I have to make sure their new codes fit into Revit's list. Let's discuss that, shall we?

The Assembly Codes Revit uses are read from a text file located at C:\Program Files\Autodesk Revit Building 9.1\Program\UniformatClassifications.txt.



The file is simply a tab-delimited text file which can be opened and edited in Excel. Remember to make a backup copy before you begin editing...just in case. The file consists of the assembly (Uniformat) code in the first column, description in the second, grouping level in the third and the Revit category codes in the fourth. Huh? Those codes don't make any sense, do they?


Notice, when you select an object to edit its properties in Revit (for example, a floor), the assembly codes are filtered to only show those codes related to floors. Drop the pull-down at the top of the dialog to show "All Categories." The filters come from the codes in the fourth column. Here's how they break down:

-2001000, Casework
-2000038, Ceilings
-2000100, Columns
-2000011, Curtain Panels
-2000171, Curtain Wall Mullions
-2000023, Doors
-2001040, Electrical Equipment
-2001060, Electrical Fixtures
-2000032, Floors
-2000080, Furniture
-2001120, Lighting Fixtures
-2001140, Mechanical Equipment
-2001180, Parking
-2001360, Planting
-2001160, Plumbing Fixtures
-2000126, Railings
-2000180, Ramps
-2001220, Roads
-2000035, Roofs
-2001260, Site
-2001350, Specialty Equipment
-2000120, Stairs
-2001330, Structural Columns
-2001300, Structural Foundations
-2001320, Structural Framing
-2001340, Topography
-2000011, Walls
-2000014, Windows

Thursday, January 18, 2007

Collaboration, Disclaimers and Risk Management

From my old blog...

I've been inspired by a recent thread on the AEC-IS Roundtable forum to discuss the topic of collaboration, digital file disclaimers and risk management when employing Building Information Modeling tools. I recently met with Jim Bedrick, Director of Systems Integration for Webcor Builders in California to discuss related topics and I credit the inspiration for this thread to his Roundtable responses.

Most, if not all practicing Architects and Engineers use a Digital File Disclaimer when transmitting CAD files to clients, consultants and contractors. These disclaimers function as the buffer between the designer's intent and the builder's means and methods. To put it bluntly, disclaimers absolve the designer or engineer of any liability due to errors or omissions in their digital data. Most disclaimers also state that the accuracy of such data cannot be guaranteed. Where does this leave the state of efficiency in collaboration? See the NIST Report on Interoperability or Paul Teicholz' article on Declining labor productivity in the construction industry.

Think about what that means to a contractor when you send him/her your CAD files or BIM model and you state that none of the lines or model objects are guaranteed to be accurate. Guess where that data will go... Herein lies the problem: today's liability and insurance requirements restrict the Architect or the Engineer from dictating means and methods to the builder, thus we must take a more focused look at our methods of modeling and documentation in a collaborative environment.

While movements are underway to change the way projects are delivered, in effect distributing risk across an entire project team (result-driven), I believe the A/E sector can begin to re-examine its current collaboration process with upcoming BIM software. To begin, builders like Mr. Bedric are imploring designers to avoid 'fudging' practices such as overwriting dimension string values in CAD files or widely using terms such as "VARIES." If the A/E industry can formulate a loose set of best practices for BIM, we will make great strides towards improving productivity and the usability of our data by downstream consumers.

As far as production cost savings are concerned, Mr. Bedrick believes that reducing the time and effort required to produce shop drawings by reusing design CAD/BIM data is insignificant; however, true value can be harvested by efficient use of a RELIABLE digital model in order to provide faster, more accurate quantity take-offs. This would drastically reduce the turnaround time on estimates and would allow for either lower pre-construction fees or more frequent cost estimates which would potentially "reduce or eliminate value engineering efforts resulting in rework for the Architect."

Wednesday, January 17, 2007

Quality Representation

I'm reminded of a Jerry Laserin article titled "Much Vexation about Representation" which, in its simplest sense, remarked on the necessity of maintaining 2D or paper graphic quality while we venture into 3D, 4D, 5D and beyond. The reason for my reminisence is the amount of time I spent recently updating an Excel macro to format our extracted door schedule in a visual manner that exactly matched our legacy standard. Three difficult days were expended (found a neat tip on custom sorting though...in a future post) on this effort because formatting code is far more verbose than data manipulation. The code for the data extraction and sorting is about 100 lines of code, whereas the module for formatting consists of about 1,000 lines! At what cost do we sacrifice our building information modeling?

Believe me, we've had our share of go/no-go discussions on Revit projects when we had difficulty producing a certain graphic quality of plans or sections. No one wanted to hear about schedules, quantities or 3D cutaway views. How many of you have heard..."Let's make sure it does what Autocad can do before we implement Revit"? It's painful, but a necessity to address until we are contracted to deliver the actual BIM data.

Friday, January 12, 2007

The PDF Killer?

DWF (Design Web Format) has been around for some time and is about to gain some traction. I first heard the news at Autodesk University, but it's gradually making its way out into the news...

Cadalyst's Sara Ferris reports:

"DWF files published to the XPS specification can be automatically opened and viewed using the XPS viewer built into Windows Vista, Autodesk reports... Microsoft will also release a stand-alone viewer for use in Windows 2000 through Vista. XPS Viewers will also be available for Mac, Linux and UNIX platforms."

eSPECS Implementation Part 1

It's the start of another exciting year and we're already getting underway on at least 5 new BIM projects in our office. The only resolution I decided to make this year is to ensure 2007 is the 'year of the action item.' By this declaration, I hope to bring some of the multitude of digital design initiatives to fruition and rigorously track the effort along the way (more on that in a coming post). First, it's on to eSPECS.

We had initiated a purchase agreement with eSPECS some time ago, but the implementation never really gained momentum due to the odd state of our Revit projects at the time. With our new projects, it is one of my first priorities to get our system and content library configured for maximum effect with the Revit-eSPECS connection...more on that later.

eSPECS is a software developed by Interspec located in Portland, Maine USA which enables two things:

  • Specification authoring using a relational database instead of mere word processing
  • Connection to the Building Information Model via Revit

The mapping functionality that makes the authoring "intelligent" is enough of a full topic, but I'd like to focus on how the product integrates with Revit. Most architects and engineers in the US organize their specifications according to the Construction Specifications Institute's (CSI) 1995 or 2004 guidelines. The 1995 version contains 16 divisions, while the 2004 version boasts a more robust 48 divisions. These divisions incorporate sections which are mostly relevant to a single trade or product - for example, Metal Fabrications or Cast-In-Place Concrete. These work well when information needs to be separately identified for subcontractors and/or fabricators bidding and executing a project.


In Revit, the digital elements are organized as assemblies. As such, the founders of Revit chose to implement the Uniformat Classification codes as a method to further identify objects such as walls, floors and roofs. If we examine a simple exterior wall in Revit, it is a single object consisting of potentially several layers - interior finish and framing, sheathing, insulation and exterior finish. Elements that are typically only shown in drafted detail might include flashing, anchors, trim, weep holes, etc. - all separate sections in CSI format. These are brought together as bindings in eSPECS - essentially a series of one-to-many relationships. In the previous example, a wall type in Revit as described above might have the assembly code "B2010141 - Ext. Wall-CMU w/ Stone Veneer" which would be bound to sections 04200, 04400, 05800 and so on.

The goal in this transfer is twofold: first, to enhance the communication and collaboration between the design team and the specification writers through the generation of a report from eSPECS showing everything in the model whether it was tagged correctly or not; second, it will automatically generate about 80% of the complete project specifications. The remaining 20% consists of individual material coding and specialty research. With refinement of the product, we will hopefully be able to generate the entire spec with minimal administration from the specification writer - allowing them to spend more time researching innovative materials and construction technologies. Another residual benefit of this implementation seems to be the re-education of our design team, again eliminating the 'toss over the fence' phenomenon. To make the transfer effective, designers must coordinate closely with our specification writers, giving them a higher level of understanding in feasibility and constructability.

View the eSPECS online demo via this link.