This is not a paywall. Registration allows us to enhance your experience across Construction Management and ensure we deliver you quality editorial content.
Registering also means you can manage your own CPDs, comments, newsletter sign-ups and privacy settings.
The type sheet in COBie itemises each product once, whether used once or 100 times in the design. The Component sheet went well previously (see part one): let’s hope the Type sheet will also be simple.
“COBie files from real projects I’ve seen have a plain language company name or a company email address, but that email address certainly never appeared on the contact sheet.”
Steven Adams
NBIMS description: “The Type.Name must match the value found on design drawing schedules at the equivalent project stage of the current deliverable.”
Type.Name is the primary key so this must be unique and what Component.TypeName needs to relate to. This is how the Component sheet is linked to the Type sheet. Component.TypeName looks up Type.Name.
The format of this one was a puzzler for me. If I had four generators all of the same type, I couldn’t think how that appears on the design documentation. I’d normally only list GEN1, GEN2, GEN3 and GEN4 and would not create a “Generator Type”.
Also, for luminaires, I’d show Types on drawings, A, B, C. But I may also have Types of door readers A, B, C, so that won’t satisfy the primary need for uniqueness. I needed to revisit this. Let’s look at what else I wanted.
Field heading: Type.Category
NBIMS description: “The category of type described by the COBie data set. If allowable values are not specified by contract, the default value for this information is the current OmniClass Table 23.”
Well, in the UK we use Uniclass, and I try to give everything I model the Pr, Ss, and EF classification by default. As this is a product, I used the Pr table. Done.
Field heading: Type.Description
NBIMS description: “A general text description of the type. If description is present on design drawings schedules, this value must match.”
I had this issue with my Component.Description: to automate as much as possible, both for generation and checking, I used my reference list for equipment. I just needed to keep expanding my default list of equipment types, the reference code and the description.
Field heading: Type.Asset
NBIMS description: “A classification of the asset within one row. If allowable values are not specified by contract, the default values are: ‘Fixed’ and ‘Movable’.”
Looking at this, I thought: “It’s referring to something portable, i.e. an asset that could be moved from one space to another – a mobile load bank for my numerous generators, for example.” Most things will be fixed so that made it easy.
Field heading: Type.Manufacturer
NBIMS description: “During construction and handover phase: the Contact.Email of the installed product. During planning and design phase: not applicable.”
There are a couple of things here. First, this definition states “Contact.Email” and, second, in the examples they’re always coloured salmon, which means they’re a “reference” field. No one has said “foreign key” yet, but I think it should be called that. COBie files from real projects I’ve seen have a plain language company name or a company email address, but that email address certainly never appeared on the contact sheet.
Moving on, I wanted a manufacturer added to the contact list and the email address added to Type.Manufacturer. This has sparked several discussions at every stage of projects: “We don’t know the manufacturer of valves at Stage 3.” No, I wouldn’t have known when modelling, but talking with my engineers, even at Stage 3, they’ve stated a manufacturer and “equal or approved”.
I still get a lot of push back: “The contractor chooses the manufacturer.” Well yes, but this is telling me what’s been designed at this point in time. Just because you’ve put M&M Enterprises at Stage 3 doesn’t commit that type to be used. After all, you’ve put M&M Enterprises or equal and approved in your specification.
“At Stage 3, do I want to know the manufacturer of a valve? What are the consequences of not knowing it?”
Steven Adams
Some things I don’t think would have a manufacturer. Doors seem to be selected very late on; fixtures and fittings can be generic early on, etc. Thinking about how I’d produce a schedule, I’m sure I put “generic” a lot. The manufacturer is just a foreign key to make the database work. So as long as it’s in the format of an email address and is on the contact sheet, I made up “[email protected]” for those items, and added that to the contact sheet using Contact.Company as “Generic”.
The purpose of information
This brings me back to the purpose of the information. At Stage 3, do I want to know the manufacturer of a valve? What are the consequences of not knowing it? In the end, working with my M&E engineers, we decided to break down assets into four categories so we could share a different level of information for different pieces of equipment at different stages:
- Capital plant: this is what would normally be designed during Stage 3. The key plant, transformers, generators, chillers, air handling units, etc.
- Equipment: this is what would be added to the design during Stage 4. We’re adding air terminals, dampers, valves, meters, etc.
- Fixtures: things like luminaires, light switches, fire alarms, CCTV, furniture, etc.
- Openings: doors, windows, gates, etc.
I need to make sure any maintainable asset in COBie falls into one of these categories. Therefore, I have an ever-expanding list of plant equipment.
The common questions at this stage include: “Do we need the information in COBie? Is it realistic to expect all this information to be delivered at Stage 3?”
Showing a rectangle on a drawing and a bit of text to say “Air Curtain” is different to also providing a load of information about it. My goal for the future is to get the structure and format sorted. This will eventually allow all the information to be in our models by default and give us easy and simple access to them.
So I’m planning to give COBie for Capital plant at Stage 3, including what we should know, for example, a manufacturer (how did you size it if you haven’t contacted manufacturers?) and also have a list of doors at Stage 3. But I don’t need to know the manufacturer until Stage 4. This has also allowed me to revisit Component.SerialNumber. So I won’t plan to provide serial numbers for fixtures.
Now that I had categorised my assets, I could return to my Type sheet.
Read part three, in which Adams addresses further information on the Type Sheet.
