Naming Omnibus

Hello BIMfans,
While developing my information model ‘naming’ has easily been given the most pause for thought.  While I have already discussed some naming conventions in previous posts, I have decided to put everything here.  The rule is simple, I will only use a naming convention if it can be found in a British, European (#Remain), or International Standard.

NOTE:  If I have missed out any naming conventions, feel free to leave a comment and I will add it to the post and credit you as thanks!

NOTE:  To save repeating myself, any fields with an asterisk* are optional fields.

Naming
Fun fact:  BIM is worth eight points in Scrabble.

So, let’s see what naming conventions I have found.  For ease of reading, I have grouped the naming conventions under their corresponding standards.

BS EN ISO 4157-1

The naming of almost everything represented physically can be found within ISO 4157-1, which defines how to name:  General designation codes, buildings, storeys, parts of storeys, floors, and load-bearing structural elements.

 

1vajbl
…using ISO 4157-1

 

The naming (referred to as designation in this standard) of Types and Components can be found within ISO 4157-1, it requires a primary and additional designator which I have used as follows:

  • Type:  <IfcType><Numerals in running order> e.g. DoorType01
  • Component: <IfcSubtype><numerals in running order> e.g Door01

This naming convention has already been applied to parts of my information model like my Door and Window Schedule Drawing which I produced when I discussed my Outstanding Openings.  However, further development work is needed to reflect this information correctly within COBie. This is because the USA’s National BIM Standard states that Component.Name should be consistent with the name that appears my schedules.  Meaning that each door in COBie should be named Door01, Door02… to suit what appears in my Door Schedule.

DoorSchedule

The naming (referred to as designation in this standard) of Floors can also be found within ISO 4157-1, which is simply a running number.

This (surprisingly) aligns well with the BS 1192 naming convention with specifies a two-digit sequential number for floor levels.  Therefore, I have changed the floor names in each of my models from Level 0, Level 1, and Level 2 to 00, 01, and 02 respectively.

Elevations.JPG

BS EN ISO 4157-2

The naming (referred to as designation in this standard) of Rooms can be found within ISO 4157-2, which is as follows:

Rooms:  <Floor Number><Numerals in running order> e.g. 101

This has already been applied to my information model and can be seen in both my graphical model and in my COBie files.  Easy.

cobie-spaces

 BS 1192

The naming of almost everything represented digitally can be found within BS 1192, which defines how to name: Directories and Folders, Files, and Containers within Files.

The naming of Directories and Folders can be found within BS 1192, which is as follows:

Directory and Folders:  <Project>-<Status*>-<Revision*> e.g 7001-CR-C01

This naming convention has already been applied to my directory within Autodesk’s A360 which I use to host the graphical models I share on this blog.  However, as I am not operating a full project it’s implementation here is limited.  Note:  It does allow sub-directories with names based on the file naming convention discussed below.  However, I consider this a waste of time.  Why have a folder called ‘Models’ or ‘Architect’ when it is written in the file name?

Folders
Hint:  Optional really* means don’t bother using it…

The naming of Files (Probably the second most contentious naming convention behind Boaty McBoatface) can also be found within BS 1192, which is as follows:

Files:  <Project>-<Origin>-<Volume>-<Level>-<FileType>-<Role>-<Class*>-<Number>

This naming convention has already been applied to several files that I have been sharing over this blog via Autodesk’s A360.   You’ll notice that as BS 1192 specifies file types meaning that my native files use ‘M3’ and my IFC files use ‘MR’.

Models

The naming of Containers within Files can also be found within BS 1192, which is as follows:

Containers within Files:  <Role>-<Class>-<Presentation>_<Description*>

This naming convention has already been applied to most of my views and some symbols within my graphical models.  However, I haven’t yet finished renaming my symbols or configured my layer export setting to comply.

SymbolsViews.png
Yes, that is exactly what my North Point needed; Uniclass2015!

BS 8541-1

The naming of Objects can be found within BS 8541-1, which is as follows:

Objects:  <Source>_<Type>_<Subtype>

This naming convention has already been applied to my objects when I first considered Object Naming and has been applied to objects such as my Nest Thermostat, and Google Home.  Now there are several opinions on how this naming needs to be implemented, I have taken the stance that it is for the naming of the object file (i.e. what you find when you search your computer), because type and component naming is covered in ISO 4157-1.

DoorNaming

BS 8541-4

The naming of properties can be found within BS 8541-4, which requires the use of CamelCase (just like Hashtag writing #CamelCaseMakesItEasierToRead) and an indication of the data type expected.  For example, if you take a look at the properties I have used from my previous post on Classical Conditioning three properties were being focused on:

Pset_Condition
AssessmentDate, when the assessment was completed YYYY-MM-DD;
AssessmentDescription, qualiative description of the assessment; and
AssessmentCondition, the condition:  Very Poor, Poor, Adequate, Good, or AsNew.

By suffixing Assessment with ‘Date’, ‘Description’, or ‘Condition’, it suggests the data type that should be expected to populate each property.  Luckily for me, all the properties I have used are available in the IFC Schema.  However, if I ever found I was lacking, this convention is how I would create those additional properties.

BS EN ISO 3098-0

The naming (referred to as designation in this standard) of text styles can be found within ISO 3098-0, which is as follows:

Text Styles:  “LetteringISO3098” – <Type>-<Spacing><Incline><Alphabet>-<Size>

This text style naming convention has now been applied to my graphical models. However, due to Revit’s vile terrible horrible improving text formatting capability, I have to include an additional field to indicate whether the text is bold, italic, or underlined as a suffix.

Text

BS EN ISO 128-20

The naming (referred to as designation in this standard) of line styles can be found within ISO 128-20, which is as follows:

Line styles:  “LineISO128-20” – <Type> x <Width> / <Colour*>

However, Revit annoyingly unfortunately doesn’t allow you to rename system line styles. While I could recreate all my lines styles following this convention, I do not consider this worthwhile.  If/when I need to create specific line styles, those user defined line styles will follow this naming convention.

Lines

BS EN ISO 5457

Finally, the naming (referred to as designation in this standard) of title blocks can be found ISO 5457, which is as follows:

Title blocks:  <Descr.>-<Standard>-<Size><Trimmed>-<Material>-<Side>-<Pattern*>

This has already been applied to my title blocks when I formed my original templates

Title Block.JPG

And there we have it.  By using a myriad of British, European, and International Standards, I have now laid out all of the naming conventions I am aware of and how they have been applied to the production of my information model.  This will help me align my information not only between models but also to the national and international communities; fantastic!

Operation and Maintenance
3.1 What are the sizes and condition of the windows & doors?
3.2 What assets are in a poor condition?
3.3 What costs can be attributed to my assets?
3.4 What are the most cost effective thermal improvements that could be undertaken?

Now that I have worked out all of my naming, I need to apply this so that I am ready to share my model to do some external cost exercises…

Update:  Component naming has been changed from IfcSubtype abbreviations to full text. Using abbreviations became impossible to apply globally because some types share the same first initial.

Update:  Following a Twitter Poll I have changed how my name my IFC files from M3 to MR.  Thank you, John Ford, for raising this question.

Advertisements

PLQ 3.3 – Understanding Uniclass 2015

Hello BIMfans,
Before I calculate the costs associated with my preventative maintenance schedule, I need to ensure each object is correctly classified.  So, let’s take a good look at Uniclass 2015.

A few weeks ago I had the pleasure of sitting down with Sarah Delaney, head of classification at NBS, to talk about Uniclass 2015.  It turns out that the way I have used classification on my doors isn’t exactly how it should be used, so I wanted to share with you why, and the changes I needed to make.

NOTE:  Sarah has written an article on Uniclass 2015 which was a big help in getting me to understand.

Classification:

Ok, a quick bit of context, what is a classification system?  Basically, it is a method of classifying or categorizing objects to differentiate between them.  Classification impacts everything, from the Tree of Life, and the age-old debate around Whether Jaffa Cakes are in fact Biscuits? (A debate based on avoiding VAT), to how we decide what parts of a design are the responsibility of which professionals.

tree-of-life_2000.jpg
Note:  I have no idea where Jaffa cakes sit on this diagram

In construction, there is an International standard for forming classification systems, ISO 12006-2 (you’d think I was on commission with ISO by the number of these standards I reference).  It suggests how classification tables should be broken up as well as their relationships to each other. Uniclass 2015 is the UK’s latest in a series of classification systems to be created aligned to this standard.  Now before any QS/Estimators kick-off comment, I will point out that the RICSNew Rules of Measurement (NRM) is NOT a classification system; more on that in a future blog post.

Uniclass 2015:

As explained by Sarah in her article, Uniclass 2015 consists of several tables which are based on the following number series:

Group Title
10 Preparatory*
15 Earthworks
20 Structural
25 Wall and barrier
30 Roof, floor, and paving
32 Damp-proofing, waterproofing and plaster finishing
35 Stair and ramp
37 Tunnel, shaft, vessel and tower
40 Signage, FF&E, and general finishings
45 Flora and fauna
50 Waste disposal
55 Piped supply
60 Heating, cooling, and refrigeration
65 Ventilation and air conditioning
70 Electrical
75 Communications, security, safety and protection
80 Transport
85 Process engineering
90 Circulation and storage

NOTE:  While under Products(Pr) preparatory work is covered under Pr_15; in Activities(Ac) however, it is under Ac_10. So, as 15 has been taken by Earthwork in Systems(Ss), I have opted to use 10.

So, where did I go wrong?  Put simply, I hadn’t fully understood the relationship between the tables.  Which is as follows:

  • Pr, Products:  Things you buy (Bricks, wall ties, and Mortar)
  • Ss, Systems: An element (or part of an element) made of products (Brickwork)
  • EF, Elements/functions:  Main building components (Walls and Doors)
  • SL, Spaces/locations:  Place where activities happen (Living Room and Kitchen)
  • Ac, Activities: Exercising, Sleeping, Eating, Working etc. (Cleaning and Cooking)
  • En, Entities:  Individual assets (Just the house)
  • Co, Complexes:  Group of Assets (House and Garden as ‘Ty Crempog’)

What I had done was incorrectly use the Systems(Ss) table when I should have used the Elements/function(EF) table for my doors.  Each of my doors were classified as Ss_25_30_20_25: Doorset systems, but this isn’t correct as they are not doorsets.  As such, I have now re-classified them as EF_25_30: Doors and windows.

To remind myself, I drew this diagram.

Classification.jpg
This feels like one of those Mensa questions.  If all Systems include products, and some elements include systems, are all Elements Systems?  Answers on a postcard!

Using classification:

For classification to work within Revit so that if exports into IFC, an object’s classification code and description need to be placed onto the defined property specified in the classification settings window; written as ‘Code: Description’ to comply with BS 1192-4 & COBie.  As you can see from the image below I have opted for the property ‘ClassificationForObjects’.  I chose this as it is the most appropriate field I could find within the IFC Schema as it is listed within IfcClassification.

ClassificationSettings
The default value is ‘ClassificationCode’, I was just being awkward changing it.  It also made using objects from a 3rd difficult as I would have to change its properties to exchange any classification information.

This information is then exported into the IFC file and passed through to COBie so that it is ready to be exchanged and used to manage my home.

COBie-Uniclass.JPG

And there we have it.  By using Uniclass 2015 in the way that it was intended to be used, I have now improved the quality of the information I have produced and are using to managed my home; fantastic!

Operation and Maintenance
3.1 What are the sizes and condition of the windows & doors?
3.2 What assets are in a poor condition?
3.3 What costs can be attributed to my assets?
3.4 What are the most cost effective thermal improvements that could be undertaken?

Now that I classified my objects correctly, I wonder how classification will relate to costing up my preventative maintanence schedule?…

Drawing to Conclusions

Hello BIMfans,
You will be happy to know that my graphical models are nearly ready to be delivered.  I have considered how to do Mindful Modeling, what to do about Objects within my model, and even had not one round, but two rounds of COBie consideration.  I thought I had considered everything I needed to.  However, I’ve realized that I haven’t really considered one of the most important deliverables; my drawings.

architect-plans-hard-copy-print
Yes, drawings are still needed when following the BIM process!

Now if I want to produce objects to create my graphical models, I have the BS8541 series; if I want to produce COBie I have BS1192-4, but if I want to produce drawings what support do I have?  In fact, a lot.

Drawing Sheet:

For this project I want to create a number of drawings consisting of Plans, Elevations, and Sections.  To be appropriate for my house (where I have no access to a large format plotter) I have opted to use A3.  Now A3 is a standardised size, defined in ISO 216 as 297x420mm. Ok, so I know how big my paper is; how big is my border?  Well there is a standard for that too.

ISO 5457 says that the drawings space for an A3 sheet is 277x390mm giving 10mm of clearance vertically, and 20mm horizontally on the left to allow for filing. It also states that drawing sheets should have centre lines, and a grid reference for identifying locations on the drawing, and trim markings in the corner; giving me a sheet that looks like this:

iso5457drawingsheet
I like the ‘A3’ the bottom corner to indicate size, but to be honest this sheet does feel a little over the top; no matter it’s in the ISO, so it goes on my sheet!

Title block:

Right, I have my drawing sheet, I just need a title block to go with it. Luckily for me, there is a standard for that as well. ISO 7200, specifies the mandatory fields required for a title block which are:

  • Legal owner
  • Identification number
  • Date of issue
  • Segment/sheet number
  • Title
  • Approval person
  • Creator
  • Document Type

In addition to these codes I want to include the following optional fields within ISO 7200: Revision Index, and Technical Reference as well as the BS1192 specific field Status Code and the project’s name.  So taking all of these fields and trying to put them together logically gives me a title block that looks like this:

titleblock
Where space permits I have included the attribute that controls each box.

Note:  To better align with the approval gate process in BS1192 I have changed Technical Reference to ‘Checked by’ and renamed Approval Person and Creator as ‘Approved by’ and  ‘Drawn by’ respectively.

Now that I have a ISO 7200 title block, I can use this on all my drawings as well as my Employer’s Information Requirements, BIM Execution Plan, and model splash pages to consistently convey information about them all.

Symbols:

I also need to select the proper symbols and annotations, luckily for me there is even a standard for that too.  BS8541-2 includes standard symbols, annotations, hatch patterns, and even specifies what my North Point should look like. Using this standard I can ensure that I convey my information in a nationally consistent manner.

northarrows
If there is one thing that every designer likes to do, it is to design their own North Point.  Why when we have a national standard that provides one?

Font

Finally, no annotations are complete without a good font.  Now when I first released this post I hadn’t considered a font and had just used Ariel (#Mainsteam) but through closer inspection of the standards came across ISO3098 Series and the compliant ISOCP fonts. These have now been used to annotate my drawings.

quickbimfox

Now that I have put all of these standards together, I am able to complete by drawing properly, here are two I have completed below:

NOTE:  All of these international standards are conveniently summed up in a single British Standard, BS8888.  Thank you to John Ford for pointing me towards it!

And there we have it, by thinking about how I am going to produce my drawing deliverables I have been able to apply a number of international and national standards to produce a standard drawing sheet, title block as well as use standard symbols on my drawings.  A big help towards the completion of 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 for producing each deliverable in place, It’s about time I shared them with you…

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.

bepmushroom
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:

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

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.

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

ojbecttypenaming
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:

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

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

kitchenmeasure

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

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

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

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

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

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

typeselect_new
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…

PLQ2.5 – Bridging the Attribute Gap

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.

data-bridge
By defining my data deficit, it’ll allow me to focus on building the right data to bridge this gap

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.

data-total
This process has helped keep my data muscular and compact, like corned beef.

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.

bmx-tourdefrance
I’m winning!

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%

descriptionissue
Why description; whyyyyyyyy?

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!

cobie-graduation
*Sob* They grow up so fast!

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…

 

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.

PLQ2.3 – Object Naming (cont.) & House Layout

Hello BIMfans,
After starting to author my Architectural graphical model last week.  This week I have continued its development resulting in a model which while work in progress is starting to really come together!

3D
As with last week, you can access this model here through Autodesk’s A360 portal.

I was very happy to see that after last week’s blog, a lively debate started on LinkedIn around object naming; as I also had some questions of my own.  As you might have saw last week, when I named my walls I did not put the thickness of layers into my subtype. so for example a wall might have been called:

BBH_SolidWall_PlasterBrickwork

I did this because within BS8541-1, table 1 states that the subtype should not capture attribute data.  However, while authoring my model I quickly needed to distinguish between walls with the same build up but different thicknesses.  Unfortunately,  Revit doesn’t allow duplicate family names I couldn’t use ‘BBH_SolidWall_PlasterBrickwork’ for walls with the same layers at different thicknesses, so a solution was required.

BBH_SolidWall_PlasterSingleSkinBrickwork

Initially I described the number of brick skins to avoid recording attribute data within the name, but quickly realised that that was stupid, and I was describing the thickness of the wall, just in a very awkward way.  So I was led back to using the thickness of each layer within the subtype.

BBH_SolidWall_15Plaster225Brickwork

Now to make sure my reasoning was sound, I decided to ask Twitter.  Interestingly (but not very helpful) the majority of people who participated in my poll thought that both options were wrong.

VoteTweet
In fact the correct answer is that ‘both’ are correct.  As the wall does not have a predefined subtype, anything goes so long as it has no attribute data, and uses no special characters other than an underscore ( _ ).

To make matters worse, I added some new objects to my model this week that had to use BS8541-1‘s other naming convention for unclassified objects.  Basically, if you are using an object without a classification field then the unclassified object naming convention is required, which is a tad more complex:

BS8541NamingUnclassified
To use this convention I did what all great men do in times of strife.  Ignore the optional fields, in this case it is ‘presentation’.  Also why is BS8541-1 now telling me to use hyphens(-) instead of underscores( _ ) between each field in the example object?…

To make sure that I complied with the original Employer’s Information Requirements and my BIM Execution Plan, I needed to use this naming convention for the following objects:

  • Kitchen worktops;
  • Bespoke window sills; and
  • Top of small units which also acts as a shelf.

This meant I needed to find out some extra information.  We already have my role, in this instance it is Architectural, classification means we need to rely on a Uniclass 2015 table (see example below), we have skillfully skipped presentation, source is my organisation (BBH) as the object creator, type relates to the corresponding IFC type, and subtype will allow me to differentiate between any other similar objects.

UniclassWorktop
Uniclasss 2015:  Those underscores will look great inside my kitchen worktop family name…

Meaning that I named my kitchen worktop like this:

A-Pr_40_50_21_45-BBH-Worksurface-Kitchen

Note:  Because of the underscore ( _ ) within the classification codes I have used a hyphen (-) as a field separator which doesn’t comply with the text but does comply with the example provided within BS8541-1.  This inconsistency isn’t very helpful, so I have chosen a solution that suits my situation best.

Objects such as kitchen worktops and shelves have been added for a reason.  Each of these were needed to accurately reproduce my floor layout, as required to satisfy my next Plain Language Question “What is the Layout of my house?”.  So now that they have been modelled, the result is a set of floor plans built into a graphical model that’ll be used for its own purposes as well as capturing what assets I have in order to answer my next Plain Language Question.  Once completed I was able to set up suitable views of my floor plans, and transfer them to a title block to complete this deliverable.

Plans
The full size .pdf plans can be accessed here.

And there you have it, after putting in the objects I needed I have now been able to produce a drawing containing my ground and first floor plans which has been derived directly from my graphical model.  Using this information I now know the layout of my house; therefore Plain Language Question PLQ2.3 is complete!

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 pretty strong Architectural model, it’s time to start creating some of my other models to record the electrical and mechanical objects

Note:  If you have any comments or opinions regarding the Layout of my House, please let me know either on twitter, or commenting below.

PLQ2.3 – 3D Modelling & Object Naming

Hello BIMfans,
After undertaking a traditional survey of my home last week, this week I have finally opened up a piece of 3D software and started to do some modelling!

First thing’s first; what do I need to actually produce?  Well, after reviewing my Master Information Delivery Plan (MIDP), and the responsibility matrix within my BIM Execution Plan (BEP), I need to produce an Architectural Model which includes:  External walls, internal walls, door, windows, roof, floors, fascia, gutting and anything else associated with the external structure or internal layout.  So to do this I need some objects, but it isn’t as simple as that..

First, I need to either find the right objects, or build them myself.  Now this week I have managed to build my own (so I won’t discuss online object libraries this week) but once I had built my objects I found that picking their names was a challenge!

Choosing_Baby_Name_Parent
Few people have ever had to name a wall!

Now luckily for me to make sure that good consistent naming was used I specified within my Employer’s Information Requirements (EIR) that BS8541-1 should be complied with; the British Standard for object identification.  Within this standard it states that objects using the software’s associated classification (Like when you use a Wall object to represent a Walls) should use three fields.

BS8541-Naming

Source:
Source is easy, I made these objects so I have used the the same organisation code I used in my EIR & BEP; BBH (BIMblog.house).  However if they are downloaded from another source, then they should be identified as the source.

Type:
Type are also fairly easy as BS8541-1 suggests the use of the corresponding IfcType which can also be found on the IFC Schema page.

Subtype:
Subtype has little guidance but states that this information should not captured within the attribute data, so with that limitation I have used this field to describe the structure of my objects. For example, a partition wall object has the subtype ‘PlasterStudPlaster’, so describe the layers used within.

Note:  All fields need to use CamelCase (no spaces) and special characters are not permitted either!

Annoyingly many of the standard objects within the software package I was using (Revit) didn’t strictly comply as hyphens ‘-‘ are only permitted in objects without associated classifications.  So, after creating a number of my own objects, I ended up with a list like this:

WallNaming
Note the BS8541-1 non-compliant default families that I couldn’t purge at the bottom of the list.

Now that I have a consistent naming method, it’ll be easier to identify these objects when they appear in schedules and eventually within my COBie export.  So, to the modelling!

Those of you who follow me on Twitter, may have seen my frustration at modelling my home last night.  As my home is a 1900s Victorian Terrace, it isn’t exactly built perfectly straight.  In fact, when I tried to use a photograph to check my dimensions by course counting I discovered something very interesting; my courses don’t add up!

BrickCourses
What kind of unholy monster would do this???

So sticking to my internal dimensions, and modifying some of my wall thickness to take into account imperial brick dimensions, I have started to create my graphical model. Currently Work in Progress, this model currently includes:

  • Generic floor objects with a depth based on my landing void;
  • Wall objects based on my survey measurements, and has started to be populated with bathstone detailing and render on the rear facade; and
  • Generic roof objects based on pure conjecture (to be revised!)
HouseCapture
You can access a copy of this Work in Progress 3D Model here to interact with through Autodesk’s A360 portal.

There you have it, after some frustration trying to make my measurements add up, this model is now starting to look like my home.  However, this model isn’t complete by a long shot, so I hopefully by next week it’ll have sufficient content so that I can answer my current Plain Language Question, PLQ2.3.

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 this model, it’s time to add some further objects, to answer PLQ2.3…

 

PLQ1.4 – Standards

Hello BIMfans,
Now that I have established what my Data Requirements and Information Formats are, I now need to consider what Standards I want followed to make sure that the information I receive is right, complete, and structured correctly.

It is worth saying at the start of this post that (as a member of British, European and International Standards committees) I am a strong believer in adopting a standardized approach.  However, often when we are working we deal with Standards, instead of a Standard.

Toothbrush
Standards are like toothbrushes, everyone would rather use their own.

At BRE, I often audit for our BIM Business System Certification scheme. When auditing, I find it amazing how often I see phrases such as “BS 1192 amended/revised/inspired” when referring to naming conventions.  What also makes matters worse is when standards are developed often they are not considered holistically and as a result conflict with each other.

standards
If XKCD‘s Randall got a pound every time I tweeted this, he’d be slightly richer than he is now

As this blog is looking at promoting good practice, I will aim to follow existing standards where possible as opposed to producing my own.  On the Official BIM Level 2 Webiste, there are six ‘core’ standards identified which I will be following which are:

  • BS 1192; guidance on how to produce information using a standard file naming, revision, and suitability code convention, as well as exchanging information within a common data environment.  Note:  As I am a team of one I will not be following the common data environment exchange requirements.
  • PAS 1192-3; guidance on the relationship between the Employer’s Information Requirements (EIR) and other core documents from the organization and asset teams, as well as a definition for content included within an asset information model, and guidance on managing the asset information model throughout the asset’s life cycle.
  • BS 1192-4; guidance on how to structure an information exchange to COBieincluding how data should be presented, what the expected attributes are, and where to locate recommended type and system attributes.  Note: I will producing COBie compliant content.
  • PAS 1192-5; guidance on how to define the sensitivity of an asset as well as how to safeguard its information.  Note:  While my asset is not defined as ‘sensitive’, I will be requiring safeguards to prevent the release of any personally identifiable information on regarding the location of my home.
  • BS 8536-1 / BS 8536-2; guidance on forming Plain Language Questions, additional owner and operator information requirements, key employer activities at each project stage, and guidance on post-occupancy evaluation.

Those of you who have been paying attention will have noticed that most (if not all) of these standards have already been referred to in previous posts.  These six documents make up the ‘core’ set of BIM Level 2 standards, but they are not enough to manage a project, so I intend to refer to some additional Standards which will be outlined in future posts.

These Standards (as well as many, many others) will be used to structure my information as well as the key documentation that define relevant standards, methods, and procedures that well used to undertake the production of my information model.

And there you have it.  I have defined the standards that I intend to have followed.  This means that I have now answered another Plain Language Question; PLQ1.4 Complete!

Brief:
1.1 Have the model purposes been defined?
1.2 Are there any specific data requirements to achieve these purposes?
1.3 What format shall the information be delivered in?
1.4 What standards will be followed?
1.5 What level of accuracy/detail/development is required?
1.6 Is there sufficient information to produce an EIR?

Now that I know what standards to follow.  I need to now establish what Level of Definition is required for my information to satisfy PLQ1.5…

Note:  If you have any comments regarding my choice of Standards, then please let me know either on Twitter, or by commenting below.