Friday, January 12, 2007

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.

5 comments:

  1. Thanks for posting about this. We are also trying to get this integration rolling and it's not as easy as it sounds, due to the considerable amount of coordination it takes to make sure that your families are classified correctly, etc. We're still looking at some other packages, but my feeling is that Especs is a pretty mature product and has great Revit integration already. I'm sure looking forward to this series of articles =)

    ReplyDelete
  2. Mario Guttman - HOK1/17/2007 1:30 PM

    We at HOK are also looking at eSPECS. I really like the strong "object" and "database" philosophy to the design.

    The main issue for us is that we don't have a very unified specification writing group over our 20+ offices. They use a variety of in and out-of-house people and have different ways of working. As individuals they are not really progressive about technology.

    I would like to see a unified, database-driven, approach to specification writing first, then we will look at the Revit link. I see the BIM aspect a relatively minor one, which will be easy to implement, given the reorganization of the specifications effort.

    ReplyDelete
  3. Hiroshi Jacobs1/18/2007 6:38 PM

    RTKL also struggles with a non-unified specification writing group, and I agree that this is the hardest part of implementing something like this. The technology is there but the mindset is not yet.

    I too look forward to your thoughts on implementing e-SPECS.

    ReplyDelete
  4. James, we are looking into e-specs, but probably won't act on it for a while. In the mean time is there a way to add the information e-specs uses (assembly codes) to our families now as we build them? Where would I find information on the assembly numbers, or are they automatically done in Revit?

    Thanks
    Tim

    ReplyDelete
  5. Tim, Yes you can add assembly codes into every family you build in Revit. Autodesk usually assigns a code to most of their OOTB families, but you can change them as you see fit.

    ReplyDelete