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

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…

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:

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.