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 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 – M&E Review

Hello BIMfans,
After releasing my Architectural model last week for review, this week it is time for me to release both my Mechanical model and Electrical model; completing the set of deliverables I aim to produce for my home from my Information model.  I have already had a few comments come in about my Architectural model, so please keep those comments coming in (be as pedantic as you like, honestly)!

Why is my house now transparent (maybe because all the clubs have been closed down or too much fighting on the dance floor)?

Much like last week because in my BIM Execution Plan I am: Author, Checker, and Approver of all the project information, I am recruiting you to review this information on my behalf.  As with my Architectural model, there will be a fortnight given for any comments that come out of this review so that I can update the information before it is formally released. The first person who suggests each amendment will be credited on here when the information is authorized and considered complete.  Think of yourselves as the Task Information Managers for my project.

Yes it’s the same image from last, yes that seems a little lazy, yes I don’t care.

I will cover these in greater detail next week, but here are some of the comments I have already had back.

Volume Code:

I was correctly informed that I should be using ZZ instead of XX for my volume code, as specified in BS1192. so I have preemptively addressed this in my Mechanical and Electrical models, and revised my BIM Execution Plan.


I was asked why I don’t clean or maintain my house as my job sheet is blank.  As Revit cannot record these jobs, I’d need another database. I will create this schedule when I begin to look at my Operational Plain Language Questions in the new year.

Maybe I can use it as an excuse to get a Roomba


I have also been asked why there are no designers risk assessments linked to my COBie documents tab.  Luckily for me, I have done no design on this project (and have no PI insurance to back it up!) so there are no risk assessments as a result.

In accordance with my Employer’s Information Requirements, and BIM Execution Plan I intend to issue the following information:

Graphical Models

Non-Graphical Data


  • None

So please go forth, review, and report back.  As I mentioned last week, these models aren’t perfect, and my terrible spelling with have caused typo’s throughout; so there will be plenty to find (I won’t be crediting typos; there is only so much space I can give to a blog post).

As with last week, the purpose of the native models have been purely to create the other deliverables so it is OK if that is a little rough around the edges.  For context, from the Native Models I have produced the drawings listed above as well as my FM handover IFC model which was then used to generate my COBie deliverables. Note:  For transparency, I have marked all of the modified fields in my COBie as red. What is important is the quality of the deliverables.

Also now that I have multiple models, feel free to run some clash detection too.  No, not that clash…

And there we have it, subject to your scrutiny I have now completed the deliverables associated to my Mechanical model and Electrical model.  This means that once these items have been approved and authorized, I will have completed PLQ2.5 for my all of my information!

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 Mechanical and Electrical information out for review, let’s release my Architectural information…

PLQ2.5 – Architectural Review

Hello BIMfans,
It has been a long time coming, but after thinking about my GUIDs last week this week I have a special treat for you.  I have completed all of the deliverables associated with my Architectural Model, so I thought I would share them with you.

If only I could find out how to add colour…

Now you may have noticed that in my BIM Execution Plan, I am Author, Checker, and Approver of all the project information; this isn’t exactly a good way to managing the exchange of information.  Therefore, I am recruiting you (yes you, no not the other people who read this blog, specifically YOU!) to review this information on my behalf.  There will be a fortnight given for any comments that come out of this review of the information before it is formally released.  The first person who suggests each amendment will be credited on here when the information is authorized and considered complete.  Think of yourselves as the Task Information Managers for my project.

…to review his deliverables

In accordance with my Employer’s Information Requirements, and BIM Execution Plan I intend to issue the following information:

Graphical Models

Non-Graphical Data


The purpose of the Architectural model has been purely to create the other deliverables so it is OK if that is a little rough around the edges.  There are limitations on renaming system families and other little quirks I can’t seem to get past using the software in it’s default form.  From the Native Model I have produced the drawings listed above as well as my FM handover IFC model which was then used to generate my COBie fileNote:  For transparency I have marked all of the modified files in my COBie as red. What is important is the quality of the deliverables.

Now I am going to be 100% honest here.  These files are not perfect.

