In part 3 of this series we spoke at length about the difference between Revit’s type and instance parameters and we related them to catalogue and inventory items that are typically tracked in a facilities management system. In this blog post I’ll try to make some recommendations about when to use type vs. instance parameters in your Revit families and also talk a bit about data tracking priorities and required vs. optional content.
There are two main considerations that we need to consider before we move to an explanation about how to organize information about our assets. This is a post about Revit so we’ll want to think about our building assets in general and then consider whether or not we actually want to include them in a Revit model that has been specifically created for facilities management. The same principles would generally apply to a model developed in the AEC process that you want to modify for use in daily facilities management workflows so keep that in mind as you think about how all of this applies to your models. The first thing to consider is why you would want to model a building asset in Revit and what it will be used for. We’ve worked with many customers who are moving to a BIM based lifecycle approach to facilities and one of the key lessons we have learned is that you typically will not be successful if you try to stuff a model from the AEC process that was developed for other reasons (clash detection, coordination, design, engineering, analysis etc.) into a facilities management solution without thinking about what you actually need the model to do. It’s better to keep the Revit model “lighter” with the key consideration being, does the asset you are modeling have to be tracked or maintained as part of existing ongoing facilities workflows? When you apply this basic reasoning you can quickly deduce that much of what may exist in a Revit model that comes over from design and construction contains detail that really isn’t that useful in day-to-day FM workflows.
An additional consideration when thinking about what types of data to include in your model and what you need to actually model should be whether or not the data that you can include is accurate and maintainable. There is inherent risk involved in terms of relying on questionable data especially when you are using this information for maintenance or costing purposes. When at all possible actual facilities data should be field verified to ensure accuracy. When you apply this approach to reality you can see that maintaining accurate data on a handful of key attributes which are maintainable is much better than including dozens of data points that are not easy to verify and could be inaccurate including being outdated or simply wrong. One piece of information that is imperative to include is a unique asset id that is durable and clearly labeled on a piece of equipment and also maintain that unique id on your Revit asset instance. I discussed the differences between type and instance parameters in my previous blog post which was tip #3 in this series so please refer back to that post for a refresher if you have questions.
You will also want to get a handle on how you categorize and describe the assets in your building. Typically we will think of these as “object types” which is a fairly broad category and could be something as simple as a pump. Once you come up with the basic categories that describe your assets such as pumps, chillers, air handlers etc. you will then want to determine which “asset types” belong with those objects. For instance if I have an object type of pumps, I might then have a specific type of pump that is base mounted–100 GPM capacity pump. Once I have my types established I can then begin to determine what data I will track on each instance of those base mounted 100 GPM capacity pumps that are installed in my facilities. Figure 1 below is a portion of a spreadsheet that I have developed that helps me to track all of the data that I want to track on my building assets. In this figure I’m simply showing this pump that I described above.
As you can see in the example above I am starting with a small amount of attribution for objects in my Revit model that are easily maintainable but also provide a level of information that allows me to uniquely identify and track specific instances of my assets. This level of information is easy to maintain and keep accurate and provides the basic data that can make it easy to attach the assets in your Revit model to your maintenance program for day-to-day facilities operations.
