Category: COBie

PLQ 3.3 – COBie Culmination

Dan1 Comment

Hello BIMfans,
Those of you who have been following this Blog will know that producing good COBie has been a persistent goal of mine.  This goal may sound simple, but it wasn’t.  Due to the current state of software, the delivery of well-structured information isn’t a one-click activity (one day we’ll have that magic COBie button…one day).  When producing information to manage my home, I have been careful to ensure that the properties and attributes I’ve used have been structured to suit the available British, European and International Standards which are:

Because of my allegiance to the Standards, I’m confident in the quality of my work.  However, I can’t be sure.  Most methods of producing COBie do not incorporate verification, a method of testing that the information has been formatted correctly.  Meaning that while it might save like COBie, and look like COBie, it isn’t necessarily COBie.  My process of using an IFC rendition to produce COBie through xBIM has this problem.  Thankfully, a follower came to the rescue; John Ford.

JohnFord
Look at this BIM model!

John is the senior business information development manager at Carillion Plc.  If the name seems familiar, it’s because he is quite active on Twitter and is one of the most active participants in the LinkedIn COBie forum.  One of  John‘s many key roles is the validation of COBie using Carillion‘s preferred COBie quality control plugin, the COBie QC Reporter.  John contacted me and kindly offered to verify my COBie (I think I nearly bit his hand off!).

Note:  Anyone (I mean anyone) is free to take files off this blog and use them for whatever purpose they like; they are on creative comms for a reason.  Please play with these files and let me know how to improve them.

John provided a series of reports created by the COBie QC Reporter, filled with useful information that tabulated the findings from each sheet, like the one shown below.  Reading these reports I discovered that my COBie had failed!

COBieReport

Full disclosure, I knew they would fail.

Back when I looked at my Data Security, I opted to use ‘redacted’ as my email address.  Because of this, I was producing an error each time my email address should have appeared.  However,  John also found a few other errors that I wasn’t expecting.

  • Email address.  I was also getting a second email related error.  The other was that I incorrectly used ‘n/a’ when I didn’t know the warranty guarantors of my components.  To resolve both of these used ‘redacted@bimblog.house’ and ‘unknown@bimblog.house’ respectively.
  • Model Number.  I didn’t realise that model number had to be a value other than ‘n/a’.  Because my home has a lot of missing information, I don’t know the model number for most components.  To resolve this I used ‘unknown’ instead.
  • Warranty Start date.  No components in my architecutal model had a warranty start date (ooops!). To resolve this I added the attribute as required.
  • Duplicate Types.   After exporting, duplicate types were appearing.  On investigation it turned out to be an issue with Revit and the way it handles instances.  Types were duplicated if their default height or their orientation had changed.  I have been in contact with Autodesk who have recognised the issue and are looking into it.
  • xBIM.  Due to my use of Revit to IFC to xBIM, some of the default cells were not being completed such as Attribute.Unit, Attribute.AllowedValues and Space.Floor.  In addition, some components would appear without their type, and vise-versa.  To resolve these I modified the information in post (shown in red).  I will be raising these issues with xBIM in the new year.
  • Assemblies.  My assemblies were not exporting as expected; causing validation issues.  To resolved this, I omitted them from the report.
  • Picklist.  To date I had been lazy and hadn’t written my own picklist.  As such it was causing some validation issues.  To resolve this I just sat down and wrote the damn thing.

Once I had resolved these issues,  John kindly re-verified my COBie through the COBie QC Reporter and found zero errors; woohoo!!  As you can imagine I was pretty chuffed and had to tweet about it:

You can access my validate COBie here:

I wasn’t the only one who was impressed; John was quite impressed too.  In fact, he was so impressed that he left this kind testimonial:

Testimonial_JohnFord.png

Note:  Other testimonials for this blog can be found here.

And there was have it.  Throughout my professional career, I have always valued third-party validation.  It’s one thing to say it, it’s another to have someone else prove it.  Thanks to the kind help of John, we’ve managed to prove that my COBie not only walks the walk; but also talks the talk; fantastic.

As you can see, it has taken a lot of effort to ensure that the information I have produced is correct, and this has only been for a small Victorian mid-terrace. My effort would pale in comparison to the effort needed to deliver COBie for a multi-million-pound central government BIM Level 2 project using today’s software.  If we expect ‘proper’ projects to do the same, the methods we use to produce COBie needs to improve.

