Universal Shared Parameters

This post began not so much as a blog piece, but more a means of contributing to a discussion that isn’t limited to 140 character chunks…. (fix it Twitter!). I’m happy to be corrected / contradicted using the comments section, or back over on Twitter @pumphousebim

There is currently a healthy discussion on Twitter about the best way to resolve the ‘Shared Parameter Problem’. Although this is Revit terminology (and I will largely use Revit terminology throughout this post), this is part of a broader BIM discussion.

The problem is this – there is no universal list of Shared Parameters for the construction industry, either in the UK or worldwide. People may try and tell you otherwise, usually people who aren’t day-to-day Revit users – believing that COBie or IFC or National BIM Library (NBL – a UK body) offer a solution to this. They don’t.

This matters because – without Universal Shared Parameters, BIM in Revit doesn’t work very well. Conflicting lists of Shared Parameters, used by conflicting object publishers, cause massive problems for users and BIM Managers, problems which are passed on to Contractors, Subcontractors and Clients

Some of the problems this causes:

1. Shared Parameter names get repeated by different publishers. Although Revit uses GUID* to track these, the GUID is not exposed in the Revit user interface (UI). An object might therefore have the same parameter name several times, with no way for a user to know which one to use from the Properties Palette .
*GUID is “Globally Unique Identifier”

2. GUID is not exposed in the Revit UI when creating (or templating) Schedules either. That shiny readymade Door Schedule your BIM Manager provided in your standard project template won’t work with door objects from different publishers, even if it looks like the Shared Parameter has ‘exactly’ the same name.

3. Revit can’t map Shared Parameters to Units. Parameter units are also not exposed to the user in the Properties Palette of the Revit UI. (These are both software deficiencies that only Autodesk can fix.) Shared Parameter publishers usually publish their units, but once the SP is loaded into Revit, this information is lost* . Without knowing the publisher of a Shared Parameter, users have no way of looking up the units (without resorting to tracking the GUID). Are your Acoustic Rating units Rw or DnT,w + Ctr ? Who knows. Revit doesn’t.
*The units can be added as metadata to the tooltip, but this requires manually editing a Shared Parameter file in a text editor, plus there is no way of getting this unit data into a schedule or mapping it during data export anyway.

Why don’t NBL Parameters work:

1. They aren’t prefixed.
Once loaded into a project with mixed data sources (e.g. NBL, BIMstore, BIMobject, Manufacturer’s objects etc) the Shared Parameter names that come from NBL can’t be identified within the Revit UI. NBL suggest everybody use their SPs, which would solve the problem, but this is the real world, and even if achievable in the long term, it would take years to transition. Any Universal Shared Parameter system has to be prefixed to show the source.

2. They aren’t extensive enough
To be fair to NBL, they’ve made a pretty good job of this. They made Product Data Templates, for hundreds of building elements, then added Shared Parameters to cover the attributes of each of those products. No system can contain all the SPs required by users though, and any Universal Shared Parameter system has to be extendable rapidly and openly (like openRFA – see below)

3. They use incorrect Datatypes
Revit Shared Parameters can’t contain units (see next bullet). You’re limited to the predefined ‘datatypes’ that are built into Revit and those don’t even include acoustics, fire, or other important attributes. Importantly though, when you create Shared Parameters, you need to choose the most appropriate datatypes from those available, but NBL haven’t. Fire Rating uses the Datatype TEXT for instance, instead of NUMBER. If you use NUMBER, it is proper BIM data, not dumb text, and users can use a checking formula in a partition schedule or door schedule, if they know the units (minutes or hours). Actual units (minutes or hours) can be declared in the Tooltips (see below) to avoid ambiguity. Any Universal Shared Parameter system should use appropriate datatypes and avoid the TEXT datatype wherever possible.

