PLQ 3.2 – Classical Conditioning

Hello BIMfans,
When I made my information model I didn’t want it to be just for show, it wanted it to be a (useful) tool to manage my home. That is why I was very pedantic fussy particular about what information I needed by forming several Plain Language Questions, my Model Purposes, and my Data Requirements. Since this blog’s outset, one clear output I had in mind was to use the information model to manage any repair or replacement work needed within my home. To do so, I will need to form a preventative maintenance schedule; time for some Classical Conditioning!

I’m no Pavlov but I am known to drool over good information.

When I first wrote my Data Requirements, I was keen to incorporate a way to capture the condition of each of my components. The problem was, I needed a way to record this consistently; luckily for me, there is a way to do this.  BS 1192-4, the British Standard for COBie, includes some additional attributes under table 14, which are also included as part of IFC4 Schema, under the Pset_Condition property set.

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.

So, a plan was formed.  When I produced my components, each of these attributes were added to the one I intended to manage. As a result, this information appears in each of my graphical models, IFC exports, and COBie files (the joy of a single source of truth).  As the majority of these components were assessed when Chris John undertook a (very thorough) property condition survey before we bought the home, there isn’t much additional information to be collected.  The only exception being new items such as my Nest thermostat and Philips Hue bulbs that have been installed since.

As you can see, this window was surveyed August 2015, as part of the property condition survey, and it’s in a pretty good condition.

Using these assessment attributes, I can manage each of these components and develop my preventative maintenance schedule. For example, using the AssessmentCondition attribute, I can filter and identify any Very Poor or Poor components. Of the 100+ manageable components I have in my home, I can use Revit‘s scheduling function to filter this information down to just those components and form a manageable schedule.

NOTE: I could have done this using my COBie file, but I won’t.  COBie isn’t a data management tool. Until I acquire an asset management system, using the information embedded in my graphical models, as I have done, is the best solution.

By federating my models, I can create a single schedule showing all of the Very Poor and Poor components in my home.

And there we have it.  By using the information that I have already populated within my information model I was able to create a preventative maintenance schedule highlighting what components need to be repaired or replaced. This means that PLQ3.2 is complete; Woohoo!

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 what needs doing around my home, I wonder how much it’ll cost to fix…

Advertisements

PLQ 3.1 – Outstanding Openings

Hello BIMfans,
After completing my BIM Level 2 deliverables and publishing my Project Information Model it’s about time I put my model to work.  I have now entered the operational stage, which means I have some new Plain Language Questions to answer:

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?

So without further ado, let’s tackle Plain Language Question 3.1 “What are the sizes and condition of the windows & doors?”

construction-architecture-fails-mistakes-7
This is what happens when you accidentally flip your door vertically instead of horizontally in the model…

Now lucky for me, I have (technically) already answered this question as my Architectural COBie file has all of this information I need already included.  However, I don’t feel that COBie is the best way to communicating this information as I haven’t imported it into a suitable asset management tool (yet) and the information needed is on several different sheets.

doorwindowcobie
Sizes are on the type worksheet, while assessment information the attribute worksheet.

So I have instead decided to answer this question with a schedule.  As I have all the information within my model, it is just a matter of deciding how I want to structure my schedule and what information would be useful to include within it.

To answer my Plain Language Question, I will need Size (Height and Width) as well as Assessment Condition as a minimum.  However, to relate these back I will also need a reference for each component (IfcName), and a type reference (TypeName).

In addition, to make the schedule useful it is worth providing the type description (IfcDescription) as well as indicating which space each component is in, as well as the other assessment details (AssessmentDate and AssessmentDescription) to provide sufficient content.  This leaves me with a schedule that looks like this:

DoorSchedule Header

This scheduling format provides me with enough information to assess each of my doors and windows, find their location within my home, and includes enough information to arrange for a replacement if required.  Luckily for me, I could put all of this information onto a single A3 sheet, which can be accessed here.

SheduleDrawing.JPG
*Dan’s perfectionism sense is tingling* Why couldn’t I have only 4 door types??

 

Note:  You’ll notice that I have named this deliverable: 7001-BBH-ZZ-ZZ-DR-A-6001. While full of schedule information, it is a drawing.  If I had exported this information as a spreadsheet then it would have been a schedule, using the SH file type. However, as the schedule’s information cannot be referenced (can’t import this into Excel) and it is placed on a title block, it’s a drawing.

From this schedule, it is plain to see what my back door (DoorType04, Door05) and my bathroom window (WindowType08, Window09) require work.  There is visible rot on my back door and something that I had never noticed before about my bathroom window is that instead of a sill the installer used is actually a skirting board!

WindowSill.jpg
What kind of monster would do this??