Operation and Maintenance
3.1 What are the sizes and condition of the windows & doors?
3.2 What assets are in a poor condition?
3.3 What costs can be attributed to my assets?
3.4 What are the most cost effective thermal improvements that could be undertaken?

Now that I have perfected my COBie, it’s time to find an asset management system to export this information into…

Note:  If you have any comments regarding my COBie and the validation process, then please let me know either on Twitter, or by commenting below.

PLQ 3.3 – Understanding Uniclass 2015

Dan8 Comments

Hello BIMfans,
Before I calculate the costs associated with my preventative maintenance schedule, I need to ensure each object is correctly classified.  So, let’s take a good look at Uniclass 2015.

A few weeks ago I had the pleasure of sitting down with Sarah Delaney, head of classification at NBS, to talk about Uniclass 2015.  It turns out that the way I have used classification isn’t exactly how it should be used, so I wanted to share with you why and what changes I needed to make.

NOTE:  Sarah has written an article on Uniclass 2015 which really helped me understand Uniclass 2015.

Classification:

Ok, a quick bit of context, what is a classification system?  Basically, classification is a method of categorizing ‘things’ into classes, ‘things’ that share the same characteristics. Classification impacts on everything (everything? EVERYTHING!), from the Tree of Life,  the age-old debate around Whether Jaffa Cakes are in fact Biscuits? (Fun fact: A debate based on avoiding VAT), to how we decide what parts of a design are the responsibility of which professionals.

tree-of-life_2000.jpg
Note:  I have no idea where Jaffa cakes sit on this diagram

In construction, there is an International standard for producing classification systems, ISO 12006-2.  It suggests how classification tables should be broken up as well as their relationships to each other. Uniclass 2015 is the UK’s latest in a series of UK classification systems (CI/SfB, CAWS, Uniclass, Uniclass 1.4, Uniclass 2,…) aligned to this standard.

Note:  Before any QS/Estimators kick-off comment, I will point out that the RICS‘ New Rules of Measurement (NRM) is NOT a classification system; more on that in a future blog post.

Uniclass 2015:

As explained by Sarah in her article, Uniclass 2015 consists of several tables which are based on the following number series:

Group Title
10 Preparatory*
15 Earthworks
20 Structural
25 Wall and barrier
30 Roof, floor, and paving
32 Damp-proofing, waterproofing and plaster finishing
35 Stair and ramp
37 Tunnel, shaft, vessel and tower
40 Signage, FF&E, and general finishings
45 Flora and fauna
50 Waste disposal
55 Piped supply
60 Heating, cooling, and refrigeration
65 Ventilation and air conditioning
70 Electrical
75 Communications, security, safety and protection
80 Transport
85 Process engineering
90 Circulation and storage

Note:  While under Products(Pr) preparatory work is covered under Pr_15; in Activities(Ac) however, it is under Ac_10. So, as 15 has been taken by Earthwork in Systems(Ss), I have opted to use 10.

So, where did I go wrong?  Put simply, I hadn’t fully understood the relationship between the tables.  Which is as follows:

  • Pr, Products:  Things you buy (Bricks, wall ties, and Mortar)
  • Ss, Systems: An element (or part of an element) made of products (Brickwork)
  • EF, Elements/functions:  Main building components (Walls and Doors)
  • SL, Spaces/locations:  Place where activities happen (Living Room and Kitchen)
  • Ac, Activities: Exercising, Sleeping, Eating, Working etc. (Cleaning and Cooking)
  • En, Entities:  Individual assets (Just the house)
  • Co, Complexes:  Group of Assets (House and Garden as ‘Ty Crempog’)

What I had done was incorrectly use the Systems(Ss) table when I should have used the Elements/function(EF) table for my doors.  Each of my doors were classified as Ss_25_30_20_25: Doorset systems, but this isn’t correct as they are not doorsets.  As such, I have now re-classified them as EF_25_30: Doors and windows.

To remind myself, I drew this diagram.

Classification.jpg
This feels like one of those Mensa questions.  If all Systems include products, and some elements include systems, are all Elements Systems?  Answers on a postcard!

Using classification:

For classification to work within Revit when exporting an IFC, each object’s classification code and description needs to be placed onto the defined property specified in the classification settings window; written as ‘Code: Description’ to comply with BS 1192-4 & COBie.  As you can see from the image below I have opted for the property ‘ClassificationForObjects’.  I chose this as it is the most appropriate field I could find within the IFC Schema as it is listed within IfcClassification.

