So I needed to be able to specify what we expected and inform engineers without being ambiguous and while remaining auditable. I like to use SMART criteria:
- Specific - so others know what to enter and expect;
- Measurable - as I need to check the QTOie [QTO information exchange; read part one of this story - ed] file is valid and can be used;
- Achievable - because you can’t provide what you don’t know;
- Realistic - as you still have to do it; and
- Time-bound - we have deadlines and budgets so I need to be within those.
Thus, I came up with the following fields:
Field Heading: QTOie.Type.Name
Unique product reference defined by project standard.
This will be the Primary Key for the table and needs to be unique. This needs to match what is labelled on the design documentation, i.e. the type mark, which is common practice for architects and structural engineers. I’m firmly in the M&E union and have never put type marks for containment, pipework, etc., and I don’t want to create too much more work, so I have been accepting family and type names for these elements.
Field Heading: QTOie.Type.CreatedBy
Contact email of company creating or updating data. Referenced from QTOie.Contact.Email.
Same rules as COBie.
Field Heading: QTOie.Type.CreatedOn
Date the information was added or updated.
Same rules as COBie. Dates in ISO 8601 format
Field Heading: QTOie.Type.ElementCategory
Field Heading: QTOie.Type.ProductCategory
Field Heading: QTOie.Type.SystemCategory
Classification of the element.
Most Lead Appointed Parties I have worked with ask for all the modelled elements to contain the Uniclass for element, product and system, so it’s easy enough to include in the schedule. This will also help with compliance of classification.
Field Heading: QTOie.Type.Description
Description of product.
Tell me what it is! This doesn’t need to be overcomplicated. If it is a product, put the product name in. If it is a steel column, put ‘steel column’. I have learnt that there is no such thing as obvious when it comes to descriptions. Some people looking at this data have no concept of some elements.
Field Heading: QTOie.Type.Size
Size of element to different same category items. For example, thickness for wall; size designation for structural elements; sectional area for containment; diameter for pipe.
In combination with the description, think about how this is labelled on a drawing or specification. Putting 15Ø Cu pipe on a drawing seems to satisfy the readers’ needs: that’s enough for this.
Field Heading: QTOie.Type.Manufacturer
Reference QTOie.Contact.Email of manufacturer or supplier.
This should be known for products, even from an early stage as there is “equal or approved” in specifications. We always understand that some things have no manufacturer or are a composite of products that are constructed on site, so a “[email protected]” email address and contact will overcome any compliance issues.
Field Heading: QTOie.Type.EPD
File name of environmental product declaration (EPD) completed in compliance with EN15804 for the product or “Not supplied” if not supplied.
It’s not easy to get these, as a lot of suppliers don’t provide them. Well, if we don’t keep asking for them, they are never going to do it, so let’s keep at it!
Field Heading: QTOie.Type.Quantity
Total quantity of element within project. Shall be length, area, volume, weight, depending on standard take-off measurements, or total number of elements.
This is where we should be able to take the quantity automatically from the design model.
Field Heading: QTOie.Type.kgCO2e
Kilos of carbon dioxide equivalent per unit measurement up to the point of distribution. Not required if EPD supplied.
Another one we will struggle with. Some governing bodies provide this (structures) and once you have a figure, it can be used time and again.
Field Heading: QTOie.Type.QuantityUnit
Measurement unit. Use ‘count’ if simple number of items (such as pipe bends).
This needs to be left to the information provider. Being M&E, I thought if I said there was 15m of UB 305x305x15, the QS would be happy. Turns out they wanted total kg.
Field Heading: QTOie.Type.MakeUp
Material of the element or a breakdown if a composite material is used. For concrete elements, C32/40 20% cement replacement, or this: glass 43%, aluminium 36%, steel 12%, bronze 7%, plastic 2% and so on.
Hollow/void space shall be included when quantity total is generated from models without hollows/voids modelled.
Not required if EPD supplied.
This is the key. Tell me what something is made of. Walls are easy: you have created the elements in your software. Reinforced concrete: I’ve discovered someone somewhere writes kg of rebar per m3 – perfect! Grades of building elements are in your specifications already. There’s no need to overcomplicate this. For copper pipe, I’d be happy with ‘copper’. Until someone comes to me saying there are different compositions of copper in different copper pipe, let’s not worry.
Field Heading: QTOie.Type.ExpectedLife
The expected service/design life of the product.
Not required if EPD supplied.
Everything has a design life, even if the information is provided by your governing body, surely?
Field Heading: QTOie.Type.Recycled
Percentage of recyclable content as specified on manufacturers’ data sheet.
Not required if EPD supplied.
I got this requirement from our lifecycle analysis consultants. It turns out they meant ‘what percentage can be recycled when demolished’, not how much of the product is using recycled content.
Field Heading: QTOie.Type.Density
Density as specified on manufacturers’ data sheet.
Not required if EPD supplied.
Steel framework: I assumed this would be quite easy; not sure for cable tray. We’ll definitely rely on manufacturers’ information for this one.
Field Heading: QTOie.Type.Disposal
Any information on the technical recyclability or disposal method used will help inform the end-of-life-modelling of the building. Classification of waste stream if this is not available such as. LIT10121 Waste classification
Not required if EPD supplied.
Another one from our lifecycle analysis consultant. This might be a bit wishful thinking if they haven’t got an EPD, however, we need to set a target.
Field Heading: QTOie.Type.DistributionPoint
Contact email of company distribution point. Referenced from Contact.Email.
Not required if EPD supplied.
This cannot be provided until either a product or a supplier is selected.
Field Heading: QTOie.Type.FireRating
Fire rating of element.
This information is already known in the design. This isn’t carbon accounting related, but it is definitely design information that will be useful to know. Obviously, not required for containment and pipework
Field Heading: QTOie.Type.SecurityRating
Security rating of element.
This information is already known in the design.
Field Heading: QTOie.Type.KValue
Thermal transmission of element (W/(m²K)) (combined U-value for multi-part elements)
This should be known for walls and pipe insulation.
Building element information
Surely, the above would inform anyone who wanted to know about the COBie-excluded elements in a building? It means I have a structure I can ask for to get consistent information from our consultants, which can then be shared with anyone that can open with Excel.
I have tabulated the requirements here for anyone to view, comment or download: Steven's QTOie Rules.
In the next and final part, I will look at how to get this information from our consultants.
Read pPart three of Adams' QTO journey.
Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.