And there we have it.  By using the information that I have already populated within my information model I was able to create a Door & Window Schedule with all of the information to answer this Plain Language Question and picked up which of these components need work. This means that PLQ3.1 is complete; Woohoo!

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 used by schedule to assess my doors and windows, it’s about time I look at what else needs doing around my home…

Update: Removed ‘OK’ for ‘Adequate’ under Assessment Condition to suit BS1192-4 permitted values as opposed to the IFC4 documentation example.  Thanks Nick!

Update: Turns out I had mislabelled by window openings showing them bottom hung as opposed to top hung (Ooops!); a quick check of BS8541-2 and it is all fixed.  Thanks Chris!

Update:  Changed ‘Mark’ to ‘IfcName to improve information consistency in all of my deliverables.  Tags, Schedules, and COBie now use IfcName consistently.

PLQ2.5 – Check, Review, Approve

Hello BIMfans,
After publishing my Architectural Model and my Mechanical and Electrical Models last week.  This week I am looking at some of the pedantic fantastic comments you have provided back and what I have done to resolve them; thank you for these.  Remember there is still another week to contribute so keep those comments coming!

So let’s see what comments I have had back.

commentsmeme

Volume Code

I was told that I have used the wrong volume code.  I had issued using the volume code XX-‘No associated Volume’, however, my Employer’s Information Requirements clearly states that I need to follow BS1192, which uses the default code ZZ-‘All Volumes’.  I agree, and have now renamed all of my outputs to use ZZ, and updated the appropriate sections of my BIM Execution Plan to suit.  Technically I complied with my BEP, but as Keith told me, I am a stickler for the standards!

Credit: Keith Wilkinson (@StudioBIM) of JM Architects.

COBie Contacts

I was told that my COBie contact sheet should include all of the suppliers, installers, and other contacts related to my home; not just the project design team.  I agree, and have now revised my COBie contact sheet to include all of the applicable contacts.  It’s hard to find guidance on the scope of this worksheet #excuse, but Dan knows his stuff!  I also really don’t like using the PM table in uniclass 2015 for this, but there isn’t a roles table.

contacts
I also have a spare at the bottom for any unknown contacts and to be DPA compliant I’ve only used email and contact details that are publicly available.

Credit:  Dan Mofakham of Cadan Design.

COBie Documents

I was told that my COBie documents sheet should be populated with my other outputs such as my drawings.  I agree, and as Revit cannot hold this information have used my COBie Post-process sheet to record all of the applicable outputs.  Nick, as usual, is technically correct (the best kind of correct).

Credit:  Nick Nisbet (@NickNisbet) of AEC3.

I was also told that my COBie documents sheet should include other documents such as my property condition survey and any designer risk assessments.  I agree, however, there are no designer risk assessments as I haven’t done any design on this project.  Similar to the above I have used my COBie Post-process sheet to record all of the applicable documents as well as my outputs.  Good thing I have no design, as I have no PI insurance!

Credit:  Chris Weston (@CWeston222) of Rio Architects.

documents
From my Prologue, you can see I have a lot of documents to manage.

COBie Jobs

I was told that my COBie jobs sheet is empty, therefore I must not maintain my home.  I agree with this, but as I have pointed out in a previous post, jobs are optional; so I am not going to use it.  However, on reflection it is worth considering, so It’ll feature in the new year when I am looking at my operational Plain Language Questions.  As I told Chris, despite what my COBie sheet says, I do vacuum my house!

Credit:  Chris Weston (@CWeston222) of Rio Architects.

IFC Co-ordinates

I was told that my IFC file contains some co-ordinates for my house; luckily for me those Co-ordinates are in London.  This is because of my data security requirements within my Employer’s Information Requirements stated each model had to have the co-ordinates of 0,0,0; and without changing the location in Revit, it has defaulted to London.  As a proud Welshman I’m disappointed of this default location, but happy my data security measures have worked!

projectbasepoint

Credit:  Nick Nisbet (@NickNisbet) of AEC3.

Splash Screen

Also, keeping with my BIM execution plan, I had also stated that all outputs should include my ISO7200 title block, but I had not included it in my native models.  To resolve this, I have added them as a splash screen when the models are opened.  Do I get points for spotting my own mistakes?

SplashScreen.JPG
This has had the added benefit of reducing my file size by 500KB as my model no longer has to store such a detailed thumbnail image

Credit: Me!

Note: I have also had one or two comments about the data format of some of my COBie fields. However, I’m aware of some other comments about this due next week, so I will deal with them all during next week’s post while I publish my documents.

And there we have it.  Thanks to the support of our wonderfully open community, I have been provided with a number of fantastic comments have have been used to improve the outputs from my information model.  This means that following another week of excellent input I should be ready to complete 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 the first set of comments resolved, lets see what you guys come up with next week…

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.

PLQ1.2 – Data Requirements

