Tuesday, 31 July 2012

BIM Implementation & Process/Culture Change - Part 3

In previous post of this series I looked at vector based design/documentation vs object oriented design/documentation and how fundamentally different these two processes are. Now lets take a look at one of the main (and the most important) changes we are supposed to deal with in object oriented design/documentation. To me, and almost everyone involved, it's the holy grail of BIM. Yes, you guessed it correctly. It's the "I" in BIM.

For most of us, "I" in BIM is the deal breaker so I am not surprised to hear one of the major contractors saying "we receive lot of BUMs", Bloody Useless Models. Why? Because they are just getting 3D models and not Information Models.
In our recent meeting at NBS BIM library we spent great amount of time brainstorming on how to get "I" in our BIM models at different stages of the project by different parties. The UK government/RIBA/CPIC and other related organisations are working on a protocol/procedure to define BIM data drops at various stages of a project.

So, where is this conversation leading to? Well, as most of you know, towards COBie! In coming few years we should have better clarity on COBie and roles and responsibilities of each stake holders. In the mean time we need to be ready for "Information Modelling" and changes it brings to our current process/culture.


In object oriented design/documentation process everything is object driven and each object has (Information)properties attached to it, Local and Global properties. Ok, we do have properties in 2D vector based design/documentation but mainly graphics properties, i.e. layer/linestyle/color/Coordinates/Length etc. I know we can add attributes to 2D objects in vector based process but how do we manage Local vs Global properties, how do we get "Information Schedule" to drive 2D graphics etc.? The list could go on and on. The bottom line is Information Modelling is practically impossible in vector based process, the main reason why we need object oriented process such as BIM.

In the example shown below, on left hand side we have a specification for a door and on right hand side we have a door object with the specification linked to it's global property. This specification property is available in schedule too, instantly. This is just one of the many "Information" properties expected in objects in true BIM world. Think about Design, Construction, Operation, and Building Information (DCOBie) that need to go with every BIM object. With this comes a requirement for "Information Modelling" management. We need to manage information flow quite carefully if we want to convert BUM into BIM. If you are interested to know more about object's properties I highly recommend looking at COBie spreadsheet.

So, do you think we are ready to deal with Information Modelling? do you think our infrastructure is ready to deal with Information inundation? do you think legal framework is out there to deal with Information Modelling? Answer to all of these questions might be "NO" at this moment in time, who knows. But one thing is definite, BIM is about Information Modelling and is going to call for a massive change in process/culture. We need to start working on this challenge now and be prepared before Information flow starts.

Thursday, 19 July 2012

LRUG - BIM Execution Plan

Last night we at LRUG were fortunate enough to have a very insightful debate/discussion around BXP. I was privileged to lead the debate with my co-presenter Ray Purvis of Atkins.

Alan Wooldridge is going to upload video recordings of both sessions, Underground Drainage by Carl Collins of ARUP (another not to miss session) & BXP, at the early possiblity. Be sure to check out LRUG in next few of days. In the mean time click on the following image to download BXP presentation. Any comments would be much appreciated.

COBie In The Cloud

I wrote a blog post last month on cloud based BIM collaboration and now the race for cloud based Facility Management seems to accelerate!

FM:Systems launches FM:BIM, a cloud based FM data management system.
Key Capabilities
  • Create live, bi-directional links between Revit models and the FM:BIM Cloud-based application
  • Connect BIM data from design, construction and renovation to facility management and operations
  • Manage FM:BIM room and space information both in Revit and in a Web browser
  • Synchronise type and instance properties for assets in Revit models with building equipment data in FM:BIM
  • Plan maintenance for building equipment
  • Track asset history and warranty requirements
  • Publish views from Revit models to FM:BIM — enabling anyone on the project team to visualize and manage model information.

Image Courtesy: FM:BIM

This is definitely a step forward in collaborative BIM. Other tools like Onuma, Artra etc are already making big strides in this direction (or dare I say setting direction for the industry) but what caught my attention to FM:BIM is their headline:

"With FM:BIM, anyone on the project can capture building information whether they're BIM gurus or have never touched Revit. Free up your Revit modelers to model buildings - not enter data! With FM:BIM's unique integration an engineer can specify a certain model of equipment, the sub-contractor can enter the specific serial number and date installed and the facility manager can enter maintenance schedules - all from a standard Web browser!"

Really? Do we really want to free up designers from "I" in BIM? Personally, I don't think so. If anything we should have more engagement of designers in "I" of BIM.

Last week, I was at NBS BIM Library Focus group meeting and majority of the time was spent on "I" in BIM. How do we get that "I" in our BIM, collaboratively? Who does this? When? and How?

From UK perspective COBie seems to be one of the most important deliverables as per current government's BIM strategy, for publicly procured projects.

For further reading on COBie:

 It is important to note that the requirement of contractors to provide equipment and valve tag lists is already a requirement in virtually all construction contracts. COBie requires nothing new, simply a change of format in existing contract requirements. The Contractor is free to use COBie as part of their traditional process or take the COBie Challenge to eliminate the end of project "job crawl" in lieu of simply typing in the serial numbers of equipment and tags as they are installed.
Designers and contractors facing a COBie specification for the first time may think that they have a lot to swallow, however, the information required in COBie is no different from the information already required by design and construction contracts.
The objective of COBie is not to change the type of information that is required, just to standardize the format of that information to save you, and the buildings' owners and occupants, having to rekey this information multiple times.

