"Our model checking wizard take you through the items to inspect..."
In this article we will share how we check BIM models pre-handover to evaluate their suitability for operations use. We will try to answer the question “are these project information models on their way to becoming a good “Asset information model” as the figure below suggests.” This is not a theoretical post about what an ideal operations model would look like. It is more about looking at the current state of the industry and give our view on what to check and what to change mid-project to better align with future BIM for FM strategies. Changing mid-project is hard so the real benefit may be more in influencing new projects to set early requirements for operations suitability.
In the previous two posts we have talked about IFC and COBie as important parts of the openBIM solution to structure and exchange data between disciplines and phases. We talked about how they lay the groundwork for lifecycle BIM and construction handover. In this article we share how we check and verify BIM models as they are moving through the stages. We will do the check with our “operations”- glasses on. The article will not cover model validation for constructability, clash detection, building code compliance etc.
Will it be as smooth as this indicates?
The context - typical Project Information Models of today
A BIM project of today are typically :
- in the design- or the construction stage
- using BIM tools for the major design disciplines
- using IFC for design coordination, clash detection, visualization, information takeoff etc
- have some BIM requirements & a BIM Execution Plan (BEP. BEP are very generic and not many additions have been made to a standard template.
- Have no specifications for model-based handover or the specs are very generic, e.g. “the project shall provide native files, as built IFC and COBie spreadsheets” instead of having clear Employer's Information Requirements (EIRs).
In our experience this is quite common and only expected at this current stage (early 2016) as there has been little standardization, projects take a long time and it is natural to start focusing on BIM for the early stages. This is where the use of BIM tools come natural (The BIM guidelines as the extensions to the CAD guidelines).
What to check
Checking model compliance for handover can be divided into two main categories
- Are the BIM Execution Plan for this project suitable for operations considerations and are the team following the plan?
- Are there a structured way to either add or link product and system O&M data to the models according to client requirements and again - are the spec being followed?
For the first part we check the core as designed/ as built built models. These models have been developed primarily to support the core AEC processes. We check if the structure and geometry derived from modelling are suitable for supporting operations. Is the model a good master-data model that can be the core of an asset register? Is it something you can link or embed FM documentation and FM processes to?
For the other we check the way the model has been used to collect product data and O&M documentation. This is relevant for product install and handover phases and involves data either embedded or linked to the models. These requirements are stated by the owner and their needs for operations support. This can be handled by COBie specifications or similar and will not be a part of this post. We will rather get back to it later
How to check and what to validate
A check should validate some criteria. Those criteria should be requirements from the owner. Requirements can be supported by industry standards and templates but that is not enough. Very often we see however that there are no specific requirements. You can still test according to this guide as we give generic advice.
These are tests you can do yourself either in your BIM tool of choice or with free BIM viewer tools like Solibri or Navisworks. At Areo we are working on tools to make the process of self checking even easier. Stay tuned and follow us for updates.
When we check models we like to have access to both the ifc file and the native file. The proper check is always done to the IFC export file. However when we find shortcomings or deviations in the IFC file it is always good to have access to the native file to see if the information is there in the original. Sometimes the problem identified (e.g. missing component to space relations) are just due to wrong ifc-mapping or wrong export settings.
We have a constantly evolving checklist we use when checking the model. It has been created based on our experience with the models tested along our way. The purpose of the checklist is to capture best practices and provide some kind of structure to the process. Since we usually do not have specific requirements to validate against we can only semi-automate the process. A wizard take you through the items to inspect and the model is exposed in context (data and geometry are filtered, highlighted and hidden to support the checking process).
Whats in our checklist
All models should have correct geolocation and rotation info. Errors should be fixed as soon as possible. Normally we check the footprint of the building on a map to see if it is correctly georeferenced/ rotated. We often see that geolocation either is missing or that some default location has been used. We therefore see a lot of buildings located downtown Chicago, Boston, Oslo or even where the Prime Meridian crosses Equator. Rotation is often missing, or has been implemented in a way that rotate the floorplan wrongly. We want the building footprint rotated correctly on maps but the floorplans should be rotated along the gridlines of the project.
It is important that the architecture, structural and MEP models are correctly aligned in 3d-space. With alignment we mean two things.
models should be aligned to the xyz axis (to avoid strange rotations in e.g. floorplans)
Models should match( to avoid offset and incorrect data).
Even if we have the possibility to move and rotate discipline models inside Areo we want both the native and the openBIM models to have correct location info from the beginning of the project. Areo is not the only tool needing the locations sync´ed so they may as well be fixed in the native files and exports. If you start offsetting models in the BIM checker tools you start accepting incorrect data that will come back and bite you later
Consistent use of IFCGUIDs across exports (same model)
If the same model is exported multiple times the ifcGUIDs for the same objects should stay the same. This is often handled by the BIM tool but you may have to choose the correct setting to make it work. If the correct ption is not turned on even a small change in one element will change all IFCGUIDs of all objects in the model. Then managing linked resources in COBie spreadsheets and external databases will be a nightmare
Consistent use of IFCGUIDs across exports (different discipline models)
When domain models share objects we would like them to use the same IFCGUID. This is mostly relevant for buildingstoreys (floors) and spaces (rooms). However it rarely is the case that they are using the same IFCGUIDS. If we cannot have our wish then at least we want them to be consistent and have the same name/ id. If not we end up with multiple floor objects (“floor 1” & “Floor_1”) with different disciplines lining to each of them
Simple/ normal buildings should have a straightforward building-floor-room structure that make it easy to navigate the spatial structure in both picklists and visual navigation. If the buildings are more complex it may make sense to split a building into building sections or group buildings into building complexes. IFC have support for this.
There should be spaces on all locations where you need to maintain equipment and identify issues. Often times we find that spaces are missing on flat roofs, external stairs, external parking lots etc. We know that this is not common practice and most spaces are created automagically by the BIM tools based on where there are physical boundaries (walls, doors, slabs etc). These extra spaces may not be important during design but are very helpful for operations.
IFC and COBie also give the opportunity to use zones to group spaces. Usually these zones will be established by the owner after handover, but it may also be relevant to use ventilation zones, access zones etc that are included in the design. The needs should be specified by the owner.
(Please note that the zones we are talking about here are zones as described in IFC and COBie. Zones in IFC/COBie are groups of spaces. Spaces are what Revit calls Rooms and Revit Rooms are the same as Archicad zones”).
Levels and floors with consistent naming
We only want to see levels that are proper building storeys that contain spaces. Often we see that levels in BIM tools are not necessarily building floors. They are sometimes multiple levels used to help model the building (e.g a ceiling level). The export should filter out these “helper” levels.
Having equipment and components grouped in systems is very important for MEP models. Systems should be named according to the needs and wants of the owner. Often the system naming aligns with some classification system (E.g. Onmiclass, Uniclass, NS3451).
It is very important that the actual system groupings are correct. They rarely are and errors are identified by filtering and visual inspection of the MEP models.
It should be easy to use the name of types to locate them both when adding O&M docs to the types but also when navigating the model to find equipment. If we are testing models pre-construction or if the models are not updated “as built” we often see a lot of strange content here. Objects are not properly grouped in types and the type naming looks “random” (often it is generated by the BIM tool). Again if there are no requirements in the BEP it is hard to test or validate. If possible some classification system should be used to have consistent type naming. The logic that is already in the model should help the designer to name the types semi-automaticaly.
Space names should have both a number and a descriptive name. The numbers should be unique and shared across the discipline models to make it easy to merge models and/or export to COBie with consistency.
Equipment naming/ identifiers
Naming and identification of equipment is very important and a way to connect models, asset-tagging and documentation. Usually the naming is not consistent. The reason is that the models most often are “as designed” and not “as built” (or as physically tagged).
Whatever equipment belongs in a COBie spreadsheet should have proper identification. For the rest the default identifiers generated by the BIM tools are OK.
There is also some uncertainties in the industry whether the naming/ tagging of components should be the name, description, tag or a custom property. Let us know what you think below.
Being able to identify the location of equipment and components is key for Facility management processes. To align with COBie the relation should be to the space where the equipment is accessed from (when doing inspections or maintenance). Having a component to space relation seems logical to expect but in practice it is very often missing, especially for building services models.
Only equipment that require operations and maintenance (COBie objects) need a location.
Please note that when exporting standard coordination views from Revit the spaces are not included in export and therefore any equipment/ furniture to space relations will be broken.
Please note that equipment location should be tested for both phases (as designed and as built) to ensure there is no big changes in the project that will give incorrect data to the model. The as-built checking is out of scope for this article however.
All rooms(spaces) should have finishes and colors for all surfaces. It is not sufficient that that the components building elements that make up the room (walls and floors) only have materials. We know this is not a requirement but as it can be quite useful for maintenance, we use to suggest to have it as a room property. Finishes may be different for each space even if they share a common element (e. g. a slab that goes across different rooms).
Room to door and room to window association
To locate and maintain doors and windows they should have a relation to the space(s) where they are located/ from where they will be maintained. Practice here varies from owner to owner and system to system. Someone say doors should be just related to one space. Some say it is OK to have relations to both spaces the door is connecting.
Building elements, components and spaces should be classified according to the classification system chosen by the owner. This make COBie export and import to the CAFM system of choice easier. Should use a proper ifcClassificationReference unless the owner wants to use a specific propertyset for some reason
Checking that the correct properties has been used with the correct property sets, values and units has been used is an important part of a handover model validation. To do this one need clear requirements on what standard property sets to use and what custom property sets and properties to use. Current practice at least for smaller projects is very random as you would expect when there are not specific requirements. We will skip this one for now and dedicate whole
We are constantly improving our BIM for FM model checking intiatives and will continue to share our findings along the way- If you have comments or inputs to our text above we would love to see them in the discussion forum below.
We also do free model checking from time to time to keep learning and testing our approach while hopefully giving some value back. If you are interested in us testing your models please mail us at firstname.lastname@example.org or tweet us @areo_io