PLQ2.5 – COBie Round 2

Hello BIMfans,
After Revisiting my BIM Execution Plan, this week I am taking the final steps before I complete my Architectural Graphical Model and produce its associated BIM Level 2 deliverables.  Previously on this blog I have had a look at COBie during COBie Round 1 and found a number of issues which I discussed in further detail during Bridge the Attribute Gap.  This week I am come up with the solutions (by hook or by crook) to allow me to complete my COBie files.

manhappy
As you can tell from the image, things have gone much smoother this time.

When forming my Employer’s Information Requirements, I considered the Purposes I was going to use this information model for as well as the associated Data Requirements. To resolve the issues presented in Bridging the Attribute Gap. I have come up with a number of ‘fixes’…

custom
The majority of my ‘fixes’ have been through using a custom text file to map parameters.  If you want to have a look you can see it here.

I previously discussed issues with the ‘Contacts’ worksheet due to the fact that Revit hasn’t got the functionality to store multiple contacts for a project.  While this is resolved through the COBie Extension for Revit, the extension isn’t compatible with my IFC approach.  So to resolve this I have come up with a lazy pragmatic solution.

It states within BS1192-4 that:

In federated BIM (level 2) projects, information for COBie is likely to be
available from the models, structured specifications and other schedules.
(4.2.2 Note 1)

So as the model cannot hold this information effectively, I have created a project document to schedule this information; my Project Contract Sheet.  This sheet, has been set up to be used to capture the contact information of all project participants and has been aligned to the COBie structure so that the schedule can be easily used to populate Contact worksheet after being exported (Cough…Copy…Cough…Paste).

Some might call this cheating (I call it effective project management).  A project contact sheet should be formed for project anyway, so why not align it to COBie and use it as the schedule?

informationmodel
Remember there are three parts to an Information Model, all I am doing is storing the data in a Non-graphical form.

Also, since Bridging the Attribute Gap, I have also resolved a number of outstanding attribute issues.  I mentioned previously that my home has no ‘Zones’, that due to a lack of access I will not be modelling ‘Connections’, and that I do not hold any ‘Spares’ in my home.  Also as far as I’m aware, no items that I maintain have any product required ‘Jobs’ to maintain their operation or warranty (apart from my Mattress and SmartHome kit I’m 90% nothing else is in Warranty), meaning that I also don’t require any ‘Resources’ to complete these non-existent jobs. Therefore, only the following outstanding attributes remain unresolved:

Facility:  Currency Unit (Not supported in Revit)
Facility:  AreaUnitMeasure (I have no formal convention so I’ve not looked into it)
Facility:  Description (No IfcBuilding equivalent in Revit to attach a description to)
*RESOLVED:  BuildingLongName is needed as a shared parameter*
Type/Component: Description (I can make it work for one or the other, never both)
Attribute: Unit (Not Supported in Revit)
Attribute: Allowed Values (Not Supported in Revit)

To fix these items until they are supported, I have started to create a schedule of Post-export changes to be applied to my COBie sheets.

attributespost
Shown are the current fields that need to be altered post-export to my attributes worksheet.

Some might call this cheating (I say you are probably right!).  However, does it matter?

The spirit of the BIM process is to provide the right information, to the right people, at the right time.  If I have to do a little ‘post’ to achieve it, so what?  The important part is that the process is managed.  Because I have clearly outlined by process and kept this information in separate databases I see no problem with this approach.  If you are interested, you can have a look at how close my current COBie outputs are; anything modified in post has been marked in red.

Note:  It is worth noting at many fields have ‘n/a’ due to the lack of existing information as opposed to the lack of data input…

windowadditionalattributes
As a bonus, because I have exported my files via IFC, I can limit my attributes, for example these are the only additional attributes I am exporting about WindowType01.  This helps keep my COBie lean (and relevant).

And there we have it, aside from the properties I have identified above, I have demonstrated here and through previous posts that I am able to populate my information model and export out the data I need into COBie.  Hopefully in the next week or two (free time permitting) I will be able to finish formatting the objects within my Architectural model to be able to issue it as complete.  This means that I am very close to completing  PLQ2.5!

Model Generation:
2.1 What existing information is available?
2.2 Is there sufficient information to produce a BEP?
2.3 What is the layout of the house?
2.4 What assets are contained within?
2.5 What asset information can be linked to the graphical model?

Now that I have proven the process works, let’s put it into practice…

Advertisements

3 thoughts on “PLQ2.5 – COBie Round 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s