Recognizing key ingredients

So what key ingredients do you need to make good objects? An object is actually a combination of a number of things, including the following that help you answer the corresponding questions:

• Information that defines the characteristics of the product: What is the object called? How does the object perform? How is the object maintained?
• Geometry that represents the product’s physical appearance and characteristics: How big is the object? What shape is the object?
• Visualization data giving the object a recognizable appearance: What does the object look like? What color is the object?
• Functional data, such as detection or clearance zones or data that enables the object to be positioned or behave in the same way as the product itself: Does the object open or close? Can the object only be positioned in a certain place?

Listing object types

Objects, sometimes referred to as families, are used throughout the project timeline, right from when you’re creating shapes and forms at a concept stage through to making a product selection and in-use. They contain varying levels of information, depending on whether an actual real-life named manufacturer product has been selected. This product selection process occurs at different times, depending on the procurement route selected. The contractor, rather than the architect or engineer in the case of a design and build procurement route, may undertake it. Understanding the different BIM object categories is important so that you know what the object can be relied upon for. Broadly speaking, objects fit into three camps:

• Generic object: You use a generic object in stages of the design when you’ve yet to decide on the final project or solution.
• Manufacturer object: Also referred to as a product object or proprietary object, a manufacturer object is an object that reflects or represents an obtainable product provided by a manufacturer or supplier. This is when those who are tasked with providing as-built information add details such as maintenance and warranty data.
• Template object: You use a template object to guide the production of both generic and product objects by providing schedules of classification values and a minimum number set of attributes.

Now that you have considered whether your object is to take the form of a generic, manufacturer, or template object, you need to think about how best to model and represent your object. This can take a few forms, and objects are generally

• Component objects: These are building products that have fixed geometrical shapes; for example, doors, windows, sanitary-ware, furniture, and so on. You can further break down these objects into
  • Static components: An object available in one size.
  • Parametric components: An object available in a range of predetermined sizes, or the designer can determine the size.
• Layered objects: These are building products that don’t have a fixed shape. Some examples are walls, floors, ceilings, and roofs. These objects are typically constructed from a number of layers (although just one layer is possible), and they don’t have a fixed geometry. The designer’s structural calculations define the geometry, which in turn determines a concrete floor layer thickness. Another example could be a wall, where the thickness of a wall is established; for example, it comprises a masonry outer leaf, insulation, and block-work inner leaf. However, the wall’s height and length will be determined within the project environment. Manufacturers may also determine the thickness of the object layers; for example, an insulation board may be available in a set number of thicknesses.
• Material objects: They carry information regarding identity, performance, and appearance. They can be used on their own, as finishes and coatings, as building products within an object, or as a way to represent an option within an object. The level of information for a material to be qualified, quantified, and specified within a project environment varies from a simple name and description through to detailed technical information.

Just as real-life construction products have a number of options, such as color and size, BIM objects can reflect these variations and options from which the designer makes a selection. How this is best achieved depends on the individual BIM platform. A BIM object may be highly configurable, with parametric features and component (instance) properties that require the designer to make decisions, making it very flexible. For example, an object that could be fabricated in any size may have component (instance) properties for height and width. A BIM object with multiple options may be developed as individual objects that are then embedded into the overall BIM object, such as a window that can be made up of frame, mullions, and glass.

Some BIM platforms work by using a catalog file that loads multiple versions of a BIM object. This can be very efficient in presenting many possible product variations. You often handle variations selections through a text-based file.

The BIM platforms used by designers handle multiple-layered objects differently. Some platforms can model multiple-product-layered objects; others don’t have this capability and the project team has to model the layers individually.

Typically, the project team delivers layered objects in a container file. This file can host the layered object and variations of the layered object, and the designer can select as required. For example, the manufacturer of a composite insulation board delivers all product variances in one container file.

You can use a number of BIM objects in combination to form an assembly. Assemblies are groups of components and spaces that allow many options to be described. By combining the objects in different arrangements, you can make many permutations of an assembly. For some construction products and arrangements, there can be millions of potential options.

Being aware of the timeline

Putting too much information into the model too soon may restrict both the design and supply chain options for others in the team and lead to other forms of waste with the inherent costs incurred by both the supplier and the client. It also places constraints on the supply chain to offer compliant alternative designs, offering better asset or value performance. Information requirements progress as the project develops. BIM objects develop with construction workflow and carry information that’s relevant to the particular stage of work the information is intended for. Typically, an object starts life as a generic representation, and at an early stage within the design process it may just show basic 3D geometry. This information may be just enough for space planning, but at later stages you need information to manage the asset to its optimal performance.