There are three main reasons for this:

  1. I have been ill all week so I haven’t been able to give it the time (IfcViolin);
  2. There are still data export issues out of Revit I have yet to resolve; and
  3. I’m bound to made mistakes due to human error (and the fact I can’t spell).

But what’s important to remember is that this isn’t an exercise to show off a perfect model (it is far from perfect) it is an exercise to locate and fix anything that I have missed that will adversely affect how the deliverables impact on how I undertaken my Model Purposes.

If I have avoided causing these issues then these items will be authorized and I will have produced a native model, COBie, and a number of PDF deliverables to BIM Level 2 that satisfy both my Employer’s Information Requirements, and BIM Execution Plan.  Fantastic.

And there we have it, subject to your scrutiny I have now completed the deliverables associated to my Architectural Model.  This means that once these items have been approved and authorized, I will have completed PLQ2.5 for my Architectural information!

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 Architectural information out for review, I need to publish my Mechanical and Electrical models…

PLQ2.5 – To GUID or not GUID?

Hello BIMfans,
After last week’s post COBie Round 2 where I managed to solve many of my outstanding COBie issues, I was planning to provide an informative post about asset management as I was having my gutters replaced; sadly plans changed. *sigh*

Despite giving a very detailed explanation and approving an itemised quotation, my builders showed up with no clue of what work needed doing and once they were briefed and checked the stockists told me that they needed to pre-order the materials after they arrived on site to install (Don’t worry, they will be getting terrible review on Rated People!).

Two key points that resonate out of this omnishambles:

  1. The best laid plans of mice and men often go awry.  Documents aside, how can I ensure that they can be turned into actions?
  2. I need a gutterer. If anyone knows someone who can come and fit new fascia, & gutter to my home; please let me know (Please!).

What is an Asset Identifier?

The work I was having done to my gutters got me thinking about Asset Identifiers and their use.  When I defined my Data Requirements I noted that I need to have a unique identifier for each of my assets so that each one has a unique reference to be registered, one of my Model Purposes.

Good management (and good graphics) need good data.

According to the BRE BIM Terminology Tool, a Unique Identifier is:

Role of a character string when used for unambiguous reference to a concept or to an individual thing (e.g. a physical object or an aspect or a fact or a relation type) and that is unique within a particular common context, preferably in a universal context

By applying a Unique identifier to my components, I will have their Asset Identifiers.  To save on effort, I initially thought it would be a great idea to use each component’s Globally Unique Identifier (GUID) as the asset identifiers.  To do so, I had set my HandoverMapping file to populate the AssetIdentifier field with their respective GUIDs.

Doing this is a stupid idea.

While it might seem logical at first as it does provide a unique identifier for each asset, I can’t control the GUID generated.  For example, shown below is the same door created in two difference instances of my house model.  Each was placed in the same location, when created each door and was given the same mark, but different GUIDs,

Not only are both GUIDs different, but I can’t change them.

Because I can’t change an object’s GUID it means that if I wanted to recreate my house model it would be impossible to match the same GUIDs, making them pointless as Asset Identifiers.  So I will instead be using numbers I can generate on‘s string generator.


What Triggers an Asset Identifier Change?

Now having an Asset Identifier is one thing, managing it is quite another.  If the builders had actually done what I expected, I would have new gutters; should these new gutters get a new Asset Identifiers?  To get an idea I asked Twitter:


As you can see, the majority of voters opted for a new identifier (and I agree) but it depends on the situation, as it is not manageable to do this every time an asset is modified. Therefore, I need is to define what operational actions are considered to be ‘trigger-related events’.

According to the BRE BIM Terminology Tool, a Trigger Related-event is:

Response to a trigger and the reflection of the altered state of the asset in the AIM

Information around triggers and trigger-related events can be found within PAS1192-3.  In particular, Annex A.5 provides a schedule of triggers which includes asset replacement. So I have decided to instigate what I am calling the ‘Sticker rule’.


Imagine that every component in my home has an asset tag sticker.  Any trigger that involves replacing a component will need a new sticker, because the current one is stuck to the old component (on its way to the tip); a new sticker means a new asset identifier.