ClassificationSettings
The default value is ‘ClassificationCode’, I was just being awkward changing it…

This information is then exported into an IFC file and passed through to COBie so that it is ready to be exchanged and used to manage my home.

COBie-Uniclass.JPG

And there we have it.  By using Uniclass 2015 in the way that it was intended to be used, I have now improved the quality of the information I have produced and are using to manage my home; fantastic!

Operation and Maintenance
3.1 What are the sizes and condition of the windows & doors?
3.2 What assets are in a poor condition?
3.3 What costs can be attributed to my assets?
3.4 What are the most cost effective thermal improvements that could be undertaken?

Now that I classified my objects correctly, I wonder how classification will relate to costing up my preventative maintenance schedule?…

PLQ 2.5 – Information Model Complete!

Dan3 Comments

Hello BIMfans,
As promised, after last week’s post about my Architectural model, I have resolved all the additional comments you have provided (Thank you).  This means that my information is ready to be formally shared, completing Plain Language Question 2.5.

Completed_stamp.png
Links to the project outputs can be found below and in the main menu.

Once again, a big thank you to everyone who took the time to review my project outputs.  All of your comments have been very constructive and have led to a better, and more compliant project; so thank you.  Right, let’s see that I have resolved this week:

Property Sets:

I was told that within my IFC files, I had not grouped my properties under the correct property sets.  To check this, I consulted the NBIMS COBie Responsibility Matrix, and the IFC 2×3 Schema.  When doing so, I found that I had indeed not grouped my properties correctly.  Luckily for me, this was a pretty quick fix as the property sets are controlled by the Property Set Definition Text File that I used when exportting.  I also had a few properties that didn’t fit into any property sets, such as the FensaCertID for my windows, so I created my own property set called ‘Addition_Pset_Custom’.  Note:  Revit can’t do property grouping, so this can only be seen within my IFC file.

propertiesresolved

Credit: Rob Jackson (@BondBryanBIM) of Bond Bryan Digital.

Default COBie Values:

I was told that some of the default values I had used in my COBie file were not correct.  Once again I referred to the NBIMS COBie Responsibility Matrix and found that some of my default values where indeed not compliant.  To be perfectly honest, I took the easy road any defaulted any values I didn’t know to ‘n/a‘, not applicable.  However, n/a isn’t always suitable, as it breaks the formatting of a number of fields.  For example, all elements should have an installation date and if the date isn’t known it should default to ‘1900-12-31T23:59:59‘. My house was built around then, so it’ll confuse matters for items I know were built later than that, but that’s the rule!

newinstallationdate
It might be correct, but now my boiler is as old as the house…

Credit:  Dan Mofakham of Cadan Design.

Drawing Annotations:

I was also noted that I hadn’t put any section or elevation annotations on my drawing sheets.  The reason for this is typically when using Revit , the BS 1192 file name is used as the sheet number, this helps locate the file when exporting, however, if do this your section head looks something like this…

section-before
Urgh…I think I’m going to be sick

Luckily for me, I have a solution; it relies on the fact that the file name isn’t the sheet number.  Those of you who read Drawing to Conclusions will have noticed that ISO 7200 requires a sheet number; however this sheet number isn’t the file name, it is a single number showing its place in the package being issued.

7200
In ISO 7200 the sheet number is 1 (of 5), not AB123 456-7

Now BS 8541-2 specifically states sheet number; not the file name.  So as I used both of these standards in tandem, I have a similar convention on my title block to get the following block and section head.

section-after
and just like that, order has been restored

Note: I know A LOT of you will dislike this; tough.

Credit:  Me!

And there we have it.  Thanks to the continued support of this wonderfully open community, I have been provided with a myriad of comments to improve the deliverables within my information model.  The Architectural, Mechanical, and Electrical Native, IFC, and COBie files have all now been issued.  This means that PLQ2.5 is finally complete; Woohoo!

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 finished my model generation Plain Language Questions, let’s reflect on this year…

Note:  If you have any comments regarding my information model or how I have resolved these issues, then please let me know either on Twitter, or by commenting below.

PLQ2.5 – Check, Review, Approve

Dan1 Comment