As the design develops, depending upon the design selection and criteria, information within the object becomes more specific and detailed. The project team changes to a manufacturer object, containing the actual properties. Evolving from generic to proprietary objects during the design process — and not, as often happens, during the construction phase — means that users have the opportunity to see in real time the effects of the product selection upon criteria such as performance and lifecycle costing.

At the design stage, consider what information the project team requires. Include 3D information with specification information attached, so that architects and designers can undertake early massing studies. For more information about specification, check out Chapter 17. A minimum amount of detail should represent the space allocation for any given product’s access space for maintenance, installation, and replacement. Also consider any operation space required, such as access requirements.

Describing object libraries

The client should document or reference specific controls and management of libraries in the employer’s information requirements (EIR; refer to Chapter 8 for more information about the EIR). The client should also document details of model definition and model development.

The EIR describes the details of where the project team can access BIM objects. BIM objects are shared among the team either from a central client or project library or from an external source such as a public BIM portal. The EIR should also include aspects such as BIM object version control and the exact level of detail and information BIM objects should contain at various stages of the project.

Comparing BIM object libraries

You use a wide range of objects, not just from BIM object libraries or manufacturers’ websites, but also content that manufacturers may have developed in-house or the standard out-of-the-box content that comes with your BIM authoring platform of choice. These sections identify the sources from which BIM objects originate and from where you can get your hands on them.

You can obtain objects in many ways, but be warned because they aren’t all created equal. Make sure you know the source of the content and the standards to which they’ve been modeled. Just because something looks pretty doesn’t mean that it’s correct or contains the level of information you require.

Deciding on how much is too much

Although you don’t want to produce too little information, likewise you don’t want to produce too much information. The key is providing the right information that is relevant and that is provided at the right time. Spend a moment to decide and plan how much time and effort you spend in providing information. Too much detail can reduce productivity and create waste during the design process because large models require more processing and longer file transfer times. On a large project the model can become unmanageable and may need to be subdivided.

Take a moment to think about whom the information is for and how it’s going to be used. For example, the detailed modeling of a toilet lever flush handle may include many facets and extrusions. However, at an early stage of design a generic object has little need for very high levels of detail. The project team or client may not have decided on the final toilet and flush handle.

The information overload will be exacerbated if more is included than is needed. You need to provide an appropriate amount of content at each stage. Although you can easily get carried away when modeling information, only model what is required. The amount of data should respond to the original questions that the client has asked in the EIR. You may see these questions referred to as plain language questions (PLQs).

In some instances, 3D geometry may not be required or appropriate. An example is in modeling a metal window. You model the outer profile of the frame but not the intricate internal framing members — you may represent these using 2D line work incorporated into the object and in digital 2D outputs of the project.

Consider parts of objects that you won’t model. Examples are fixings such as adhesives, screws, and bolts. They’re too small to model because too much detail compromises the usability of the object.

If in doubt, leave it out! Delivering a greater level of detail than you need is wasteful to the supply chain and may overload the IT systems and networks available. This problem is reduced as available processing power increases, either through internal IT or moving model tasks into the cloud.

Categorizing level of development

The US American Institute of Architects (AIA) document E202 defines level of development for model elements. Think of level of development as the overarching requirement for both the graphical level of the object’s geometry, which is called the level of detail (LOD) and the nongraphical data in the object, which is called the level of information (LOI). These two levels in combination form the level of development.

Note that you might also see the acronym LOD being used for the overall terms level of definition or level of development, especially in the United States. This can get confusing when you’re being asked to indicate what “LOD” you’ll be delivering. Make sure that everyone is clear on what any acronyms mean and that everyone is speaking the same language. Use our glossary to find simple definitions you can use on projects.

Because of the recent revolution in digital working processes and BIM in the United States the AIA decided to cut short its once-per-decade update process and release a set of dedicated contract documents about BIM and digital data. These provide frameworks and protocols for integrated project delivery and information exchange, and are as follows:

