Further to my post about Universal Shared Parameters, we were questioned about why we needed such very structured data in our authoring environment. Why couldn’t we use the limited IFC properties available for our parameter names, or make do with IFC parameters that have TEXT or LABEL datatypes, or indeed use the Shared Parameters provided by National BIM Library. The answer is that if you want to unlock the true power of the data in BIM, the data has to be much better structured than those schemas accommodate.
Example 1 – IFC4 properties
Here is an example of how IFC4 handles Reaction to Fire (Surface Spread of Flame):
This entire definition consists of a property name, a data type, and a description (in several languages). The crudeness of referring to a nebulous ‘national building code’ is a good example of a bad starting point.
- Do we use BS or EN values?
- EN values are in 3 parts: class, smoke, droplets. How are they handled?
- Is this a limiting value, if so a max or a min?
- Is this a manufacturer’s value? How does it relate to the limiting value?
- Is this value certified, if so by which body?
It’s clear that if you really want to document Reaction to Fire of an element, you’re going to need a bunch of parameters, OR maybe fewer parameters from a schema that declares these criteria. Neither IFC nor NBL parameters are fit for this purpose.
Example 2 – Custom Shared Parameters
Here is an example of what you can do in an authoring environment (Revit in our case) with custom Shared Parameters (hopefully your browser allows you to enlarge this image, if not click here). This is a live schedule from Revit with no manual manipulation:
This time we’re looking at properties of a drywall partition – fire, acoustic, height limit, service duty. Observe that all numeric data is of a datatype that means they are functional, rather than text values. Data like this can be used in schedules with conditional formatting, target-actual checking, calculation formulas etc, and can be fed into programming environments such as Dynamo. None of this could happen if we used IFC properties and datatypes.
The example partition schedule includes our ‘design’ fire resistance rating for partitions, set at Stage 3 when establishing the Fire Strategy. This data needs to live on through the life of the project, so that Fire Strategy drawings continue to show the correct limiting values. At Stage 4, when subcontractor’s proposals are available for proprietary partition systems, the manufacturer’s data is added to the partition types as ‘actual’ values, using separate parameters. Our partition schedule checks for compliance automatically using a checking formula, presenting a tick or a cross to show compliance, and even flags non compliance by red-shading the offending cell – all automatically using Revit’s conditional formatting feature. We do the same for sound insulation and duty rating. What we CAN’T do is compare the height limit of the partition against the actual heights, because Revit can’t report actual wall height (still not fixed in 2018!).
We can do the same things with our fire plans as we do with our schedules. Revit’s filters allow us to automatically produce fire plans based on the data the walls contain, not just with matching text strings but using greater-than-or-equal-to values, and of course we can also flag non-compliance by making walls appear bright red.
None of this data crunching can be done without custom parameters. Neither IFC properties nor NBL parameters are suitable for this purpose. What the industry needs is a functional set of Universal Shared Parameters.
Join the conversation below or on Twitter @pumphousebim
Chris Dixon is an architect and BIM manager for Franklin Ellis Architects