Hello BIMfans,
After publishing my Architectural Model and my Mechanical and Electrical Models last week.  This week I am looking at some of the pedantic fantastic comments you have provided back and what I have done to resolve them; thank you for these.  Remember there is still another week to contribute so keep those comments coming!

So let’s see what comments I have had back.

commentsmeme

Volume Code

I was told that I have used the wrong volume code.  I had issued using the volume code XX-‘No associated Volume’, however, my Employer’s Information Requirements clearly states that I need to follow BS1192, which uses the default code ZZ-‘All Volumes’.  I agree, and have now renamed all of my outputs to use ZZ, and updated the appropriate sections of my BIM Execution Plan to suit.  Technically I complied with my BEP, but as Keith told me, I am a stickler for the standards!

Credit: Keith Wilkinson (@StudioBIM) of JM Architects.

COBie Contacts

I was told that my COBie contact sheet should include all of the suppliers, installers, and other contacts related to my home; not just the project design team.  I agree, and have now revised my COBie contact sheet to include all of the applicable contacts.  It’s hard to find guidance on the scope of this worksheet #excuse, but Dan knows his stuff!  I also really don’t like using the PM table in uniclass 2015 for this, but there isn’t a roles table.

contacts
I also have a spare at the bottom for any unknown contacts and to be DPA compliant I’ve only used email and contact details that are publicly available.

Credit:  Dan Mofakham of Cadan Design.

COBie Documents

I was told that my COBie documents sheet should be populated with my other outputs such as my drawings.  I agree, and as Revit cannot hold this information have used my COBie Post-process sheet to record all of the applicable outputs.  Nick, as usual, is technically correct (the best kind of correct).

Credit:  Nick Nisbet (@NickNisbet) of AEC3.

I was also told that my COBie documents sheet should include other documents such as my property condition survey and any designer risk assessments.  I agree, however, there are no designer risk assessments as I haven’t done any design on this project.  Similar to the above I have used my COBie Post-process sheet to record all of the applicable documents as well as my outputs.  Good thing I have no design, as I have no PI insurance!

Credit:  Chris Weston (@CWeston222) of Rio Architects.

documents
From my Prologue, you can see I have a lot of documents to manage.

COBie Jobs

I was told that my COBie jobs sheet is empty, therefore I must not maintain my home.  I agree with this, but as I have pointed out in a previous post, jobs are optional; so I am not going to use it.  However, on reflection it is worth considering, so It’ll feature in the new year when I am looking at my operational Plain Language Questions.  As I told Chris, despite what my COBie sheet says, I do vacuum my house!

Credit:  Chris Weston (@CWeston222) of Rio Architects.

IFC Co-ordinates

I was told that my IFC file contains some co-ordinates for my house; luckily for me those Co-ordinates are in London.  This is because of my data security requirements within my Employer’s Information Requirements stated each model had to have the co-ordinates of 0,0,0; and without changing the location in Revit, it has defaulted to London.  As a proud Welshman I’m disappointed of this default location, but happy my data security measures have worked!

projectbasepoint

Credit:  Nick Nisbet (@NickNisbet) of AEC3.

Splash Screen

Also, keeping with my BIM execution plan, I had also stated that all outputs should include my ISO7200 title block, but I had not included it in my native models.  To resolve this, I have added them as a splash screen when the models are opened.  Do I get points for spotting my own mistakes?

SplashScreen.JPG
This has had the added benefit of reducing my file size by 500KB as my model no longer has to store such a detailed thumbnail image

Credit: Me!

Note: I have also had one or two comments about the data format of some of my COBie fields. However, I’m aware of some other comments about this due next week, so I will deal with them all during next week’s post while I publish my documents.

And there we have it.  Thanks to the support of our wonderfully open community, I have been provided with a number of fantastic comments have have been used to improve the outputs from my information model.  This means that following another week of excellent input I should be ready to complete 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 the first set of comments resolved, lets see what you guys come up with next week…

PLQ2.5 – COBie Round 2

Dan3 Comments

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…

PLQ2.4 – Ask for all the Components!

Dan3 Comments

Hello BIMfans,
After a short diversion last week to consider the importance of Soft Landings; this week it is time to finish populating my Architectural model to answer our currently Plain Language Question, PLQ2.4.

Now as you would expect,  even without any equipment or loose furniture my Architectural model has the most component (individual objects) out of my three models.   However,  it is important to understand that just because it is in my model and I want to capture information about it doesn’t mean that I plan to manage it, so much of it will not be appearing on my COBie sheets.

