Category: Standards, Methods and Procedures

Structured Safety

Dan6 Comments

Hello BIMfans,
With the recent release of PAS 1192-6, the newest core BIM Level 2 publication, there is now a specified process on how to share structured health and safety information.  So, let’s try it out and see if we can deliver this information!

EIR Invocation:

First things first (ironically), If an Employer wants the project’s health and safety information structured as specified with PAS 1192-6, then they will need to say so in their Employer’s Information Requirements.  So, as PAS 1192-6 is now specified in my EIR, I guess I’ll have to follow it.

(open) BIM Usage:

According to PAS 1192-6, 4.3 because I am modelling Tŷ Crempog using BIM processes, clauses 9 (COBie) and 10 (IFC2X3) apply.

From reading this PAS, it is clear that health and safety knows no vendor.  To comply, information shall be shared in open standard structured formats.  Meaning that thanks to PAS 1192-6, IFC2X3 is now a normative BIM Level 2 requirement (Woohoo!).  Thankfully this doesn’t impact on the most important BIM file format…

LoveExcel
Loving you is easy ’cause you’re…controlled by ISO/IEC 29500

Clause 10 (IFC):

As only maintainable objects should be captured in COBie, there needs to be a method of capturing risks about other objects; this is where PAS 1192-6, 10 comes in.  It specifies that all health and safety information being shared shall be captured using HS_Risk_UK, a new property set specified within PAS 1192-6, Appendix A.  Note:  During the final edit, the first column of this table was incorrectly given spaces.  To comply with BS 8541-4, the properties should be written in CamelCase.

Once corrected, I added this property set into my PSet Definition Text File and created Revit shared parameters to match.  Thanks to the changes to my IFC Export Process, my Electrical IFC File now captures this information and places it into the correct property set.

 

 

ifcRisk
The ease of adding this information was a shocking revelation

 

Risks can also be non-object related. When this is the case, PAS 1192-6 says that annotation entities (a.k.a floating risk signs), should be used.  To know what these entities should look like, PAS 1192-6, 4.3.3 states that BS ISO 3864-3 should be used.  Note:  This isn’t correct, as BS ISO 3864-3 tells you to use the symbols within BS EN ISO 7010.  Unfortunately, beyond this, PAS 1192-6 provides no further guidance.

This presents a problem.  With only the example being a screenshot in the appendix; I’ve had to go it alone and have produced what I feel is a pragmatic solution.

HazardMix
They say every sign has a story; this looks more like a hare-brained scheme

Shown above is my Master Warning Annotation Entity which has been produced to include all* warnings as separate types (*Only electrical and fall warnings have been added so far).  I have made this entity 700x700mm, 10 times the sign size outlined in BS EN ISO 7010), with a 7mm simplified symbol that displays on drawing plans.  Note:  The symbol is simplified because Revit can’t do lines small than 0.8mm, stupid Revit.

Also, due to the lack details on how to produce annotation entities, I also used the following additional sources to help:

  • BS 1192.  My annotation entity is named ‘Z-PM_80_60_70-M_WarningSymbol‘ to comply with BS 1192.  Note:  You might have thought that I’d use BS 8541-1. However, this isn’t an object, it’s a symbol. BS 1192 covers the naming of containers with files (i.e. symbols).
  • BS EN ISO 7010.  I extracted the symbols I needed and recreated them using several solid extrusions.  For the sign colour, I used online tools to get the RGB code (243 200 30) and set it to 20% transparency so that the object wouldn’t be opaque.
  • Uniclass 2015. Finally, I wanted to give this object a Uniclass 2015 classification.  After some thought I settled on ‘PM_80_60_70: Residual risk information’ as the while the nature of the risk might change, at least all of these objects would be grouped under the same classification.

I might be a little bias, but I think my annotation entity looks quite fancy in my Electrical Native Model File.  Note:  The rabbit silhouette is technically not BS EN ISO 7010 compliant.

RiskSign.png
Now for the real question, will Crempog check the information model before he tries to chew my cables?

COBie:

COBie, unfortunately, took a lot more effort.

While I had managed to export this information into IFC, after testing xBIMXplorer, the COBie Extension for Revit and BIMserver (Thank you Emma), I couldn’t get the issue sheet to populate.  This was because PAS 1192-6 introduced HS_Risk_UK and with it a new method of structuring risks.  Existing COBie export tools haven’t yet reacted to this new process.  Currently, COBie looks for approvals to populate its issue sheet, but it is now having to look for objects.  Note:  While PAS 1192-6 appears to go against IFC2X3, the authors have confirmed that HS_Risk_UK is a draft proposal for updating Pset_Risk so feedback on this process will be used to update the IFC Schema.

