Considering the downstream activities for our BIM model to include facilities management, we need to decide right at the beginning of the project which standards and protocols we would employ to allow us to achieve this downstream goal. Specifically, we would need to identify assets of interest. And instead of managing each asset individually, we may want to manage them as a system instead.

There are many classification systems that will help you classify elements within your BIM model into assets and systems and the one that we decided to go with in this blog is the unit class system quite often utilised in the United Kingdom and the Middle East. There are others including the Omni class system for the Northern Americas, the Uniformat system there’s also a rather popular. Whichever one you decide on will be dictated by the requirements as stated by the client stop.

There are various mechanisms with which you can codify elements within Revit but the one that is generally preferred is by adding the data to shared parameters within the properties and instance properties of elements. To do this we employ the BIM interoperability tools for Revit which you can download from your Autodesk account. The unit class system is one of the standards that is available and is populated from online databases for which the shared parameter is also commonly defined. For those that understand shared parameters within Revit, this is a good thing because the Shane parameters GUID do not need to be managed by the manager instead it is managed centrally online.

In this example the elements are those within an HVAC system. The PR table of Uniclass system defines circular ducts and fittings (Pr_65_65_25_14), rectangular ducts and fittings (Pr_65_65_25_72), and oval ducts and fittings (Pr_65_65_25_31). For fittings that connect different duct characteristic shapes, “Pr_65_65_25” is used for ductwork and fittings. There is also a code for air terminals of various types which all share the common code (Pr_70_65_04).  

In this example there is one HVAC system with one return run and one supply run. In larger buildings there would be more than one edge HVAC system and multiple runs. In our example the return run and the supply runs are separate “systems”. Because HVAC systems connect logically and physically within the beam model, the assistant to which the elements belong are automatically assigned to the relevant system and we do not have to attach additional information to the elements to identify them within the relevant system. It should either be recognized that the unique identifier is not descriptive enough for the field and that some coding should be considered to identify their sequence of assembly within the run. One could use the instance mark for this purpose or to find some other shared parameter to serve a similar purpose.

Within the Autodesk construction cloud build module we can manage the assets. One of the tasks is to set up the categorisation tree for assets themselves. In this case one must take the system categorisation tree into account when one creates the asset categorization tree because they complement each other. Roughly speaking we follow the Uniclass classification to identify the three separate types of ducting and fittings (circular, rectangular, and Oval) as well as any air terminals within each system. At this stage we would typically load a model and use the rules that the Uniclass parameter must either equal one of the duct types or contain the common coding for the air terminals, and in addition they must also belong to a specific HVAC system. As soon as this is done each item may be identified via a QR code generated from their IFC GUID and can be managed in the field via the ACC mobile app.

As far as these systems are concerned we define the same general categorization of the ducting and air terminals, however we structure them as subcategories under the relevant system name. The rule mapping now assigns an asset category to a system. Note, systems may also be nested. Be careful, since, for larger systems, the asset display size limits the systems you can select. Be sure to keep on going until all the assets are recognized.

In my mind I envisage a system where a duct is identified in the model based on its Uniclass product classification and the system to which it belongs. In addition to that, a mark number that signifies its position within an assembly sequence is also recommended (an easier number for an assembler to understand). Given a large warehouse where many ducts are being manufactured (they may very well belong to different projects) the unique identifier will contain the information for the duct.

Perhaps the best way to identify assets in the field is by its mark (assembly) number. I would not be able to identify element name below because the family name is being used as the name of the asset. There are many of the assets that will share the same name.

The name tag below makes more sense from an identification perspective. Here the Mark has been assigned as an assembly code.  

MX = General Mechanical

FX4 = Micrographics Team 4

MSA01 = Mechanical Supply Air 01

B03 = Branch 03

A01 = Air Terminal 01

During my investigation into assets on ACC and envisaging the usage of assets in the field I’m growing more excited and optimistic about trialing this on a real project hopefully that comes along sooner rather than later such that a lot of data can be compiled on the Autodesk construction cloud that can be leveraged in the field and mined for executive oversight. This data could also include references to forms submittals and issues as well as RFIs and we’ll add trackable and traceable communication between the site and the project management and design offices

If you need help adopting the AEC Collection or the Autodesk Construction Cloud in your practice or you are looking to invest in hardware, please contact Micrographics so that we may be of assistance.