So to capture this I have modified my Employer’s Information Requirements to include the following clause:

When managing the information model during operation, asset information shall be updated following the schedules trigger-related events below:

  • Receipt of information following minor works;
  • Receipt of information following major works;
  • Performance evaluation of an asset;
  • Condition evaluation of an asset;
  • Maintenance work on an asset, whether planned or reactive;
  • Asset replacement; and
  • Change in maintainer of an asset.

Where a trigger-related event has resulted in the replacement of any assets, those assets shall be given new Asset Identifiers.

Who knows, maybe when I eventually find someone to do some work on my home, I might be able to put this into practice!

And there we have it, by thinking about how I am going to use my asset information I have started to establish a simple and pragmatic trigger event strategy to control how and when I update my Asset Information Model.  All good information to help 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 a system in-place, I need to do some data entry into my model…

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.5 – BEP Revisited

Hello BIMfans,
After looking into the follies of language in our cold digital world, I wanted to revisit my BIM Execution Plan (BEP).  The reason for this is because my BIM Execution Plan is the guidebook being used to create my information model; the clearer it is, the better quality the information contained within the information model will be.  So, it is time for an upgrade.

Looking over what I have done so far, there is a lot missing from my current BIM Execution Plan.  It’s for for it to mushroom into a much more usable document.

Going through my BIM Execution Plan now that I have started to create content, I have noticed a few items and headings that I should have included which can be summarised as:

  • Revision and Status Code Details;
  • Classification;
  • Object Naming; and
  • Attribute Data Conventions

Now the great thing about a BIM Execution Plan is that it is a Live & Evolving project document, meaning that there is no issue with revisions to the document so long as the impact of those changes have been fully considered.

Revision and Status Code Details:

While I have previously specified compliance to BS1192, in reality that isn’t good enough, as it is possible to misinterpret the use of these codes.  So I have included the following diagram as an aid:

Instead of focusing on where the document sits in the Common Data Environment, I have instead focused on the level of approval/authorization the file has been given.

For example, many believe (as I did not so long ago) that if they were issuing information to an estimator that they would use the status code D1; this is incorrect.  As you can see from BS1192, table 5 ‘suitable for costing’ relates to unapproved information.  The intention is that this code allows information to be given to someone (like as a manufacturer) to get a unit rate cost to then be used as part of generating the cost estimate.

To enforce this I have included the following clause within my BIM Execution Plan:

D codes shall be exclusively for unapproved information exchanged to aid in at-risk preparatory work.  Information with a D code status shall not be referenced to generate any deliverables.

In summary, if you see a D code, think ‘D, do not use’.  As you cannot rely on the information within, as it hasn’t necessarily been approved by the authors task team.


In order to ensure a simple application of class, objects will need be classified by a single classification code.  This means that while some might have a Swiss army knife of functions, they will be classified by their primary function.  For example, my phone is a computer, camera, and sensor (and as it is a Samsung, a potential tool for arson) but is marketed as a phone; so my Nest Thermostat will be classified as a thermostat* and nothing more.

To enforce this I have modified by BIM Execution Plan to include the following clause under 5.8, and amended Appendix E to suit:

Only a single classification code shall be included on each object which describes its the primary function.  Classification shall be included in the Attribute ClassificationForObjects included within Appendix E.

Typically ClassificationCode is used as default, but as ClasssificationForOjbects is included within IfcClassification I have opted to use this instead.

Note:  There is no thermostat in Uniclass 2015, so I have had to default to Mechanical Services Control Product.

Object Naming:

We have discussed how to name objects in previous posts, so I will not repeat myself here.  However, as I mentioned last week it isn’t always as simple as complying to the standards; for one there is no guidance on Type Naming.

To enforce this I have modified by BIM Execution Plan to include the following new Heading and clauses under 5.4 Object Naming:

To satisfy EIR, section 3.5 all objects produced will be named in accordance with BS8541-1.

Specified below are the permitted values for each field.

Source Type SubType
See Ifc[Type]


See …TypeEnum
See product name

All objects types shall also be named following the following convention: […TypeEnum]Type[Number] e.g DoorType01.