Luckily I had a plan.  As I know the members of xBIM Development Team, I could ask them to patch the exporter to comply with PAS 1192-6.  Looking at xBIM’s GitHub, I identified the problem and proposed a rough solution for them to test and implement.  After a few emails, some black magic and only a couple of hours, we had managed to successfully export COBie with the issue sheet being populated as intended.  Note:  To get the validation to work, I’ve had to expand my picklist further to capture the new enumerations.

Note:  This patch is now live, anyone using xBIMXplorer can now benefit from the fantastic work that the xBIM Development Team have done.  

Those of you who have been following this blog will know that xBIMXplorer is my go-to IFC/COBie tool.  While it isn’t perfect, it’s free, open-source and as I’ve shown in this post, able to quickly respond to user needs.  I highly recommend you try it for yourselves.

If however, you want to comply with PAS 1192-6 but don’t want to build xBIMXplorer, there is another way.  After I asked for help on Twitter,  Nick Nisbet of AEC3 volunteered his help and also managed to use the same IFC files to automate the export of PAS 1192-6 compliant information using AEC3 BimServices 2018.  If you need a bit of COBie support, I’m certain that Nick can help.

And there we have it.  Less than a week after PAS 1192-6 was released, the processes have been tested and successfully demonstrated.  I managed to test HS_Risk_UK myself and thanks to Nick Nisbet and the xBIM Development Team, we have shown that automated COBie population of the issue sheet is possible using more than one method; fantastic!

Note:  If you have any comments regarding my structured health and safety information or PAS 1192-6, then please let me know either on Twitter, or by commenting below.

Update:  The HS_Risk_UK property set was missing three properties (AssociatedProduct, AssociatedActivity and AssociatedSpace).  This was done intentionally to be automated during export into COBie, but my method is incorrect as they are mandatory fields.  They have now been included in the Pset Definition file, screenshot and downloadable files.  Thank you, Nick Nisbet.

PLQ 3.3 – COBie Culmination

Dan1 Comment

Hello BIMfans,
Those of you who have been following this Blog will know that producing good COBie has been a persistent goal of mine.  This goal may sound simple, but it wasn’t.  Due to the current state of software, the delivery of well-structured information isn’t a one-click activity (one day we’ll have that magic COBie button…one day).  When producing information to manage my home, I have been careful to ensure that the properties and attributes I’ve used have been structured to suit the available British, European and International Standards which are:

Because of my allegiance to the Standards, I’m confident in the quality of my work.  However, I can’t be sure.  Most methods of producing COBie do not incorporate verification, a method of testing that the information has been formatted correctly.  Meaning that while it might save like COBie, and look like COBie, it isn’t necessarily COBie.  My process of using an IFC rendition to produce COBie through xBIM has this problem.  Thankfully, a follower came to the rescue; John Ford.

JohnFord
Look at this BIM model!

John is the senior business information development manager at Carillion Plc.  If the name seems familiar, it’s because he is quite active on Twitter and is one of the most active participants in the LinkedIn COBie forum.  One of  John‘s many key roles is the validation of COBie using Carillion‘s preferred COBie quality control plugin, the COBie QC Reporter.  John contacted me and kindly offered to verify my COBie (I think I nearly bit his hand off!).

Note:  Anyone (I mean anyone) is free to take files off this blog and use them for whatever purpose they like; they are on creative comms for a reason.  Please play with these files and let me know how to improve them.

John provided a series of reports created by the COBie QC Reporter, filled with useful information that tabulated the findings from each sheet, like the one shown below.  Reading these reports I discovered that my COBie had failed!

COBieReport

Full disclosure, I knew they would fail.

Back when I looked at my Data Security, I opted to use ‘redacted’ as my email address.  Because of this, I was producing an error each time my email address should have appeared.  However,  John also found a few other errors that I wasn’t expecting.

  • Email address.  I was also getting a second email related error.  The other was that I incorrectly used ‘n/a’ when I didn’t know the warranty guarantors of my components.  To resolve both of these used ‘redacted@bimblog.house’ and ‘unknown@bimblog.house’ respectively.
  • Model Number.  I didn’t realise that model number had to be a value other than ‘n/a’.  Because my home has a lot of missing information, I don’t know the model number for most components.  To resolve this I used ‘unknown’ instead.
  • Warranty Start date.  No components in my architecutal model had a warranty start date (ooops!). To resolve this I added the attribute as required.
  • Duplicate Types.   After exporting, duplicate types were appearing.  On investigation it turned out to be an issue with Revit and the way it handles instances.  Types were duplicated if their default height or their orientation had changed.  I have been in contact with Autodesk who have recognised the issue and are looking into it.
  • xBIM.  Due to my use of Revit to IFC to xBIM, some of the default cells were not being completed such as Attribute.Unit, Attribute.AllowedValues and Space.Floor.  In addition, some components would appear without their type, and vise-versa.  To resolve these I modified the information in post (shown in red).  I will be raising these issues with xBIM in the new year.
  • Assemblies.  My assemblies were not exporting as expected; causing validation issues.  To resolved this, I omitted them from the report.
  • Picklist.  To date I had been lazy and hadn’t written my own picklist.  As such it was causing some validation issues.  To resolve this I just sat down and wrote the damn thing.

