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.

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:

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.

Classification:

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.

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
Author, Manufacturer	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.

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:

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.

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…