Tuesday, 10 July 2012

Design BIM to Construction BIM (to FM BIM) - MEP only for now

FABmep import for Revit MEP 2013 is now available on Autodesk Labs. If you are a (Revit)MEP user then please provide your feedback via Labs web portal or Labs official blogs (you know who I am talking about!) on how this round tripping BIM, Design to Fabrication and Fabrication to Design/FM, can benefit you/your client. Do you require any fabrication related INFORMATION attached to geometry for record as-built model or FM models?

"The FABmep Import for Revit MEP is a free technology preview that enables users to import Autodesk Fabrication FABmep models into Autodesk Revit MEP® software, providing round-tripping capabilities for as-built/record drawing purposes. The import is intended to support geometry ‘only’ and does not maintain design or fabrication information."


This technology preview is only available for Revit MEP/FABmep only at the moment but one can relate this to almost all disciplines, Revit ARCH/STR and Inventor?? Some of the underlying questions behind this kind of technology initiatives that we are trying to answer are:

- How do we transfer Design BIM to Construction BIM to FM BIM?
- What is the transition PROCESS and who is responsible for what part of the BIM?
-  What kind of geometric data and INFORMATION data should be transferred from one BIM to another throughout the process?
- And finally, where do we stop?

I am sure you will find plenty of discussions/presentations around this very subject but this is still a grey area that the industry is yet to get some clarity on. Here in the UK we see lot of efforts put in by the UK government to address this very subject under some national BIM standards/framework.

Friday, 6 July 2012

BIM Implementation & Process/Culture Change - Part 2

In part-1 of this series I talked about how fundamentally different 2D design and documentation process is from 3D/BIM process, in a broad brush sense so to speak. Now let's take one step further and see what this actually means at a granular level.


In traditional 2D process we design and document buildings using bunch of vectors, spending awful lot of time drawing every possible/visible edge of wall or window or door in 2D to represent building objects. It also takes considerable amount of time coordinating one 2D view to another and so on.
Time aside, It is almost impossible to visualise the design intent using just 2D vectors. On top of this I never think about ATTACHING any information to my vectors so that one can query vectors and know whether this is a vector that belongs to a wall or a ceiling etc.

So process point of view, when I think of representing a wall, I don't think about it's builtup or fire rating or other properties. In other words, vector based design/documentation process doesn't flag up those questions at all. All I have to worry about is how to draw bunch of parallel lines to represent a wall and how to trim/fillet junctions without worrying about how wall junctions are going to work in real world. An 'experienced' designer  comes on board at later stages of the project and draws junction details etc for construction, which is less coordinated with other vector drawings because those other vectors sit in different set of files or model spaces (or sometimes paper spaces). Now how do schedules link with vectors? Well, they don't because vectors don't have any information attached so you cannot extract information.


In object oriented/BIM design and documentation, the process is more or less similar to Lego in layman's terms. You pick up an object and place it into BIM environment, 2D or 3D. What is so special about these BIM objects is that they have some information/intelligence attached to them and they are smart enough to interact with their surroundings, yeah! not always. In the example above, on the left side I am showing a 2D DWG version and on the right side I am showing 3D BIM version of the same area of a project. We can see how object oriented documentation flags up those information questions throughout the process and links information data to model data to 2D output eventually. The attached information data in turn is used to pump out schedules and the modelled data is used to generate 2D projection views/outputs.

So what is fundamentally different in object oriented process?  In object oriented documentation when I think about a wall object, for instance, I have to think about it's builtup and not bunch of lines, when I look at the wall junctions I think about how plasterboard, for instance, is going to meet moisture resistance plasterboard, when i think about schedules I think about information data attached to BIM objects, when I think about any change in partition layout, for instance, I think about how this is going to  affect other objects in the building and not worry about revising sections/elevations/schedules etc. The list could go on and on.

The bottom line is object oriented design & documentation is fundamentally different to 2D vector based design & documentation and will require wholesale change in process and culture.

BIM is a Tool - BIM vs Communication

Damon Socha and Jennifer Lanzetti share some thought provocation facts about BIM and communication at AUGI.

"Building Information Modeling is a tool, a single part of a larger solution, and not the only solution to the productivity and collaboration problems. BIM does not necessarily enhance our ability to communicate. BIM is helping preserve the loss of information throughout the lifecycle of a project, but quantity of information does not replace quality and timing."

Read full article at AUGI.

Tuesday, 3 July 2012

Trimble joins the race for BIM

Trimble announced today that it has entered into a definitive agreement to acquire WinEstimator, Inc. (WinEst), a provider of construction cost estimating and cost-modeling software. The transaction is expected to close in the third quarter of 2012, subject to customary closing conditions.

"The acquisition will allow Meridian to provide a broader range of solutions to general contractors and building owners executing projects around the globe," said Geene Alhady, general manager of Meridian Systems, a Trimble Company. "Industry trends including BIM and IPD are driving more innovation in construction management software solutions, and now we are better positioned to support our customers and markets." 

"Together our solutions will improve the flow of construction cost data throughout the project lifecycle, and allow our joint customers to get increased value from their BIM investments," said Steve Watt, CEO of WinEst. "By joining with Meridian, we can improve solution interoperability between BIM data, estimating and project management solutions for all key stakeholders—owners, general contractors, specialty trades."

Read full story HERE.