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.

 

spring-cleaning-your-website
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.

CDE-IM

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.

Kitchen.png

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.

Component.Name

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!

Type.ExpectedLife

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.

Type.ReplacementCost

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.

COBieCosts

Documentation

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.

 

ViewsOnBorders
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.
SingleSource.JPG

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.

Advertisements

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s