4. They don’t declare Units
Revit doesn’t expose units in the UI, and Shared Parameters can’t be linked to Units (only limited datatypes). The Units issue is compounded too, because the entire world uses SI Units…. except for one country, that being the US. Now you might think Revit knows whether a project is SI Metric or Imperial, but it doesn’t. Units in Revit are changed from Imperial to Metric individually, and trans-Atlantic projects are fraught with danger if Units are not exposed in the UI. Any Universal Shared Parameter system has to declare Units, either in the parameter name or in the tooltip.
Where an Imperial unit is required that doesn’t use a standard base unit (such as length) it is best to create a duplicate parameter entirely. NBL as a UK body doesn’t need to cater for non-SI units.

5. They don’t use Tooltips
Most Shared Parameter names are quite opaque to users, they use CamelCase, are often not sufficiently descriptive, and usually don’t include units in the name. Most of this can be overcome by using the Description column that lives in the Shared Parameters file – and is exposed to users as Tooltips in the UI. Here you can give a plain English description, declare SI units, give BS/EN/ISO references to which the properties are measured, and declare limiting values. NBL have done NONE of this. Any Universal Shared Parameter system has to use Descriptions/Tooltips.

6. They don’t use Parameter ‘value states’
Best illustrated with an example: The ‘Fire Rating’ of a partition isn’t a static value. For building regulations compliance we might declare a ‘Design’ value for this, such as 30 minutes, but for acoustic reasons, the partition we select might provide an ‘Actual’ value of 60 minutes fire resistance. At handover, the client’s FM team will just get a Fire Rating value in the model, without knowing if that is a requirement or just what happens to have been provided. This ambiguity is a big problem if they make amendments to the partition in future. This is a problem with COBie and IFC too. Revit supports phasing, but is doesn’t support value ‘states’ for object properties. As a solution, any Universal Shared Parameter system has to implement value states, by providing ‘Design’ and ‘Actual’ versions* of each relevant parameter.
*The actual terminology of a parameter value state doesn’t need to be fixed, it could be _Target, or _Limit, or _Measured etc as appropriate for an object property.

7. They don’t give BS/EN/ISO/ANSI references
Parameter values largely rely on a benchmark to which they are measured. Fire resistance of an element (in minutes) is not complete data until referenced to the standard by which its fire resistance is measured. Just like parameter standards, there are a lot of fire resistance standards in the world, so this can’t just be assumed. Revit can’t record this, so it has to be added via the Tooltip. Any Universal Shared Parameter system has to give BS/EN/ISO/ANSI references in the Description field.

What about openRFA?

There is a fledgling initiative called openRFA, who are a self-appointed (but open to all) group of Revit MEP users, intent on creating a Universal Shared Parameter system for Revit. They’re Seattle-based but seem intent on engaging UK users, which is a positive step. Their aim is laudable, but their approach currently has some limitations:

• See 1-7 problems with NBL parameters above – most apply to openRFA
• OpenRFA are not approaching the task in a structured way. The ONLY way to create a Universal Shared Parameter system is to first make Product Data Templates (property sets), then list out the Parameters (properties) required for each product. There are lots of PDT initiatives, particularly in the UK. The two most important ones are CIBSE and NBL, which are currently incompatible, but alignment is promised. OpenRFA need to join forces
• Quality control is lacking. Parameters in the current published SP file are mostly incomplete, with very few having any form of Description.

What about AEC(UK)?

This UK body pledged to create a set of Universal Shared Parameters for Revit, but obviously baulked at the sheer size of the task.

What about IFC / COBie Parameters

Mapping on export is the correct solution. Revit parameter names need to work with the platform and its limitations, and directly using IFC or COBie property naming inside Revit is not appropriate.

What about your/my office Shared Parameter file?

Because of all the above problems we started writing our own PDTs for the core architectural elements (walls, doors, windows etc) and made our own Shared Parameters file. Every office has one, but this isn’t a sustainable solution. We do need a universal approach to Shared Parameters, but if it isn’t done right… we’ll just carry on using our own.

 

Join the conversation below or on Twitter @pumphousebim

Chris Dixon is an architect and BIM manager for Franklin Ellis Architects