PLQ 3.3 – Summer Sort Out

Hello BIMfans,
For those of you who know me outside of this blog, you’ll know that I have been quite busy over the last few months getting married, presenting to key stakeholders, and doing some pretty exciting standards work (#HumbleBrag).  As such, I haven’t given my information model the attention it deserves.  So before I get my cost my preventative maintenance schedule I decided to roll up digital sleeves and have a summer sort out.


No, I don’t want no scrub! My model only needed a little TLC

So, what do I want to sort out?  Well as you know, there are three parts to an information model.  The graphical model and its associated renditions (i.e. exports like my IFC files), non-graphical information, and the PDF immutable documentation.


So, let’s see if these previous posts will help me improve any of these parts.

Graphical Models

Electrical Model

Following a previous post where I created a Google Home object, the electrical model has been updated to include it.  In addition, I have also been tweaking each of my graphical models to remove several z-fighting issues (trust me, this is nowhere near as cool as it sounds) to improve how my models export into a VR environment.

Architectural Model

Also, around my kitchen, I have updated the materials, altered the component names (see below) to remove a duplicate type name.  I have also worked out how to get my sink to cut through the work surface and cabinet correctly (this drove me mad, I ended up having to cut a hole in my worktop to sort it).  This brings my kitchen much closer to what has physically been built.  Note:  In a future post, I will contact Howdens and find out exactly what components were used.


Model Naming

In addition to revising my graphical models, I have also changed how I name my models.  Previously, you may have seen on this blog IFC files with the file type ‘M3’ for 3D models. After John Ford asked the question, I agreed that ‘M3’ wasn’t the most suitable and felt that it should be ‘MR’, for model rendition.  So, as always, when in doubt I turn to Twitter.

As you can see ‘MR’ was voted the most popular (phew).  This makes sense because I use my IFC files to create COBie, not instead of COBie.  If I was delivering these files back to a client I’d have used ‘IE’ (information exchange).  However, as they are effectively filtered renditions of my native model, ‘MR’ is most appropriate.


Non-graphical Information

Thanks to my previous blog posts I’ve managed to update several areas within my non-graphical information.


Following a post where I collected Naming Conventions, I have now updated the component names to suit.  The convention I have chosen to follow is:

  • Type.Name:  <IfcType>Typenn e.g. WindowType01
  • Component.Name: <<IfcTypeEnum>>nn* e.g. Thermostat01

The exception to this rule is when the IfcTypeEnum does not suggest what the component is my itself.  For example, only a few people (except losers like me!) would know that ‘Water01’ is a boiler or that a ‘UnitaryControlElement’ is a Thermostat.  When these instances occur, I use <IfcType>nn instead giving me ‘Boiler01’ and ‘Thermostat01’ respectively.  Note: This also allows me to be pedantic and refer to my radiators as convectors, so win-win!


Following a previous post where I calculated the Return on Investment of producing my information model, I have now incorporated each component’s expected life.  The service life of these components will be very useful when calculating my maintenance budget.


Also in preparation for this maintenance budget, I have added (for objects I could google…) relevant replacement costs.  This was effectively done by comparing my existing components with their B&Q or Wickes equivalents, leaving those I couldn’t find as ‘n/a’.  Despite a few omissions, these costs will help calculate my maintenance budget and have helped fill my COBie files with even more information.



View References

Finally, following the changes to Component.Name, I have updated my drawings as any name changes impact on my door and window tags.  While doing so, I took the opportunity to update the logo on my title blocks, as well as include a view schedule on each of my drawing sheets.  Placed in the bottom left of my drawing sheets, I now know what views are included on each of my drawings.


Referenced, for my pleasure.


And there we have it.  These improvements to my information model not only help me achieve my Model Purposes but also help ensure the relationship between each part of my information model.  As a result of this Summer Sort out, I have consistent component names across my graphical models, non-graphical information, and documentation; reinforcing the fact that I manage my home through a single source of truth.

Note:  If you have any comments regarding my summer sort out, then please let me know either on Twitter, or by commenting below.

Update:  Included changed to IFC file naming following a query by John Ford.


PLQ 3.3 – Understanding Uniclass 2015

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 on my doors isn’t exactly how it should be used, so I wanted to share with you why, and the changes I needed to make.

NOTE:  Sarah has written an article on Uniclass 2015 which was a big help in getting me to understand.


Ok, a quick bit of context, what is a classification system?  Basically, it is a method of classifying or categorizing objects to differentiate between them.  Classification impacts everything, from the Tree of Life, and the age-old debate around Whether Jaffa Cakes are in fact Biscuits? (A debate based on avoiding VAT), to how we decide what parts of a design are the responsibility of which professionals.

Note:  I have no idea where Jaffa cakes sit on this diagram

In construction, there is an International standard for forming classification systems, ISO 12006-2 (you’d think I was on commission with ISO by the number of these standards I reference).  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 classification systems to be created aligned to this standard.  Now before any QS/Estimators kick-off comment, I will point out that the RICSNew 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.

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 so that if exports into IFC, an object’s classification code and description need 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.

The default value is ‘ClassificationCode’, I was just being awkward changing it.  It also made using objects from a 3rd difficult as I would have to change its properties to exchange any classification information.

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


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 managed 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 maintanence schedule?…

PLQ 2.5 – Information Model Complete!

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.

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.


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!

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…

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.

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.

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

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.


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.

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.

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!


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?

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

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.

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’…

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?

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.

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…

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!

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 NIBSCOBie 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.

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

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…

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.

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.

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.

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)

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).

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.

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.

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.

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

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).

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…

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:

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.


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‘.


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!

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.