Revit adoption keeps on growing. There is no denying the benefits of having an integrated project model that holds all related information. But as more and more companies move from using Revit solely for coordination to using it as a project tool encompassing all disciplines, the level of information management required from the application continues to grow as well.
At the core of this information smorgasbord are shared parameters. Shared parameters live within families, projects, and schedules. Ideally your project template already has schedules built in for use as deliverables, and your families have the right shared parameters to fill in these schedules from the moment you lay down your first wall. At the same time, content is coming from many sources: different groups or individuals within a company, product manufacturers’ websites, and third party providers (such as Andekan). Standards for shared parameters are required if project schedules are not to be incomplete at best, and erroneous at worst.
Some companies, or individuals within companies, believe the answer is to develop and use internal standards exclusively. Yet those BIM managers who claim their company’s Revit content is all created internally are doing a disservice to their employer. The task is too resource intensive, and public or third party libraries of content will grow to thousands and thousands of families over time. Ignoring the benefits of readily available content from the outside simply doesn’t make sense.
On the other hand, an industry standard for shared parameters must take into account the different disciplines within the AEC sector, as well as the industry specifics of various product manufacturers. To date, Autodesk has set the tone with their Seek team releasing an initial standard that contains shared parameters – the Revit Model Content Style Guide. The standard is limited, however, and has some incongruencies.
For example, the Seek standard has three shared parameters for fan power – Return Fan Power, Supply Fan Power and Exhaust Fan Power. I just created a centrifugal fan family for a customer that was manufacturer-specific and could be used within any of those systems, i.e. return, supply and exhaust systems. To meet the Seek standard, I would have to add three shared parameters for fan power, each with the same value reflecting the same product data.
With generic content we have the same situation. While the default content in Revit MEP 2012 shows some content split per system, it also has content that is system agnostic, e.g. Centrifugal Fan – Inline – Direct Drive, Centrifugal Fan – Inline – Belt Drive. The Seek standard tries to codify, within the shared parameter name, the system where the parameter is being used, but having to enter three shared parameters that will hold the exact same information is a waste of time, prone to errors, and, if formulas are used to keep the parameters identical, can even affect performance within a project.
Then there is the issue of deciding the proper units for shared parameters. Seek’s standard defines Supply Fan Motor Speed as a NUMBER. This parameter will accept as a value any unitless real number, measuring Revolutions Per Minute (RPM). Recently, another standard called ANZRS was published to address content standards for Australia and New Zealand. That standard doesn’t have a shared parameter named Motor Speed or anything similar, but it does have RPM_ANZRS. RPM_ANZRS, however, is defined as an INTEGER. If we are going to be meticulous from an engineering standpoint, the choice of INTEGER as the DATACATEGORY for the parameter is wrong.
Ignoring for a moment the engineering side of the issue, Revit throws a spanner in here. Let’s say you download a manufacturer’s family that follows the Seek standard. You’ve just cut a couple hours time from the process of adding such an item to your library. Now you edit the family and try to substitute its Supply Fan Motor Speed parameter with the RPM_ANZRS parameter. Revit won’t let you.
This could be handled by Revit easily enough if the parameter weren’t to be used in any other formulas within the family, but even then there is a chance that the parameter could already be in use within project schedules or calculations. And while you could argue that Revit should more gracefully handle the substitution of one unitless parameter for another, that still wouldn’t help in certain cases, say where one standard sets a given parameter as a LENGTH while another sets it as TEXT.
These examples are just the tip of the iceberg when it comes to issues with standardizing shared parameters, and my critiques are by no means meant to condemn or discount the efforts being made by Autodesk and other groups, such as the ANZRS. These initiatives are essential and progress is being made. I myself will be participating in the AEC Standards Committee a couple weeks from now, where Revit family standards and shared parameters will be discussed.
My aim here is to dig into the complexities involved in this endeavor, and to encourage an active and open discussion about the usability and long-term implications of proposed standards. Without this kind of consistent public examination and feedback, I believe we run the risk of getting ahead of ourselves and adopting standards that could prove more of a burden than a boon for Revit users. I plan to continue writing on the subject of standards in the weeks and months ahead, and in my next post I’ll look at Revit’s interface for shared parameters and how it has affected naming conventions to the detriment of long-term usability.