• AIA Document C106, Digital Data Licensing Agreement: This agreement clears up the legal liability and copyright permissions associated with collaborative project teams — for example, that any party exchanging data grants a limited license to the receiver to use the information on the project and guaranteeing ownership rights.
• AIA Document E203–2013, Building Information Modeling and Digital Data Exhibit: This document is attached to existing contracts, such as the Standard Form of Agreements between owners and project parties. You can consider it similar to the UK PAS 1192 documents, in that it establishes expectations for data exchange and provides guidance on developing a detailed process protocol for BIM and digital data, as a statement of intent.
• AIA Document G201–2013, Project Digital Data Protocol Form: In connection with Document E203, this G201–2013 Protocol Form documents the procedures for digital data communications and submittals — for example, the use of electronic data management systems (EDMS) and where data will be stored.
• AIA Document G202–2013, Project Building Information Modeling Protocol Form: In connection with E203 again, this document is specifically focused on BIM and the management of model information. In particular, this is where the level of development descriptions is defined so that everyone can agree on what the level means.

It’s worth noting that the AIA documents draw on a lot of previous information in earlier contract documents. The updated set includes content from the former AIA E201 and E202 releases. If you’re looking at this area of BIM in detail, refer back to these original documents, but some are only available via AIA software.

If you want more information on the AIA Digital Practice Documents, a great guide is available at www.aia.org/groups/aia/documents/pdf/aiab095711.pdf.

Defining the model’s complexity

AIA G202 talks about five categories of level of development (100, 200, 300, 400, and 500). Table 10-1 shows the potential levels of detail (LOD) and levels of information (LOI) for an example BIM object, in this case a boiler.

Each number indicates an increase in the amount of graphical and nongraphical data across the project timeline. As levels increase, the data is less generalized and becomes more accurate and more product-specific.

Embedding data into the objects

Not all the data lives in the model. It becomes impractical if the objects and hence the models are overloaded. The linking to other relational bases provides a wider source of information and empowers the object, making it a rich source of information. Think of a BIM object as a placeholder — not only a physical representation of the real-life physical properties of the said object, but also a home for nongraphical information such as performance criteria, cost, and operational details.

The next sections examine how to handle BIM objects that have multiple variations and options and consider the most appropriate place for information, either in the geometric model or with nongraphical data such as words and numbers that are usually found in associated documentation like specifications.

Following common approaches: Modeling requirements

To provide more efficient and accessible BIM objects, you must take a standardized approach. Creating digital buildings requires a consistent kit of parts that can yield all the benefits that standardization brings. Objects are easy to source and to use, and are comparable, interoperable. By standardizing the information within objects, you can compare them and make an appropriate selection for the project.

Common approaches to the modeling of the physical characteristics of products make the BIM objects simple to use, affording the designer a reliable, consistent, and intuitive experience. The hard work is in the detail; for example, BIM objects in IFC format. These IFC files are manipulated so that their information properties are consistently grouped and organized, which makes their use in various BIM software straightforward and consistent.

Another example is the use of standardized properties. The benefits become obvious when using objects from more than one manufacturer in the same project. When creating schedules that span products from many manufacturers, using a standardized property enables you to display information relating to each of these products in a single column, much in the same way you find the number of megapixels listed when comparing cameras.

You can find a lot of discussion online about object properties and naming conventions, but there isn’t much agreement on standardization. Some organizations are working to help the situation. For example, the NBS BIM Object Standard (www.nationalbimlibrary.com/nbs-bim-object-standard) defines minimum standards for BIM objects. It refers heavily to the BS 8541 series, a code of practice that takes the form of guidance and recommendations for library objects for the AEC industry, as well as COBie and the buildingSMART IFC schema.

Being consistent: Standard property sets

Consistency is fundamental to being able to correctly export information from within the object and use it in other applications. To meaningfully reuse the information, it must have a consistent set of parameters and attributes with consistent naming conventions. As a bare minimum, you can identify a product by a trade name or model number. At an early stage within the project this type of detailed information is unlikely to be known, as specific product selections are yet to be made. This is where a classification system such as Uniclass or Omniclass comes into force, as a way of the whole supply chain knowing that everyone is referring to the same thing. You may call a spade “a spade,” but your contractor may call it “a shovel” and your client “earth relocation equipment.”

A parameter is a property or attribute of an element; for example, fire resistance, material, type, and color. A property set provides a consistent set of properties across all objects, giving information such as version number, issue date, and classification.

Include standardized construction data and recognized standards such as

• COBie properties: This data standard was developed by the US Corps of Engineering to manage the data coming from BIM models into the client organization, particularly for the handover of operational and maintenance information.
• Classification: Classification systems are the tools that determine groups of things based on similar characteristics. They arrange information about a particular topic, coordinate and disseminate information, find and understand information, and join like information together. Whether you’re in the supermarket or searching for information on Google Maps, classification is the key to finding what you want.
• Interoperability properties: To exchange information about a building using common and understood rules, you use the Industry Foundation Classes (IFC) specification developed and maintained by buildingSMART International as its data standard and registered with ISO as ISO 16739.