By using the objects allowed enumerated values I get a consistent a human readable set of Object Types

Attribute Data Conventions:

Finally to control the application of consistent attribute data I have come up with the following convention which has been included within my BIM Execution Plan:

I now have a consistent (and likely controversial) way to naming my direction attributes.

For consistency I will be using the following convention:

Width      = X-Axis (across the front)
Depth      = Y-Axis (across the side)
Height     = Z-Axis (up to the top)

For a Boiler it is rather simple. It has a Height, Width, and Depth.  As it has no profile it is given no Length, leaving Height and Width to appear on the type worksheet, and Depth to appear on the attribute Worksheet.  While this may seem a little messy, the benefit will be realised once the information is exported out of COBie and into a data management system (who knows what you would measure if someone asked  how ‘long’ your boiler is).

For a Door this can applied in a fairly straight forward manner.  My doors have Height and Width, but depth is controlled by the host so it isn’t required (as it is instance driven); so I only need to record Height & Width.  Once again, as it has no profile it is given no Length.

My Kitchen worktop on the other hand is a little more complex.

As you see the profile used is the side of the worktop (Y-Axis), meaning that the length is  perpendicular (X-Axis).

By modelling my kitchen worktop the way I have the profile has a Height of 38mm, a Depth of 625mm, and a variable Width (Width=Length).  This means Width isn’t required (as it is instance driven), leaving Height and Length and to appear on the type worksheet, and Depth to appear on the attribute worksheet.


And there you have it, by spending a little longer sorting out my BIM Execution Plan, I have a much tighter set of Standards, Methods, and Procedures to following which will resulted in a better data set now I am at the final stretch in completing my information models…

PLQ2.5 – Attic-tion to Detail

Hello BIMfans,
After considering the Type Trouble I have been having when looking at my doors, I decided put some more work into Architectural Model.  This week I have tried to give my attic some attention, so it was time to get up the ladder and have another look.

If any of you reading know me, you’ll know that I’m no da Vinci; so I apologise in advance for the quality of the sketch below.  To develop my Architectural model, I decided to first draw out a few of my key junctions, measure the relevant elements, and then produce my information model.

Model progression:  Sketch of Junction (Left), Unedited callout of junction from graphical model (Centre), detailed callout (Right).

The reason I developed my graphical model this way was to limit the amount of overall modelling that I needed to do.  I’ve discussed Level of Definition before as I am a firm believer of modelling as efficiently as possible.  For example, to limit the amount of modelling I need to do for my roof I have set a number of informal ‘volumes’ within the roof itself using Revit’s built-in system family layering function:

Top: Tiles, Middle: Battens, Bottom: Rafters

So what is a Volume? Well thanks to the BRE Terminology tool, a volume as described within PAS1192-2 is:

Manageable spatial subdivision of a project, defined by the ‘project team’ as a subdivision of the overall project that allows more than one person to work on the project models simultaneously and consistent with the analysis and design process.

While formal volumes can acting as a tool for simultaneous working, I have also used informal volumes to limit the amount of modelling required.  Each volume, as a subdivision of a project, is effectively a geometric space assigned for a particular system, element or array of components to be populated within.  Typically, as the design develops these volumes can then be assigned to sub-consultants who would then populate them with their objects.

A volume strategy is no different than a 3D ‘Paint by Numbers’.

Therefore these informal volumes I have created for myself can be used in two ways.

  1. As a substitution for objects.  For example, it would be practically impossible to model each roof tile and batten, so instead volumes are used.  This also applies to other elements such as Walls (who’d model every brick?); and
  2. As a placeholder for objects.  For example, my rafter volume was drawn initially as a substitution, but this week I have added them to my model.  If objects are placed within their respective volumes, then a clash free model can be created as any clashes that may occur within this volume are ‘known’.
As you can see, my rafters and joists have been placed within their volumes.

Finally, to sort my attic I also had to have a look at my party wall.  Now very interestingly my party wall isn’t fully constructed (apparently this was fairly common when terraces like mine were constructed).  This along with its annoying complex interesting profile has allowed me to generate some unique geometry to complete my attic.