As stated by NIBS, COBie is :

COBie is an information exchange specification for the life-cycle capture and delivery of information needed by facility managers. COBie can be viewed in design, construction, and maintenance software as well as in simple spreadsheets. This versatility allows COBie to be used all projects regardless of size and technological sophistication.

What’s important here is that the information is for ‘Facility Management’, this means that I need to consider which of these components that I (as the facility manager) need to manage my home.

Currently between my three graphical models I have hundreds of components (including the kitchen sink!).  These graphical models are intended to hold *all* of my components, but my COBie sheet is meant to exchange those components I maintain.  Note: Depending on when you have visited my house you may believe that it doesn’t get maintained at all!

For a component to be considered ‘maintained’ is quite subjective, and to be honest can often depend on the component itself.  Luckily as a starter for 10 the National Institute of Building Sciences (NIBS) in the US have provided a schedule of components typically to be excluded from COBie within their Information Exchange standard under table 102. When compared against my Architectural model a number of components are on the exclusion list such as: Roofs (3), Slabs (5), Stairs (1), and Walls (59).  That’s over two thirds of my components that I don’t need to include as they are not maintained.

Maintenance
Not having to consider over two thirds of my Architectural Model makes management of this data much easier.

To be honest that is a pretty good fit.  If I replaced my carpet in the living room, I haven’t maintained the floor, I’ve maintained a finish I’ve placed onto of the floor; the floor itself hasn’t been modified.  The same can be said for wallpapering my walls or painting my ceilings.  Which means that now only have to consider a third of my architectural model when it comes to answering my next PLQ.  This makes the process of creating and managing this information leaner meaning a much more manageable data set being exchanged.

Margaret Hamilton
While Margaret Hamilton was adept at writing code,  she didn’t limit the scope of her COBie export and ended up with a lot of unneeded data!

This being said, these elements still need to be modelled and filled with the correct data as while they might not appear in my COBie, they will be needed when any works are undertaken at the house.  So for now I have made sure that even if they appear within the NIBS exclusion table I have included them within my information model, but in a future post I will need to ensure any information exchanges exclude the right content.

Please remember that they are like *VERY* work in progress, but if you are interested to see my populated models without correct fully formatted attribute, they can be found here:

7001-BBH-XX-ZZ-M3-A-0001 (Architectural Model)
7001-BBH-XX-ZZ-M3-E-0001 (Electrical Model)
7001-BBH-XX-ZZ-M3-M-0001 (Mechanical Model)

Out of interest, I federating my models together I am very pleased with how well it represents the physical assets, and how the geometry has been kept to a minimum.  At the time of writing this post, my Architectural model is just over 12 megabytes (Note: less than 8 megabytes when exported into IFC!); the equivalent of two or three MP3 songs; yet has enough information to represent all of the fixed components within my house.

This slideshow requires JavaScript.

Fantastic, this means that I have now fully populated my architectural, electrical and mechanical models; therefore Plain Language Question PLQ2.4 is now complete!

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 my components, it’s time make sure the right data is included within each of them so let’s see what data is currently being exchanged and work out where the effort is required…

Note:  If you have any comments regarding my information model or how I have resolved these issues, then please let me know either on Twitter, or by commenting below.

PLQ2.4 – COBie Round 1

Dan6 Comments

Hello BIMfans,
After lasts weeks review of The Importance of being openBIM, this week I have managed to fully populate my mechanical model with all of the assets I want to capture within it to satisfy my Plain Language Question 2.4 (only Architectural and Electrical to go!).   The work in progress model can be accessed as both a Native Revit file, an IFC file, and have I even tried to do a COBie export to see where the gaps lie…

ComputerRage.jpg
Needless to say it hasn’t exactly been a smooth process so far.

While I haven’t given it too much thought, when creating new objects I have tried to ensure that I fill them with the information I need to answer my Plain Language Questions about attribute data; for the most part this has been successful.

Note:  So far all I have done is map over the COBie properties and my additional property sets, I haven’t tried to make all my sheets work; that happens during PLQ 2.5.  

However, nothing in life comes easy, and COBie is no different.  Shown below is a screenshot showing that my components have at least successfully transferred over some of their data with them.

MechCOBie
The file is far from complete, but if you want to see how my mechanical COBie file is shaping up, you can access it here.