Once I had resolved these issues,  John kindly re-verified my COBie through the COBie QC Reporter and found zero errors; woohoo!!  As you can imagine I was pretty chuffed and had to tweet about it:

You can access my validate COBie here:

I wasn’t the only one who was impressed; John was quite impressed too.  In fact, he was so impressed that he left this kind testimonial:

Testimonial_JohnFord.png

Note:  Other testimonials for this blog can be found here.

And there was have it.  Throughout my professional career, I have always valued third-party validation.  It’s one thing to say it, it’s another to have someone else prove it.  Thanks to the kind help of John, we’ve managed to prove that my COBie not only walks the walk; but also talks the talk; fantastic.

As you can see, it has taken a lot of effort to ensure that the information I have produced is correct, and this has only been for a small Victorian mid-terrace. My effort would pale in comparison to the effort needed to deliver COBie for a multi-million-pound central government BIM Level 2 project using today’s software.  If we expect ‘proper’ projects to do the same, the methods we use to produce COBie needs to improve.

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 perfected my COBie, it’s time to find an asset management system to export this information into…

Note:  If you have any comments regarding my COBie and the validation process, then please let me know either on Twitter, or by commenting below.

PLQ 3.3 – Summer Sort Out

Dan2 Comments

Hello BIMfans,
For those of you who know me outside of this blog, you’ll know that I have been quite busy over the last few months getting married, presenting to key stakeholders, and doing some pretty exciting standards work (#HumbleBrag).  As such, I haven’t given my information model the attention it deserves.  So before I get my cost my preventative maintenance schedule I decided to roll up digital sleeves and have a summer sort out.

 

spring-cleaning-your-website
No, I don’t want no scrub! My model only needed a little TLC

So, what do I want to sort out?  Well as you know, there are three parts to an information model.  The graphical model and its associated renditions (i.e. exports like my IFC files), non-graphical information, and the PDF immutable documentation.

CDE-IM

So, let’s see if these previous posts will help me improve any of these parts.

Graphical Models

Electrical Model

Following a previous post where I created a Google Home object, the electrical model has been updated to include it.  In addition, I have also been tweaking each of my graphical models to remove several z-fighting issues (trust me, this is nowhere near as cool as it sounds) to improve how my models export into a VR environment.

Architectural Model

Also, around my kitchen, I have updated the materials, altered the component names (see below) to remove a duplicate type name.  I have also worked out how to get my sink to cut through the work surface and cabinet correctly (this drove me mad, I ended up having to cut a hole in my worktop to sort it).  This brings my kitchen much closer to what has physically been built.  Note:  In a future post, I will contact Howdens and find out exactly what components were used.

Kitchen.png

Model Naming

In addition to revising my graphical models, I have also changed how I name my models.  Previously, you may have seen on this blog IFC files with the file type ‘M3’ for 3D models. After John Ford asked the question, I agreed that ‘M3’ wasn’t the most suitable and felt that it should be ‘MR’, for model rendition.  So, as always, when in doubt I turn to Twitter.

As you can see ‘MR’ was voted the most popular (phew).  This makes sense because I use my IFC files to create COBie, not instead of COBie.  If I was delivering these files back to a client I’d have used ‘IE’ (information exchange).  However, as they are effectively filtered renditions of my native model, ‘MR’ is most appropriate.

 

Non-graphical Information

Thanks to my previous blog posts I’ve managed to update several areas within my non-graphical information.

Component.Name

Following a post where I collected Naming Conventions, I have now updated the component names to suit.  The convention I have chosen to follow is:

  • Type.Name:  <IfcType>Typenn e.g. WindowType01
  • Component.Name: <<IfcTypeEnum>>nn* e.g. Thermostat01

The exception to this rule is when the IfcTypeEnum does not suggest what the component is my itself.  For example, only a few people (except losers like me!) would know that ‘Water01’ is a boiler or that a ‘UnitaryControlElement’ is a Thermostat.  When these instances occur, I use <IfcType>nn instead giving me ‘Boiler01’ and ‘Thermostat01’ respectively.  Note: This also allows me to be pedantic and refer to my radiators as convectors, so win-win!

Type.ExpectedLife

Following a previous post where I calculated the Return on Investment of producing my information model, I have now incorporated each component’s expected life.  The service life of these components will be very useful when calculating my maintenance budget.

Type.ReplacementCost

Also in preparation for this maintenance budget, I have added (for objects I could google…) relevant replacement costs.  This was effectively done by comparing my existing components with their B&Q or Wickes equivalents, leaving those I couldn’t find as ‘n/a’.  Despite a few omissions, these costs will help calculate my maintenance budget and have helped fill my COBie files with even more information.

COBieCosts

Documentation

View References

Finally, following the changes to Component.Name, I have updated my drawings as any name changes impact on my door and window tags.  While doing so, I took the opportunity to update the logo on my title blocks, as well as include a view schedule on each of my drawing sheets.  Placed in the bottom left of my drawing sheets, I now know what views are included on each of my drawings.

 

ViewsOnBorders
Referenced, for my pleasure.

 

And there we have it.  These improvements to my information model not only help me achieve my Model Purposes but also help ensure the relationship between each part of my information model.  As a result of this Summer Sort out, I have consistent component names across my graphical models, non-graphical information, and documentation; reinforcing the fact that I manage my home through a single source of truth.
SingleSource.JPG

Note:  If you have any comments regarding my summer sort out, then please let me know either on Twitter, or by commenting below.

Update:  Included changed to IFC file naming following a query by John Ford.

Naming Omnibus

Dan10 Comments

Hello BIMfans,
While developing my information model, ‘naming’ has easily given me 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 navigation, I have structured this post as follows:

  • Directory naming
  • File naming
  • View and symbol naming
  • Layer naming
  • Object naming
  • Type and component naming
  • Level naming
  • Space naming
  • Property and attribute naming
  • Title block naming
  • Text naming
  • Line naming

Directory Naming

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 its 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 means don’t bother…

 

File Naming

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 my native files use ‘M3’ and my IFC files use ‘MR’ as they are renditions out of their respective native models.

 

Models
Looks at those tiny file sizes!!

 

View and Symbol Naming

The naming of containers within files, such as views and symbols 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.

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

 

Layer Naming

The naming of views and symbols above is based on ISO 13567-2, which covers the naming convention for layers.

Layers:  <Agent(Role)><Element><Presentation><Status*><Sector*><Phase*><Projection*><Description*>

A key difference is that ISO 13567-2 uses a fixed field system.  Meaning that there is no need to use a field separator. Instead, hyphens are used as a ‘general’ symbol and underscores as ‘not used’.  Due to issues with Uniclass 2015 that I have expressed a concern over, I haven’t implemented this yet.  However, an example layer would look something like this:

A-2530__–DoorsAndWindows

Object Naming

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 in another standard.

DoorNaming

 

Type and Component Naming

The naming of almost everything else 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

Level Naming

The numbering (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.

However, I have also chosen to name my floors, and have done so following the component naming listen above to get:  Floor 00, Floor 01, and Floor 02.  Note:  This is different from my storeys which are Storey 1, Storey 2, and Storey 3 respectively.

Elevations.PNG

Space Naming

The naming (referred to as designation) of rooms and spaces 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.

COBieSpaces

Property and Attribute Naming

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.

 

Title block Naming

The naming (referred to as designation) 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

 

Text Naming

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

Text Styles:  “Lettering ISO 3098-1” – <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.

TextNaming_New

 

Line Naming

The naming (referred to as designation) 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.

Line_new

 

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

Update:  Text naming image updated following a clarification comment around how ISO 3098-0 naming can be applied within Revit.  Thank you, Nathan Beevers.

PLQ 3.3 – Understanding Uniclass 2015

Dan8 Comments

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 isn’t exactly how it should be used, so I wanted to share with you why and what changes I needed to make.

NOTE:  Sarah has written an article on Uniclass 2015 which really helped me understand Uniclass 2015.

Classification:

Ok, a quick bit of context, what is a classification system?  Basically, classification is a method of categorizing ‘things’ into classes, ‘things’ that share the same characteristics. Classification impacts on everything (everything? EVERYTHING!), from the Tree of Life,  the age-old debate around Whether Jaffa Cakes are in fact Biscuits? (Fun fact: 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 producing classification systems, ISO 12006-2.  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 UK classification systems (CI/SfB, CAWS, Uniclass, Uniclass 1.4, Uniclass 2,…) aligned to this standard.

Note:  Before any QS/Estimators kick-off comment, I will point out that the RICS‘ New 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 when exporting an IFC, each object’s classification code and description needs 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…

This information is then exported into an 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 manage 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 maintenance schedule?…

Drawing to Conclusions

Dan6 Comments

Hello BIMfans,
During the development of my information models, I have considered a lot of different aspects, including Mindful Modelling, Open data and Producing with Purpose.  However, these information models aren’t the only deliverable I should be concerned with.  I will also need to produce documentation, such as COBie and, more importantly, drawings.

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

To produce objects for my information models, there are standards such as the BS 8541 Series, to produce COBie there are standards such as NBIMS 4.2 and BS 1192-4, but what about for producing drawings?  In fact, there are a lot of supporting standards that cover the various elements of drawing production including:

Paper Sizes:

As I wanted to create several drawings including plans, elevations, and sections, I needed a readily available paper size (that didn’t require a large format plotter), so I chose A3. A3 is a standard size, 297x420mm, specified within ISO 216. The beauty of the A-series is that they are easily scalable; doubling in size as you go up the series.  This is because they are based on √2.  I’d love to explain this to you in detail, but Numberphile have kindly already done this for me!

Now that I’ve chosen my paper size.  I need to define my drawing border.

Drawing Border:

There is an international drawing border specified within ISO 5457. It states that the drawings space for an A3 sheet is 277x390mm; giving 20mm clearance on the left to allow for filing and 10mm of clearance on the remaining sides. It also states that drawing borders should have centre lines, a grid system and trim markings; which when combined, look like this:

iso5457drawingsheet
I like the specified ‘A3’ the corner to indicate the paper size, but to be honest, this feels a little over the top; no matter it’s in the ISO!

Now that I have a drawing border, I need to add a title block.

Title block:

There is an international set of title block fields within ISO 7200.  ISO 7200 covers all document headers and title blocks, meaning that it is applicable to anything from drawings and calculation sheets to splash screens and metadata.  It states that the following fields are mandatory:

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

In addition to these, I also want to include several of the optional fields including project name, document revision, document status, and technical reference from an expanded list within EN 82045-2 which specifies metadata for document management.  This will not only allow me to comply with ISO 7200, but also capture additional information that I wish to share.

Now how should I arrange these fields?  Originally, I had created a horizontal title block but ISO 9431 states that the title block space is also used for text notes. Wanting to keep this space to a minimum, I have =produced a vertical title block to the minimum specified width of 100mm.

TitleBlock

Note:  To better align with ISO 19650-2 I have changed Technical Reference to ‘Checked by’ and renamed Approval Person and Creator as ‘Approved by’ and ‘Created by’ respectively.

Note:  This is also my splash screen to ensure that I manage models using the same metadata have I use for drawings and other deliverables.

Now that I have a title block, I just need to add my text notes.

Space for Notes

The space for notes on drawings is specified within in ISO 9431.  ISO 9431 states that there should be a space, the length of the title block, for three kinds of notes:

  • Explanations (notes that help read the drawing);
  • Instructions (notes on how to use the drawing); and
  • References (notes on supplementary drawings and documents).

Under explanations, I’ve added a note on general tolerances as specified within ISO 2768, a note on dimension units as specified within ISO 129-1 and a note on symbols as specified within BS 8541-2.  Under instructions, I had added ‘do not scale’, however I am aware that many planning authorities do not accept drawings with this note.  Because of this I have instead used ‘Responsibility is not accepted for values obtained in scaling from this drawing’.  Under references, I’ve included a schedule of relevant drawings.

Font

There is an international font for CAD drawings specified within ISO 3098-5.  As you are no doubt aware, no annotation is complete without a good font, for CAD there is no font better than the ISOCP fonts (These fonts come preinstalled in most CAD software).  These fonts are Sans-Serif (without serifs), and looks like this:

quickbimfox

Putting all of these elements together, I get the following super-ISO title block:

TitleBlock_Complete
At A3 the notes section looks quite large, it looks much better on A1 drawings!

Now that I have put all of these standards together, I am able to complete my drawings; producing the following for Tŷ Digidol:

NOTE:  All of these international standards are also conveniently summed up in a single British Standard, BS 8888.  Thank you John Ford for letting me know!

And there we have it, by thinking about how to produce my drawings, I have been able to apply several international and national standards to produce an internationally consistent drawing border and title block.  This is 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

Dan2 Comments

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…

Language, the not-so-silent BIM Killer

Dan1 Comment

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…

PLQ2.5 – Type Trouble

Dan5 Comments

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

Dan1 Comment

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…