Table 10-2 lists some essential properties you should include within your BIM object and what questions these properties are trying to answer.

Industry Foundation Classes

BIM authoring applications generally allow the user to identify a model subset (or filter) when exporting to IFC by exporting only the layers that are currently visible in the BIM-authoring application and allowing users to export only the parts of the model relevant to the purpose of the export.

In order to do this, the project team must categorize objects correctly. Some BIM platforms automatically assign IFC information based upon the IFC schema. Others require additional properties (for example, in Autodesk Revit the properties IfcExportAS and IfcExportType are used). Generally, software solutions don’t support the entirety of a schema such as IFC; they support an industry-relevant subset that’s generally termed a model view definition (MVD). Software may be certified in terms of how well it supports a view definition. That is, a view definition provides a relationship between the whole schema and the software solution that implements it.

COBie

When we refer to COBie, we’re referring to Construction Operations Building information exchange. COBie is a model view definition (MVD) of IFC that is a spreadsheet mapping of the FM handover view definition. This means that COBie is only concerned with a particular snapshot of the IFC schema that specifically looks at information that is useful to facilities management. COBie defines how the project team is to structure information and what the minimum data fields are. It’s a data format, not a standard on what information the project team is to provide for facilities management. COBie isn’t a predefined list of what information the client requires. So to ask for COBie without defining what you want in COBie is a bit like asking for a MS Word document without saying what you want written in it.

You can produce information for COBie in a number of ways. These include, but are not limited to, the following:

• Direct creation from the BIM platform. Objects may contain the relevant COBie properties.
• Production from an IFC file, using IFC-to-COBie translation tools and settings, based on properties as defined by buildingSMART IFC2x3 basic FM handover view.

Whatever method you choose, make sure that the properties are consistent and don’t contain a hybrid of the two. You can extract a COBie deliverable from the IFC if the data is structured and exists within the file. Likewise, you can push COBie information into an IFC file if the information is structured and exists within the file.

The total COBie deliverable is provided by a range of people and comes from many sources, and you can’t populate all information from the BIM platform. The BIM object should include COBie properties that don’t include parametric behavior, graphical, or stylistic information.

Value associated with certain properties depends on the stage of the project. Take, for example, the property “InstallationDate.” No value is associated because you don’t know this information until the product is installed. You complete some values such as “AssetIdentifier” at handover stage, where the asset is made available for use or occupation. In the case of generic objects, you don’t know properties such as “Manufacturer,” and therefore you enter a default value of “n/a” (not applicable or not available). This acts as an aide-memoir for information that may be completed later on in the project, often by a different person or organization.

For now, the UK government requires for BIM projects only COBie, native model files, and reviewable 2D PDFs. You can deliver COBie as a spreadsheet or an XML file (a structured text file, a bit like HTML). XML files require software to make them readable for people, so unless a software (or web service) is proscribed, the client normally requests COBie as a spreadsheet. The theory is that people can fill in a spreadsheet manually, yet you still retain the possibility of populating data automatically via software from BIM.

The COBie file, which can be as simple as an Excel spreadsheet, holds valuable information for the asset management. The data is exchanged using spreadsheets to keep the complexity of systems and training to a minimum. It comprises 16 tabs that hold information, from very generic things to very specific things, and lists all the products installed in a building including manufacturer details, replacement costs, warranty information, and links to maintenance instructions.

Don’t think you could deliver COBie through entirely manually filling in a spreadsheet. COBie spreadsheets may be readable for people, but they’re not human friendly (except maybe to computer programmers). True, you could set up human-friendly spreadsheets that fed data to COBie spreadsheets, but that wouldn’t overcome the enormous amount of data that you’d have to manually type in, check, and verify.

Think of COBie as a filter. COBie is a bus that gets you from one place to another. Or, to think of it another way, it’s a bag with various compartments to put your data into. The number of the COBie worksheets to fill in depends on the project stage. Project team members only enter the data for which they’re responsible. Designers provide spaces and equipment locations. Contractors provide manufacturer information and installed product data. Commissioning agents provide warranties, parts, and maintenance information.

COBie isn’t just going to fall out of your BIM. You need time to set it up, test it, and then do the export and validate it. Keep in mind that it will take a lot less time if you use someone who knows what she’s doing. Ideally, the information manager should program COBie data drops to avoid other deliverables. Expecting COBie to be delivered on the same day as a milestone document issue is silly. You need them for different purposes, so why increase everyone’s stress levels?