Saturday 2 March 2013

BIM Task Group - Labs Area - Overview

Update 20/04: The latest plain language questions pulled together by Nigel Fraser following client sessions with MoJ, SL, DfS + BIM4Retail groups have now been refreshed. At NBS we have updated the information requirements tables to reflect these changes. The latest CIC digital Plan of Work modifications are also reflected in this.

On Friday the BIM Task Group released a huge amount of information detailing how their digital vision will be implemented. At NBS, we played a small part here in terms of helping with the object information requirements part of the documentation. However, it's extremely interesting looking at the final package together. All of the material is free to browse at the URL below...

I've only spent a few hours reviewing the material - so a big disclaimer that the overview below is "first impressions only" - but here are some thoughts.

1. Digital plan of work

The screenshot below shows how information typically develops over the project timeline. Information is defined as a combination of the geometry and the property-sets. So for the geometry, early on this may be just enough information for space planning - later in the project it may be enough to fabricate the object. For the property-sets... more on this later in section 3 of this blog-post. In the screenshot below the green circles are the digital plan of work stages that align to the data drops.
Information developing through the project stages
Objects can be anything from the complex (eg a hospital) down to a material (eg the sand that makes up the concrete). Each of these objects have property-sets - this is the y-axis below. The x-axis defines the digital plan of work stages. The z-axis are different views of the data for different actors on the project.
The information cube
The document shows what format the information drops must be in. In the screenshot below, to the left, the native file formats and the 2D PDFs are required. This information package could be a collection of say a few Revit, ArchiCAD, NBS files and 2D pdf drawings, schedules and specs (no paper). However, the big change it the inclusion of a COBie dataset that has coordinated information from all of the models. This is then used for validation purposes and for reporting based on the information requirements (section 3 of this blog post). The data is all classified by the new object-based classification system Uniclass 2.
The information "drops"
In terms of the validation of the COBie data - there are a few screenshots showing this in action in a MS Excel spreadsheet. I suspect that over the next year or two then this will develop on from basic tools built around MS Excel. A number of the big project management/hosting web portals are working on these currently.

Using COBie as a requirements validation tool
To demonstrate the complexity of objects being broken down into smaller objects, the NBS example looking at a sandwich is used to illustrate this point. A sandwich is an object, made of smaller objects (bread, butter, fillings). Each object can have properties and relationships between each other. Once you put a bit of thought into how much effort may be needed to specify a sandwich, then this puts into perspective why specification is so important for systems like floors, heating, structures etc...
Objects have properties, objects are made from objects, that have properties too

2. Uniclass 2

The Uniclass 2 work has been live for a number of months - so nothing radically different here. It's a combination of the main tables in PDF form and also Stuart Chalmers BIMGateway interactive UI.

I would say that it is worth reading my colleague Ian Chapman's introduction to Uniclass 2 in parallel to the material on the BIM Task Group site:

3. Plain language questions and information requirements

This is the area of the website that NBS contributed to the most. There are 22 objects from complex (eg hospital) to entity (eg building) to space to systems to products. Each is classified by Uniclass 2. Each has around 50-100 properties. In parallel to these objects and their property sets there are also a set of "plain language questions" - the sort of questions that a client needs answers to at each stage of the project.

All of this is presented in the labs area in an easy to navigate interactive website.
22 example object definitions are provided
The screenshot below shows some of the example properties for a Window System. Hovering over the property name shows the IFC equivalent. Each property has a clear definition. In addition there are also "little green ticks" to indicate when during a project that this information must be provided to the client.
Each property has a definition, IFC is the starting point
The screenshot below shows that the user can hover over each "green tick" to see what plan of work stage and which questions each property relates to. Clicking on the "green tick" takes the user to those questions.
Exactly why does the client need this information?
The questions are written in a simple to understand way. So in the example below, the client may need to know how the windows perform at construction stage. To be able to answer that question, they must know the security performance of the window.

So nothing incredibly complicated. Nothing new. Just now it will be (a) digital and (b) consistent on every project and when comparing projects.
The reference back to the plain language questions

4. IFC examples

There are some IFC examples included that show example completed property sets at different plan of work stages. The principles are exactly the same as the information requirements section. So in the example below for a classroom, there are a number of properties that are completed for an early stage of the project. The exact specification of each product in the space are not known. But the top level performance of the space is.
Early in the project the information is against the space
As the project develops, the design of the space develops to include the various products and the specification for each of these. The screenshot below shows the property sets for the doorset that are now starting to develop.
As the project develops, the information is developed against each system and product

A few thoughts to finish on...

A. The BIM vision is definitely on the right tracks
This is a logical and solid vision around digitalising the information that is needed throughout a construction project.

B. Open standards are the way forward
IFC is not going to go away, it is referenced throughout, it is *the* only player in town in terms of a neutral format for 3D+PropertySet data exchange. However, all parties have to up their game when it comes to IFC  (see the NBS COBie/IFC Report) - For example, I couldn't open the IFC samples in the first three applications I tried. The free DDS-CAD IFC Viewer eventually came to my rescue. But even then the sample files where visually  not quite right (see the luminaires on the wrong face of the ceiling in the image above).

C. Keep the focus on the information structures
It's all about information, information, information. Fantastic to see the LOD focus is mainly about the property sets and not the level of geometric detail. Both are clearly important, but BIM to date has mainly been about geometry (drawing generation, visualisations and clash detection) - it's time for some balance. However, the work to standardise these property sets that extend IFC (the data dictionary for the UK) has to be accelerated now.
This will not just help the client in terms of the information they receive. But with solid classification and information structures it will allow manufacturers info to flow through into models. It will also allow cost data, third party approval sources, environmental impact databases, in use data all to flow from the cloud onto construction professionals desktops to help them make informed decisions and great buildings.

Anyway, just an overview from me - but to check everything out go to:

No comments:

Post a Comment