Hello BIMfans,
Now that I have worked out what Model Purposes I will be using my information model for, I need to work out what information to produce to satisfy these Model Purposes.  To do so, I will be looking at several key British Standards around exchanging information.

I’ve already discussed information exchanges when I formed my Plain Language Questions (PLQs).  In brief, within the BIM Level 2 process, there is a clear mechanism outlined within PAS 1192-2 to allow information to be exchanged from the supply chain to their employer.  The UK Government has outlined that its preferred method of exchange is through Construction Operations Building information exchange (COBie).

COBie
Don’t let her acting career fool you,  Cobie is a key actor in BIM.

So why COBie?  Well within the UK there is (currently) no formal convention on how to structure information.  The relevant British standard for applying properties to objects is BS 8541-4.  However, this standard is limited to: Guidance information on units, to name properties using CamelCase (no spaces), and that properties suggest what type of data should be used within.  However, BS 8541-4 uses examples that conflict with its own guidance…

Capture
CamelCase? No thank you, I don’t smoke.

However, despite this conflict, BS 8541-4 does provide real value and quite usefully refers to using the Industry Foundation Class (IFC) schema, which covers property naming, units, and property sets; developed by buildingSMART.  So I will limit myself to properties that appear within the IFC schema, specifically using the IFC2x3.

Luckily for me, by following IFC, I will also need to provide information in a COBie compliant structure.   In brief, COBie is an IFC file filtered to remove geometry and retain only the information to be handed over, complying with the COBie 2.4 MVD. Meaning that if I use the IFC2x3 Schema to add attributes, mapping to COBie’s structure should be a fairly simple process.

Note:  I’m not going to explain COBie in detail here, but if you want to know more Rob Jackson of Bond Bryan Digital has collected several COBie resources on one easy to access web page here.

So by using IFC, I can structure my asset information based on an internationally accepted open data schema. Meaning that I’m more likely to be able to use this information in other tools.  If I didn’t use IFC, then there would no doubt be issues with exporting information:

GiGo
Garbage in = Garbage out.  Explains the need for good data in construction (and my A-level results).

So now that I how I want to structure this information, I need to work out what information I want to capture based on my intended Model Purposes.

Register

I want to use this model to register each of my components.  By registering these components I can keep an inventory for content insurance purposes and to facilitate any other purposes such as repair and maintenance.  To register my components I need to include a unique reference, so I’ll need a ‘GUID‘, as well as the component’s ‘Name’Manufacturer‘, ‘Model‘, and if applicable ‘ModelReference‘.  I will also need to know when each component was installed my including an ‘InstallationDate‘, as well as its ‘ReplacementCost‘.

To register each of these components I also need to know what room they are in, so I need to register my rooms including ‘Name‘ and their ‘Description‘; both found under ‘IfcSpace‘.

Operations

As I stated when discussing my Model Purposes, this model will likely not be used for day-to-day operation, but I do plan on using information from the model to undertake a future SAP calculation, and will likely need to use this information if I have many minor works done to my home.  By capturing this information, I will also have the information needed to run any operational analysis in the future.

For the house itself, I need to know the ‘NumberOfStoreys‘ the house’s air permeability ‘Infiltration‘, as well as a custom property for my EPC Rating.  I couldn’t find a suitable property within the schema, so I will create one called ‘EPCRating‘.

For my floors, I need to know their ‘Height‘, ‘Area‘, and ‘Elevation‘.  Each of which can be captured by the base quantities.

For components (where applicable) I will also need to capture their geometry details such as ‘Height‘, ‘Length‘, and ‘Width‘.  Details of components specification such as their ThermalTransmittance‘ (U-Value), ‘Infiltration‘, as well as the ‘TotalPrimaryEnergyConsupmtion‘ for any electrical components.  In addition, I couldn’t locate a property for SolarTransmittance (G-Value) under the IFC2x3 Schema, so I will need to create another additional attribute ‘SolarTransmittance‘.

Maintenance and Repair, Replacements

Much of the information identified to register my components will also be used to manage any repair and replacements.  In addition, I will also need to capture warranty information such as ‘WarrantyStartDate‘, ‘Duration‘, and ‘WarrantyContent‘.  In addition, to schedule any planned maintenance, I need to capture asset condition details under ‘AssessmentDate‘, ‘AssessmentCondition‘, and ‘AsessmentDescription‘ to form a preventative maintenance schedule.

And there you have it.  By using my Model Purposes I have now outlined the minimum attributes I need achieve them.  Meaning I have now answered another Plain Language Question; PLQ1.2 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 information I need to support my Model Purposes, I need to establish what format I need this information in to make sure it is usable to satisfy PLQ1.3…

Note:  If you have any comments regarding my property data requirements, or the properties I have chosen, then please let me know either on Twitter, or by commenting below.