Parameter Namimg
Parameter names are the headings of data fields. They define the data type.
If you have a window object in a BIM, there may be data associated with the object for the manufacturer, U value and G value of the glazing. Each of these items will have data values, but the data will also have a reference or a parameter name.
It's the naming of these parameters that generally varies widely both between different BIMs but also within the same BIM.
BIM as a Database
In most relational databases the data is arranged in a consistent and formal way. This happens because a database will be constructed for a specific reason and arranged with a defined structure.
Model data is also often based on relational databases. However, they are also designed to include inherent flexibility. This means that where you have an object within a BIM, the parameters for an object are defined by the author of the object. There is guidance in the way of predefined parameters, in an attempt to provide consistency, but it's just guidance.
Interestingly, IFC (the open file format) is just a text file, albeit a very large text file. Although, when added to applications it's often converted to a database to enable any sort of usability.
IFC is just a text file
An object may have as many parameters as required. The parameters naming can also take any name (although, duplicate names within the same object are not permitted). This results in inconsistent and varied methods for parameter naming.
Property Sets
The good news is that the open nature of object parameters allows for flexibility. So that an object may have parameters consistent with multiple schemas, such as COBie, IFC, Property Sets, bsDD (Building Smart Data Dictionary), project specific requirements, Uniclass coding and NRM coding.
I have until recently generally used COBie fields to enable consistent parameter naming. An example would be the parameter name for a manufacturer, using COBie the parameter name would be COBie.Type.Manufacturer. But, this is reinventing the wheel as COBie parameters have an established mapping schema from IFC and so requires an updated method.
We have now moved over to using the parameter naming (and GUIDs) as detailed within the standard IFC property sets (Psets) and the extended property sets as provided through the bsDD (Building Smart Data Dictionary).
Pset - a standard IFC property set
When it comes to COBie not all COBie parameters are directly mapped to existing IFC parameters. Some require new property sets to be defined within your IFC file. For example, COBie requires an IFC property set (IfcPropertySet) named COBie_Specification for many of the COBie.Type specification fields such as 'finish'. The full scheme mapping between IFC and COBie is available to view within the 2013 COBie Responsibility spreadsheet. It can be downloaded from the National Institue of Building Sciences (you'll find it about 3/4 of the way down the page).
IFC Psets (Property Sets)
IFC property sets or Psets provide a standard set of parameters for a standard set of object types. Standard object types include doors, walls and windows. The property set for a door (Pset_DoorCommon) includes:
- fire rating
- acoustic rating
- security rating
- glazing area
Additional parameters can also be provided. But these would not be defined within the standard set and so would not necessarily be compatible with other applications without explicitly defining and mapping the data.
Extended Property Sets
The Pset parameters are available through bsDD.
The dictionary contains a comprehensive list of parameters, which has widespread international support for consistent parameter naming. If a parameter is not detailed within the bsDD, then the next point of reference is BIMHawk. Where available BIMHawk links to the bsDD but also contains a full set of MEP asset parameters.
bsDD provides a library of the available standard property sets
The idea behind bsDD is to have global consistency over the use of parameters. This uses a consistent GUID for a parameter type, allowing for different languages and different local conventions. But knowing that a door opening width in the US means the same thing as a door width in France. The underlying GUID for the door width will be the same but this allows the naming to be different and specific to suit local needs.
The Foundations for Consistent & Structured Data
Along with the consistent use of classification codes, consistent parameter naming provides the foundations for models with structured data. Structured and consistent data within models will enable a wide range of future opportunities, such as digital design briefs, reliable model quality checks and most importantly the effective use of building data during the life of a facility.
Consistent and structured data will unlock the possibilities of BIM
Set the foundations in place now for structured data by developing your own requirements, establish your organisational information requirements.
Contents