At this point I have noticed a number of elements work well, and a number of elements work not so well.  Note:  It is worth pointing out that there is likely to be (an element of) user error as I have not fully investigated how to export this information correctly; yet.

The Good:

Because I have used the shared parameters and property set mapping files I introduced in the last blog post many of my properties are exporting correctly, such as: Bar Code, Serial Number, Material, Shape & Size.  I have also managed fixed my dimension error from last week thanks to Autodesk customer support (I had to change the data type from ‘Real’ to ‘Length’).  So the attribute mapping process appears to be going well.

The Bad:

I’m afraid that it isn’t all sunshine & rainbows however as some elements are not working exactly as I hoped.  Currently: ‘Category’ properties don’t seem to carry despite appearing within the IFC object’s properties, and something similar is also happening with ‘Description’.  As you can see below, my IFC file captures this information but when I use xBIM to create COBie the information just doesn’t seem to carry.

COBieCompare
Where has that hammer gone?

The Ugly:

It gets worse.  As the IFC export doesn’t capture data from linked files I need to create rooms/spaces in each model so that my components can export space information. This means that when I produce my combined COBie file I will need to delete duplicate space instances as I’ll end up with three Living rooms.  In addition, no matter what I do I cannot seem to get an object’s ‘Category’ to export and appear within the COBie type sheet  (or even other sheets when I tested them too) despite appearing within the IFC.  For matters like this I normally turn to xBIM’s Github but sadly I have not found the solution yet.

Finally, within my attribute tab, I am getting duplicate attributes.  It appears that despite being recorded as an instance or type property, when exporting some properties are coming out as both; making the sheet more difficult to read and much longer too.

Over the next few weeks as I complete the graphical element of my information model, I will also be looking into resolving these issues to attempt to create a bespoke IFC FM Handover that’ll include as much information to complete my COBie export as possible, and satisfy my data requirements.

But first, let’s focus on the matter at hand.  What assets are in my home?  Well here is a schedule of all the Mechanical assets I am including that fall under the responsibilities outlined within my Design Responsibility Matrix.

COBieIFCCompare.JPG
To be honest, at this point I just need to know how many assets I have.  I should just be happy that I have 10 objects within my IFC file, and 10 components within COBie too!

And there you have it, now that I have a schedule of my mechanical assets, I am well on my way to answering this Plain Language Question.  This means that subject to ensuring I follow suit my Architectural and Electrical information models; completing PLQ2.4 shouldn’t be far away!

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 Mechanical is sufficiently developed, it’s time to look at some more electrical objects…

The Importance of Being Open(BIM)

Dan2 Comments

Hello BIMfans,
Last week I started to build my mechanical model and had managed to compare different object vendors to select my preferred boiler object.  This week I have started to build my electrical model and wanted to discuss the importance of proper data formatting.  I need to do so to ensure that when information is exported from my native authoring tool (Revit) into IFC, it is formatted correctly.  As an active member of buildingSMART, I am a strong believer in open formats, and the importance of being open(BIM).

TheImportance of Being Open(BIM)

What is openBIM you ask?  In short, it is the use of non-proprietary methods to delivery asset information.  There is a short video that explains it better than I can here.

The non-proprietary method I’m referring to is Industry Foundation Class (IFC); think of it as the PDF of the built environment.  No matter what software you use to make a document, if you convert it into a PDF it’ll allow others to access this information without having purchased the software you used; this is what IFC achieves.  Note:  There any many other benefits too I won’t discuss here, but if you are interested I suggest you read Rob Jackson’s excellent blog post on Why Use IFC).

As IFC has a language (Schema), it comes with its own grammar (Property Sets) which includes acceptable words (Properties) that can be used providing consistency and the opportunity for validation.  For example, take my Nest Thermostat.  Under IFC2x3 (the current recommended release) it is classified as an IfcSensorType and I can associate a number of standard property sets to this object to define it.  Note:  In IFC4 a thermostat is a IfcUnitatryControlType, but for the purposes of this blog I am sticking to the recommended release of 2×3.

To make this a successful BIM Level 2 project, I need to export information about my Thermostat that I defined at the start of blog when I discussed my Model Purposes & Data Requirements.  As I discussed during these posts, I will need properties relating to condition, warranty, and manufacturer information.  By looking through the IFC Schema I can find suitable property sets and properties to include that are structured in a consistent manner.  After searching, I came up with the list below:

  • Pset_ServiceLife
  • Pset_EnvironmentImpactIndicators (for my energy use)
  • Pset_Condition (for monitoring until it requires repair/replacement)
  • Pset_Warranty (for reference when being repaired/replaced)
  • Pset_ManufacturerTypeInformation (because it is a manufactured product)
  • Pset_ManufacturerOccurrence (because it is a manufactured product)

