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…

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.

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.

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.

<<Type>>N

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.

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.

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…

Hello BIMfans,
After completing another Plain Language Question last week when I considered what components should be excluded from my model when I create my COBie.  This week, before properly considering two aspects:

1. Where best to store and manage the data; and
2. What’s missing.

By doing this, I can clearly define the data gap that’ll allow me to complete my information model; surprisingly, I am a lot closer than I had thought.

Where best to store and manage the data?

Now it is worth pointing out that I have already put a lot of consideration into what attribute data I want to capture.  I did so by defining my Model Purposes, which led to the definition of my Data Requirements.  Which helped filter down the information I want to capture.

This information will be stored in a number of locations.  The files themselves will be held on my Google Drive while some information will also be transferred into Chimni.  To exchange this information out of my information model into Chimni, COBie will be my method of choice.

Now through this process I am generating three kinds of container (files holding data): Graphical data (2D & 3D models), Non-graphical data (Schedules & COBie), and Documentation (Reports, & Drawings).  When I need to amended this information however it will almost be exclusively through the graphical data.  There are two main reasons for this:

1. Most of my non-graphical data & documentation are originated from my graphical model; and
2. Documentation are created in a locked format (such as PDF) making their management difficult, while non-graphical data are either used as reference (such as Schedules), or for the transfer of information between applications (COBie).

Note:  There are many articles online that criticise COBie as a means to manage data; they have however misunderstood how COBie is meant to be used. COBie is the vehicle to transfer information either into a more user friendly format (everyone knows excel), or into another application where it can be managed effectively.  While you COULD use COBie to manage your data, it is just as fit for purpose as a BMX is for competing the in the Tour de France.

What’s Missing?

So what attribute data am I missing?  Well, what attribute data did I ask for?  Looking back at my Data Requirements and what is written in my Employer’s Information Requirements (EIR) I asked for sufficient attribute data to comply with BS1192-4 (COBie), and a number of additional properties to suit my model purposes.  So let’s see what we have already successfully managed to capture.

Note:  I could have fixed a number of these issues before this weeks post, but I chose to highlight the current gap as opposed to present a ‘Blue Peter’ solution.

Contact

Nativity there isn’t sufficient support within Revit for ‘Contacts’.  Therefore not much of information I require is being exchanged.  Currently the following fields require attention:

Category: remains as ‘n/a’;
Phone: remains as ‘n/a’;
OrganizationCode: remains as ‘n/a’; and
Street, PostalBox, Town, StateRegion, PostalCode, and Country: remains as ‘n/a’.

From a contact point of view I need to investigate the best way to manage this information either through a plug-in, or through an external database. – Score: 10/19 = 52%

Note: It is worth noting that the COBie extension for Revit is able to capture this contact information, but is not being used due to my desire to follow a more open approach.

Facility

By completing the ‘Project Information’ settings within Revit & the IFC exporter plug-in, the majority of information I require is being exchanged.  Currently the following fields require attention:

SiteName: Cannot rename the Site system family in Revit to comply with BS8541-1;
CurrencyUnit: remains as ‘n/a’;
AreaMeasurements: remains as ‘n/a’;
Description: defaults to ‘BuildingName’;
ProjectDescription: defaults to ‘ProjectName’; and
SiteDescription: defaults to ‘SiteName’.

From a facility points of view I need to investigate why the description fields are defaulting to the ‘___Name’ properties, and look into a plug-in that’ll allow me to rename system families, as well as how to capture the house’s EPC value – Score: 16/22 = 68%

Floor

By completing the properties associated to my ‘Levels’ within Revit, the majority of information I require is being exchanged.  Currently the following fields require attention.

Height:  remains as ‘n/a’.

From a floor point of view I need to investigate what is the best property to include to exchange floor height information.  – Score:  9/10 = 90%

Space

By completing the properties associated to ‘Rooms’ (or Spaces) within Revit, almost all of information I require is being exchanged.  Currently no fields require attention, but I do need to map an occupancy attribute to each space. – Score: 13/13 = 100%

Zone

Within my architectural model I cannot attribute ‘Rooms’ to zones; but I can with spaces. So within my mechanical model I did just that and all of the information I require has been exchanged.  – Score: 13/13 = 100%

CORRECTION: I had stated in the original post that the way xBIM had represented the data is incorrect however I have been informed that both single row and multiple row methods are accepted (Thank you Nick Nisbet for letting me know!).

Type

I have already done a lot of work formatting my object types in previous posts, so thankfully all of information I require is being exchanged. Currently no fields require attention, but I do need to populate this data into most of my objects. – Score: 35/35 = 100%

Component

I have also already done a lot of work formatting my components in previous posts, so thankfully almost all of information I require is being exchanged.  Currently no fields require attention, however the description issue is persisting. – Score: 17/17 = 100%

System

While I do have a number of systems within my house, Revit will only export systems if it forms a closed loop (ie pipework between my radiators).  As I cannot access beneath the floor I have opted not to model on conjecture and have excluded my pipework, as such no systems will be included unless I can find a way to resolve this. – Score: 9/9 = 100%

Assembly

We have also already done a lot of work formatting my assemblies in previous posts, so thankfully almost all of information I require is being exchanged.  Currently no fields require attention, but I do need to capture a few additional assemblies such as my kitchen cabinets & worktops. – Score: 11/11 = 100%

Connection & Issue

Connection & Issue are an optional tabs (so I’ve efficiently sidestepped them) mostly due to the fact that may of the connecting elements (such as pipework) are hidden from view and thus not being modelled.  Also from an issue point of view the products have already been selected so theses will not be recorded either. – Score: n/a

Spare, Resource, Job, & Impact

These tabs are not related to additional data attributed to my objects but to the operation of those objects, for example my Boiler documentation will recommend maintence (Job) that need to be undertaken and by whom (Resource).  If I inputted this information onto my objects directly they would appear in the attribute tab, there I will need to investigate a way to manage this information through an external database. – Score: n/a

Document

Similar to the tabs referenced above, Revit is not capable at collecting information about related documents.  I do have a number of documents I want to capture (such as my property condition report) so I will need to find a way to manage this data through an external database too. – Score: n/a

Attribute

Thankfully almost all of information I required around my attributes is being exchanged including the additional attributes I have requested when I outlined my Data Requirements. Currently the following fields require attention:

Unit: remains as ‘n/a’; and
AllowedValues: remains as ‘n/a’.

However due to Revit‘s lack of enumerated value (pick list) support, and poor support of attribute units. – Score: 11/13 = 84%

Coordinate

Finally, there appear to be no issues relating to coordinate information as all the information I require is being exchanged.  Currently no fields require attention however further rigour may be needed as this tab is more difficult to validate. – Score: 15/15 = 100%

So, after considering the attributes I require I am currently exporting 146 of the 164 attributes (including the optional attributes) to comply with BS1192-4, in addition to a number of additional attributes I want to satisfy my data requirements.  If I populate all of my objects following my currently methodology that results in an average compliance score of 89%.  Had my COBie gone to university this would equate to a first!

Fantastic, this exercise has helped show where I need to focus my efforts while I also ensure that the right data as been populated into my objects. PLQ2.5 has been successfully scoped out!

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 where the issues lie, it’s time to explore how to resolve outstanding attributes as well as the best way to manage contact & document information which cannot be recorded within my graphical model. Perhaps I need some kind of external database…