While I admit that the exact profile of the party wall is an estimate, it provides a much more accurate  account of the existing physical conditions compared to earlier iterations of my Architectural model, accessible here through A360.

By completing both of these elements of work I have also been able to generate another Stereo Panorama, with my partially constructed party wall providing a convenient light source when it was rendered (thank you Victorian builders?).

And there you have it, by exercising some attic-tion to detail (sorry!) I have now captured the geometry of my attic, as well as some useful elements that will aid future posts such as the amount of loft insulation and my half constructed party wall.  Now that my Attic is sorted, I wonder which other parts of my Architectural model also need to be optimised before I can consider it complete…

PLQ2.5 – Type Trouble

Hello BIMfans,
After looking at how I will be Bridging the Attribute Gap, I have now started to finish populating my graphical models to satisfy my graphical and information requirements. However, a practical problem has appeared which I wanted to share you with around type naming.

A while ago, I discussed good practice around 3D Modelling & Object Naming, this related to the file name (how you would find that file in a folder) using BS8541-1 to the point that I am able to use pretty effectively name all of the objects (that Revit allows me to rename). What we didn’t discuss is type naming, now Rob Jackson of Bond Bryan talks about it much more detailed in his blog here, but put simply an object’s type name also needs thorough consideration.  However, as I didn’t properly consider them a problem has been brought to my attention;  let me explain.

When is an IfcDoor not a door?  When it’s an IfcJar!

Shown above are the different door families in my home.  Each family has a unique name and happen to only require a single type which I have named following Revit’s guidance for type naming through using a dimension-based type name.  Meaning that the family and types names are as follows:

  1. BBH_Door_FourPanel;
    .  830x2035mm
  2. BBH_Door_Stair;
    . 600x1760mm
  3. BBH_Door_Trapdoor;
    .  680x680mm
  4. BBH_Door_TwoPanel; and
    .  830x2035mm
  5. BBH_Door_SixPanel.
    .  830x2560mm

Can you spot my problem yet? No, neither could I at first.

The way families & types work in Revit means that an object’s type isn’t necessarily unique.  This isn’t a problem in Revit, but can be a problem when exported into other tools and systems, such as when I export into COBie.

Which 830x2035mm is the one I want?

Ideally an objects type should be unique and human readable so that it is clear which object is being referred to.  To do so, I can see two solutions:

Family & Type

The term type can be a misleading one.  In BS1192-4, type is defined as the named specification for components which means that using ‘Revit Speak’ both the family & type constitute the object’s type.  This means that if I could export the object’s type as <<Family>>:<<Type>> I would have a unique reference for each type.  However, while this isn’t supported by the IFC Exporter it is supported by the COBie Extension for Revit which solves the problem for COBie, but means that there isn’t a supported solution for any other exchange method, such as IFC.

It’s functionality like this that really let’s the COBie Extension for Revit shine.


A more practical solution then may be not to describe the size of the object but instead give it a name that is easier to understand.  Both Revit’s guidance and the definitions within the IFC Schema refer to what I call the ‘<<Type>>N’ method, for example using a type name such as DoorType01 to describe each object’s type.   For a scheme like mine (without any design) this can be easily applied, but for a more iterative project an issues can occur if a Type becomes redundant during the development of the graphical model.

So let’s give it a go.

As you can see, I have replaced all of my dimension-based types with a type description based on the order you’d find them in my home.

This method doesn’t change how my doors are set up in my model but provides two advantages.  The first is that when this information is exported into COBie there is no duplication  which means that it is clear which type is which.

Instead of being unsure which 830x2035mm I need, I can instead just use DoorType04, easy.

There is another advantage too.  If a dimension-based type name is used then there is a chance for error due to the manual input as well as the need to update the name each time a change to the object occurs.  Using a name such as DoorType04 mitigates these potential issues.

And there we have it, by considering how I name my types, each type now has a unique reference that doesn’t duplicate other data and is less prone to error.   This means that once I have replicated this throughout my model I will be well on my way 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 know how to resolve my types it’s time to explore my other attributes so that I can capture all my required metadata.  But first I want to tell you about my year with Nest…