Note:  I will also need any properties required for types & components to satisfy COBie within BS1192-4.  

The problem is that to do this properly, it take a lot of work.

To help, there is a COBie extension for Revit that helps create COBie files from the native file format (A requirement of PAS1192-2).  However, it does not create correctly named IFC properties and each property that is created is prefixed with ‘COBie.<sheet>.<property>‘, I also found it difficult to control which properties did export and which did not.  Because of this, I chose not to use the export tool.  Also, since I requested IFC as a deliverable within my EIR, I need to make sure that the properties are structured properly; so I have decided to do this the long way.

In order to get a decent looking IFC, I needed to define my property sets. Revit can’t do this.  So to do it I had to create a number of shared parameters and a custom property set definition file to allow them to export correctly using the IFC Exporter.  At the same time is also used it to define my COBie properties too (excerpt below).

IfcExportSample
A copy of the defined property set file can be found here.

Using this file, it moves object properties into the defined property sets.  This is important because in Revit you cannot create property sets.  Because you can’t all the properties end up under one of the pre-defined categories (I’ve chosen IfcParameters for many of them). However this definition file resolves this when exporting.

MappingBeforeAfter.JPG
Shown Left:  Properties in the Revit file, Shown Right:  Properties in the IFC file, Shown off screen:  My agony in getting all of this to work!

Note:  To view IFC files there are many viewers available.  For this blog I have chosen to use xBIM. xBIM is a free open source viewer that also has the ability to federate models and export COBie files.

IfcThermostat
You can access the IFC File for my electrical model here.

Now here is the exciting bit.  Because I have defined the property sets I require including all of my Data Requirements and COBie properties I am able to create my COBie data in a number ways including:

  • Export Revit schedules to transpose into a COBie template;
  • Export directly from IFC into COBie; and
  • Install the COBie Extension and remap its properties to use my IFC properties.

So whichever method I choose I have a good set of data I can rely on.

COBieExport
I have 99 problems, but my Thermostat ain’t one.

I will point out however that it isn’t all sunshine and rainbows.  There are a few problems that I still need to resolve when exporting into IFC:

  • I cannot get an object’s category to export properly;
  • Under my attributes tab, a number of properties have duplicate instances.

UPDATE:  I have an issue with my NominalLength and NominalWidth properties, but after contacting Autodesk they have advised me to use ‘Length’ instead of ‘Real’ during the property mapping to achieve this.  I have now tested it and it works perfectly, so thank you Angel & Autodesk!

I will continue to explore this and will report back in the future post, but if anymore has any ideas feel free to let me know!

And there you have it, after reviewing how I create my information, I have now developed an openBIM workflow that allows the information I have created in Revit to be exported as an IFC, and this IFC aligned data can be used to create a fully populated* COBie file. Because of this my data is well structured and most importantly consistent with an international schema.

This means that if I apply this process to all of the assets within my model I should then be able to answer this Plain Language Question, and will have all the information I need to have delivered a fully compliant BIM Level 2 Information Model.  So let’s get to it!

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 started my electrical model, it’s time to add other assets such as my lights and fire alarms…

Note:  If you have any comments or opinions regarding my openBIM process, please let me know either on twitter, or commenting below.

PLQ1.2 – Data Requirements

Dan2 Comments

Hello BIMfans,
Now that I have worked out what Model Purposes I will be using my information model for, I need to work out what information to produce to satisfy these Model Purposes.  To do so, I will be looking at several key British Standards around exchanging information.

I’ve already discussed information exchanges when I formed my Plain Language Questions (PLQs).  In brief, within the BIM Level 2 process, there is a clear mechanism outlined within PAS 1192-2 to allow information to be exchanged from the supply chain to their employer.  The UK Government has outlined that its preferred method of exchange is through Construction Operations Building information exchange (COBie).

COBie
Don’t let her acting career fool you,  Cobie is a key actor in BIM.

