Language, the not-so-silent BIM Killer

Hello BIMfans,
After giving my attic some attic-tion (sorry,  again) I wanted to talk to you about an issue I am having.  This issue isn’t directly related to production of my graphical models or information, but it is having a BIG impact on both of these; it’s language.

bimaroundtheworld
As a man fluent in three languages (Welsh, English, and Sarcasm) I often consider the failings in how we communicate.

Our language(s) are incredibly analogue, making it difficult to fit what we say into our logical, cold, and uncompromising digital world; with English is particularly difficult.  As a quilt of a Language, English has inherited many inconsistencies such as: Strange pronunciations (Slaughter is Laughter with an S at the front), and inconsistent terms etymology (Pig is German, while Pork is French).  Languages like Welsh on the other-hand are phonetic, and use consistent terms (Moch = Pigs, Cig Mochyn = Pig Meat).

Most of you (at least according to the blog’s analytics) will be glad to hear that this ins’t a post about the superiority of the Welsh Language, but it is instead a post about the follies of trying to digitise information using the analogue method of communicating and structuring information known as language.

Classification

Our world isn’t black and white (Zebra’s & LinkedIn Profile pictures being the exception), so it is easy to misclassify (or overclassify) objects.  From the Tree of Life to Uniclass 2015 it is not an easy job to provide order to this chaos; leading to difficulties when trying to classify.

platypus
“What do you mean mammals don’t lay eggs?” Platty also finds classification a difficult concept.

I’ve written about my Nest Thermostat previously but I didn’t mention its classification. My Thermostat, being a clever tool, functions as many things and therefore could be classed under Uniclass 2015 as a: Pr_70_70_47_21: Daylight Sensor, Pr_75_50_76_73: Room Temperature Sensor, Pr_80_51_85_21: Data Logger, Pr_40_30_25_23: Display Screen and many others.  Its primarily function however is as a Thermostat, with the closest classification I can find being Pr_75_50: Mechanical Services Control Product.

This means that while everyone on a project might be using a single classification system, there is to guarantee that they will use it consistently.

Would everyone classify my Nest Thermostat as Pr_75_50: Mechanical Services Control Product?

Naming

Just like classification, we are also terrible when it comes to naming.  For example, due to the fact that radiators emit 80% of their heat as convection, and 20% of the week as radiation; radiators are actually convectors.

radiatoridentity
The Sequel to the 1988 action comedy took a very experimental turn…

In addition: Models aren’t federated, federation is for federal unions; they are really integrated models; Gargoyle have water spouts; without spouts they are grotesques; and BIM barely has any acronyms.  Acronyms are spoken as words, meaning that terms like EIR, DRM, TIDP, MIDP, IFC, IDM, bSDD, and BCF are actually Initialisms. +10 Pedant Points

To show how complex naming can be, last week on Twitter I asked how to name my Amazon Dash Buttons (Wi-Fi enabled buttons for ordering products off Amazon), and the results were inconclusive.

classificationtweet
When is a ContactSensor not a Switch? When it’s a CommunicationApplicance…

This means that while everyone on a project might be following the same Object Standard, and even using the IFC Schema to limit their choice of relevant Types and Sub-types, there is to guarantee that they will use them consistently.

Would everyone name my Amazon Dash Buttons as CommunicationAppliances? Not even I would, as I’d use Switch_MomentarySwitch.

Distances:

In mathematics numbers have an order for numbers.  We have:

  • Cardinal numbers, the principle set of numbers;
  • Ordinal numbers, used to provide a ranking; and
  • Nominal numbers, used to identify (not necessarily by rank).

The same can also be applied to Directions for both Cardinal or Ordinal, but what about Nominal?  Well as nominal numbers are used to identify, then Top, Bottom, Front, Back, Left, & Right can be considered Nominal Directions; but how to measure these distances?

If I wanted you to measure the distance across the front of a cube, what are you measuring its length, width, breadth or depth?  The answer will differ depending who you ask as there is no consistency on how we name these distances.

This isn’t a new topic, many have discussed it previously such as Practical BIM when considering Which Direction is Depth?, and more recently Keith Wilkinson is conducting a survey to gain a consensus on what to call these directions.

cubenames
How would you identify these distances? Why not try Keith‘s survey, which can be accessed here.

In many commercially available authoring tools, you are able to name (and in my case misspell) these distances anything you like. So while we might instinctively know what to measure when asked how tall a door is, when we are asked how wide a cabinet is; there is plenty of room for varying interpretation.

This means while everyone might be using the same language, variation in how it is used can change the values recorded against attribute data such as Height, Width, Depth, & Length; all of which are required by COBie.

Would everyone call distance B width, and distance A depth on this cube?  What about a more complex shape?

On this project I have specified Uniclass 2015, BS8541-1, COBie, & additional EIR attributes so I have a consistent method of classifying, naming, and attributing data. However, it is one thing to specify their use, and quite another to ensure that they are being used consistently and appropriately.

The only way to ensure that the application of this information correctly is to further qualify their use within my BIM Execution Plan, it looks like a revision is in order…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now that I have started my electrical model, it’s time to add other assets such as my lights and fire alarms…

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