A Specification is designed to be easy for humans to understand. However, Specifications are also highly structured so that computer software may automatically and accurately check information requirements with no ambiguity. Every Specification has three main parts:
- Description: a description of the rationale for the Specification and instructions of how to achieve it. This part is designed for humans to read and understand why information is being requested.
This field is also used to describe the rationale for the various applicability facets, and how they serve to identify the relevant data contracts on an asset as a whole, rather than individually. Conversely, the description data on each requirement facet should help the user understand the purpose of the individual piece of information required.
- Applicability: Identifies the subset of the model that we are intending to specify. There are many different types of objects in IFC models, but each Specification only applies to a subset. The subset can be identified via the available facets like entity (e.g. walls, windows), classification (e.g. Uniclass EF_25_10_25 External walls), and others.
- Requirements: what information is required for subset identified in the applicability, such as required properties or materials.
For example, the Specification of "all walls must have a fire rating property" is structured like so:
- Description: wall fire ratings are critical for building code compliance
- Applicability: this specification applies to all wall objects
- Requirements: the aforementioned wall objects must have a fire rating property
Applicability and Requirements are described using a collection Facets. A Facet describes information that a single entity (e.g. wall, door, etc) in your model may have. A Facet describes its information precisely using fixed Facet Parameters so that computers can understand exactly what information you are after.
When a Facet is used in the Applicability section, it describes the information that we use to identify the relevant parts of the model.
When a Facet is used in the Requirements section, it describes the information constraints that the model parts must fulfill to comply with the Specification.
There are six different Facets of information:
| Facet Type | Facet Parameters | Example applicability | Example requirement |
|---|---|---|---|
| Entity | IFC Class and Predefined Type | Applies to "IfcWall" with predefined type of "SHEAR" | Must be an "IfcWall" with a predefined type of "SHEAR" |
| Attribute | Name and Value | Applies to elements with the attribute "Name" having the value "W01" | Must have the attribute "Name" with the value "W01" |
| Classification | System and Value | Applies to elements classified under "Uniclass 2015" as "EF_25_10_25" | Must have a "Uniclass 2015" classification reference of "EF_25_10_25" |
| Property | Property Set, Name, and Value | Applies to elements with a property set of "Pset_WallCommon" with a "LoadBearing" property set to "TRUE" | Must have a "Pset_WallCommon" property set with a "LoadBearing" property set to "TRUE" |
| Material | Value | Applies to "concrete" elements | Must have a "concrete" material |
| Parts | Entity and Relationship | Applies to elements that are "contained in" an "IfcSpace" | Must be "contained in" an "IfcSpace" |
You can combine multiple Facets together in either the Applicability or Requirements section to describe a wide variety of Specifications. Some Facets may have optional Facet Parameters. For example, if you want to specify that a property should exist, but not the exact value, you may omit the value parameter of the Property Facet.
You may also specify a list of valid values, or a range of numbers, or text pattern for some Facet Parameters. These are known as Complex Restrictions. For example, you would use a Complex Restriction to specify that a fire rating property must choose from either the value "0HR", "1HR", or "2HR" only.
Here are a few examples to wet your appetite:
| Intent | Applicability | Requirements |
|---|---|---|
| External load bearing walls need to have a fire rating property for code compliance |
|
|
| Bedrooms should have a minimum area of 10m2 |
|
|
| All brick wall types must be classified and follow the approved naming convention |
|
|
To see the full capabilities of what each information each Facet can specify, see the sections below for more detail.
Each Specification defines that a subset of the model matching the applicability criteria is Required, Optional, or Prohibited. Given an example like the following:
applicability = Type = walls
Property = IsExternal
requirement = Property = FireRatingthe following interpretation applies:
| minOccurs | maxOccurs | Interpretation | Meaning |
|---|---|---|---|
| 1 | unbounded | required | At least one wall with the IsExternal property must be found in the IFC model, each such wall must have the fire rating property |
| 0 | unbounded | optional | Walls with IsExternal property are optional in the model, if any such wall is present, they must all have fire rating property |
| 0 | 0 | prohibited | No wall with IsExternal property should be found in the model, requirements are ignored in the verification of models |
Individual requirement facets may also specify whether they are Required, Optional, or Prohibited.
Given the example like the following property:
Requirement 1: Property
propetySet: ePset_SpaceOMA
property: TravelDirection
datatype: IFCLABELthe following interpretation applies:
| Type | Meaning | Success criteria |
|---|---|---|
| required | A matching property is required in the model | Matching entities have a ePset_SpaceOMA/TravelDirection property of type IFCLABEL and non null value |
| prohibited | A matching property cannot be present in the model | Matching entities don't have a property TravelDirection in the ePset_SpaceOMA property set |
| optional | Expectations of a propertySet/property and value constrains are defined, but optional | Matching entities either don't have the property, or if they do, it is of the expected datatype and value |
As a complete example, you might have a Required specification that applies to wall entities, that are Prohibited from being load-bearing, if you wanted your model to not contain any load-bearing walls.
Each Specification defines the IFC schema(s) that it applies to. The supported IFC schemas are:
- IFC4X3_ADD2
- IFC4
- IFC2X3
IDS assumes that the provided IFC model only contains valid data. If the model has syntax errors or IFC schema validation errors, then the model may not be able to be verified. It is the responsibility of the IFC authoring software to ensure that the produced IFCs are valid.
The first version of IDS targets basic information and relationships in IFC that are common to all disciplines. More advanced information requirements are currently out of scope for IDS. For example, geometry checks, checks that rely on calculated or dynamic values, checks that reference data outside the IFC model, or use domain specific IFC relationships are not possible.
Here are some types of advanced requirements that you will need other tools to help audit:
- There must be no clashes between structural beams and pipes
- All walls need to be 3m away from the site boundary
- The total area of all office spaces must be more than 300m2
- The names of all door types must be unique
- All pumps need to have a nominated supplier and manufacturer
- All air handling units must have sensors assigned with trigger events
- Saturday and sunday must be a holiday in all work schedules
- All models shall load in under 3 minutes by major software vendors
- Associated drawings in the model must match the latest revisions in the CDE
- All rebar should be modeled as parametric swept disks
- The model must match the as-built state of construction