So why COBie?  Well within the UK there is (currently) no formal convention on how to structure information.  The relevant British standard for applying properties to objects is BS 8541-4.  However, this standard is limited to: Guidance information on units, to name properties using CamelCase (no spaces), and that properties suggest what type of data should be used within.  However, BS 8541-4 uses examples that conflict with its own guidance…

Capture
CamelCase? No thank you, I don’t smoke.

However, despite this conflict, BS 8541-4 does provide real value and quite usefully refers to using the Industry Foundation Class (IFC) schema, which covers property naming, units, and property sets; developed by buildingSMART.  So I will limit myself to properties that appear within the IFC schema, specifically using the IFC2x3.

Luckily for me, by following IFC, I will also need to provide information in a COBie compliant structure.   In brief, COBie is an IFC file filtered to remove geometry and retain only the information to be handed over, complying with the COBie 2.4 MVD. Meaning that if I use the IFC2x3 Schema to add attributes, mapping to COBie’s structure should be a fairly simple process.

Note:  I’m not going to explain COBie in detail here, but if you want to know more Rob Jackson of Bond Bryan Digital has collected several COBie resources on one easy to access web page here.

So by using IFC, I can structure my asset information based on an internationally accepted open data schema. Meaning that I’m more likely to be able to use this information in other tools.  If I didn’t use IFC, then there would no doubt be issues with exporting information:

GiGo
Garbage in = Garbage out.  Explains the need for good data in construction (and my A-level results).

So now that I how I want to structure this information, I need to work out what information I want to capture based on my intended Model Purposes.

Register

I want to use this model to register each of my components.  By registering these components I can keep an inventory for content insurance purposes and to facilitate any other purposes such as repair and maintenance.  To register my components I need to include a unique reference, so I’ll need a ‘GUID‘, as well as the component’s ‘Name’ ‘Manufacturer‘, ‘Model‘, and if applicable ‘ModelReference‘.  I will also need to know when each component was installed my including an ‘InstallationDate‘, as well as its ‘ReplacementCost‘.

To register each of these components I also need to know what room they are in, so I need to register my rooms including ‘Name‘ and their ‘Description‘; both found under ‘IfcSpace‘.

Operations

As I stated when discussing my Model Purposes, this model will likely not be used for day-to-day operation, but I do plan on using information from the model to undertake a future SAP calculation, and will likely need to use this information if I have many minor works done to my home.  By capturing this information, I will also have the information needed to run any operational analysis in the future.

For the house itself, I need to know the ‘NumberOfStoreys‘ the house’s air permeability ‘Infiltration‘, as well as a custom property for my EPC Rating.  I couldn’t find a suitable property within the schema, so I will create one called ‘EPCRating‘.

For my floors, I need to know their ‘Height‘, ‘Area‘, and ‘Elevation‘.  Each of which can be captured by the base quantities.

For components (where applicable) I will also need to capture their geometry details such as ‘Height‘, ‘Length‘, and ‘Width‘.  Details of components specification such as their ‘ThermalTransmittance‘ (U-Value), ‘Infiltration‘, as well as the ‘TotalPrimaryEnergyConsupmtion‘ for any electrical components.  In addition, I couldn’t locate a property for SolarTransmittance (G-Value) under the IFC2x3 Schema, so I will need to create another additional attribute ‘SolarTransmittance‘.

Maintenance and Repair, Replacements

Much of the information identified to register my components will also be used to manage any repair and replacements.  In addition, I will also need to capture warranty information such as ‘WarrantyStartDate‘, ‘Duration‘, and ‘WarrantyContent‘.  In addition, to schedule any planned maintenance, I need to capture asset condition details under ‘AssessmentDate‘, ‘AssessmentCondition‘, and ‘AsessmentDescription‘ to form a preventative maintenance schedule.

And there you have it.  By using my Model Purposes I have now outlined the minimum attributes I need achieve them.  Meaning I have now answered another Plain Language Question; PLQ1.2 Complete!

Brief:
1.1 Have the model purposes been defined?
1.2 Are there any specific data requirements to achieve these purposes?
1.3 What format shall the information be delivered in?
1.4 What standards will be followed?
1.5 What level of accuracy/detail/development is required?
1.6 Is there sufficient information to produce an EIR?

Now that I know what information I need to support my Model Purposes, I need to establish what format I need this information in to make sure it is usable to satisfy PLQ1.3…

Note:  If you have any comments regarding my property data requirements, or the properties I have chosen, then please let me know either on Twitter, or by commenting below.