The OpenBIM Pledge

The OpenBIM pledge is a no-nonsense, step-by-step practical strategy to raise adoption of international, open data standards based BIM. If all companies agree to incrementally implement these principles, we can move towards standardised data across the world, and a strong foundation to build all digital processes, workflows, and future visions of our built environment.

This pledge is inspired by the pledge signed by browser vendors who stopped fighting and instead worked together to implement standards-compliant web technologies. This is a technical document, aimed at a technical audience of digital engineers. It's intended to be signed by the lead / head of digital engineering for a project, department, region, company, or government department. Signing this document is entirely voluntary. That said, you'd assume anybody who is a buildingSMART member is probably at least tier 1.

This is a draft. I did a braindump at 1am without holding back and haven't digested anything. Please braindump your own ideas by editing this page and we can collectively polish this.

The following tiers are aimed at both those requesting and providing BIM.

Tier 0

This is basically the participation trophy. It's better than nothing.

• I solemnly swear to require "IFC" (as vague as that is) as part of a deliverable. I will actually check that I've received something, and at least open it to make sure it contains information relevant to the project.

Signatories: your company here?

Tier 1

• I will require and check for a specific IFC schema version (IFC2X3, IFC4, IFC4X3), acknowledging practical differences between IFC versions.
• If I require properties attached to objects, I will specify and check for a property name, property set name and IFC data type (e.g. IfcLabel, IfcIdentifier, IfcPositiveLengthMeasure) of the data.
• I will not penalise any stakeholder from using any software they want, giving them freedom of using the best tool for the job, so long as OpenBIM deliverables are provided.
• If an IFC is not delivered, I will withold payment if it is within my power to do so.

Signatories: your company here?

Tier 2

• All IfcProduct and IfcTypeProducts must be assigned to the correct IFC class. This means that regardless of people's favourite classification flavour of the day, there is a fallback "broad" classification that anybody can use for any process. This does not stop you from using additional classifications on top of IFC's built-in classes. This is also the first step in order to use any sort of standardised property or quantity.
• If I require properties or quantities that already exist as part of a buildingSMART standardised template (i.e. those prefixed with Pset or Qto), I will use that instead of reinventing my own.
• I will specify the applicable IFC class for all properties that I require. This ensures people understand which objects need which properties, and it can be automatically checked.
• I will provide an IDS for simple property requirements so that audits are standardised and there are no ambiguities or nasty surprises.
• I will validate IFCs and report validation bugs to software vendors. This provides a reliable technical foundation that we can build systems upon.

Signatories: your company here?

Tier 3

• If I require anything to be georeferenced, I will require at least IFC4, and correctly implement IfcProjectedCRS and IfcMapConversion following the best practices of the buildingSMART user guide to georeferencing for vertical and horizontal projects. This is the first step to federating across models, GIS environments, and infra projects of the future.
• If anything is named in documentation (drawing, schedule, specification, etc), that name must be stored in the Name attribute (not a property!) of the relevant IfcTypeProduct and/or IfcProduct and/or IfcSpatialElement. This ensures that documentation at least correlates to BIM data (otherwise everything else becomes almost meaningless).
• If any name is not self-explanatory (e.g. a coded naming or numbering system), then a Description attribute (not a property!) must be provided of all IfcTypeProduct and/or IfcProduct and/or IfcSpatialElement (LongName instead of Description). Descriptions should be sufficient so that those reading a schedule of my objects can understand what the object is without visually looking at a 3D model. This provides a strong foundation to any non-graphical scheduling or query.
• If I require an external classification system, it must be stored as a classification reference in an IfcClassification, not as a property. This means that filtering of classifiations can actually benefit from understanding the hierarchical nature of classifications.
• All physical products must additionally have a predefined type assigned. If any user defined values are used, it must be documented and audited. The rules of inheritance and override of predefined types must be followed. This leads to a more granular option of an international classification.
• If the project documentation or asset strategy refers to types of objects (e.g. wall types, beam types, pit types, pipe types, equipment types, etc) then IfcTypeProduct must be used to reflect this with the appropriate type relationship to occurrences. For example, if there are 10 documented door types, there must be exactly 10 IfcDoorType objects.
• I will use object types and occurrences effectively using their ability to inherit properties and classifications. I will not explicitly require properties on every single occurrence. This prevents obscene duplication of data where data can be intelligently inherited.
• I will blacklist properties that are not explicitly required or part of the execution plan. This will prevent high quality, audited properties from being mixed in with untrustworthy, misleading "garbage" properties that create the risk of "garbage in, garbage out".
• I will specify the "Category" attribute for all IfcMaterials, using only one of the keywords listed in the IFC documentation. This allows you to identify basic things consistently like "concrete objects" or "steel objects" at a high level.
• If I want quantity data, it must be stored as a quantity set, not as a property. This allows us to separate calculable or geometry-derived data from semantic data so we can recalculate and check quantities and later connect parametrically to costs.

Signatories: your company here?

Tier 4

• I will audit and guarantee that the spatial hierarchy reflects all documentation. This ensures that all documented rooms, storeys, spaces, buildings, infrastructure corridors, etc are also available for analysis in the model. Spatial breakdowns have many usecases and this is a required first step to any sort of spatial-based analysis.
• I will audit and guarantee that all products are contained in the correct spatial element in the spatial hierarchy. This will ensure that any spatial division or filtering can be reliably performed in the model. This is critical for any sort of cost / carbon / facility management quantification or further auditing breakdown (phasing, clash detection, etc).
• If I require information about the system that a product is part of, I will use IfcSystem classes appropriately, instead of storing this information in a property set. This is the first step to semantically storing useful system connectivity.
• If I have my own invented classifications, properties, or materials, I will submit and maintain a register of the in the bSDD. This allows tools to integrate with my data schemas in a standardised manner.
• If I require COBie 2.4 or COBie 3.0, it must be extracted from the IFC in compliance with the COBie mapping table and COBie IFC class lists, not delivered as a separate spreadsheet. This ensures that IFCs are consistent with facility management data.
• I will not request spreadsheets of information where all that information is stored in the IFC. Instead, I will audit data in IFC directly. This prevents duplication of data, ensures a single source of truth, and does not downgrade smart semantic data to dumb tabular form. You can of course later on generate tabular datasets, but it must not be a primary deliverable.
• I will specify all geometric LOD and clash detection priorities / rules in terms of data in IFC (e.g. IFC classes and predefined types, or IFC classifications) similar to the filter facets available in IDS. This means that geometric reliability and tolerance can be analysed in a standardised manner.
• I will not require any properties that can be derived from counting classes (e.g. total building storeys). This removes duplication of data and possibility of mistakes.
• I will not require any properties on an occurrence (e.g. room number) that can instead by stored on the relating container (e.g. space, storey, etc) or relating system (e.g. distribution system, circuit) or relating material. This removes duplication of data and is a good first step away from dumb properties and towards intelligent, related semantic objects.

Tier 5

At this tier onwards, it is acknowledged that this is only achievable by experts and advanced users in OpenBIM. This is the bridging point between using IFC in a superficial or secondary manner, towards truly using IFC as the primary data schema for the built environment.

• I will provide any structural analytical models in IFC, using IfcStructuralAnalysisModel. The quality may vary at this tier.
• If I require a cost breakdown structure, I will provide it in IFC, using IfcCostItem and IfcCostValue. The quality may vary at this tier.
• If I require a work breakdown structure, I will provide it in IFC, using IfcWorkPlan, IfcWorkSchedule, IfcWorkCalendar, and IfcTask. The quality may vary at this tier.
• All documentation forming a deliverable will be provided in IFC using IfcDocumentInformation.
• All standardised steel profiles will come from an IFC library managed by my local buildingSMART chapter ideally including critical structural, quantification, and environmental data. This library must at a minimum include standardised names. This ensures highly standardised primary building components can be identified explicitly, and encourages sharing of industry standards.
• I will not require any property that can be derived through traversing port connectivity of system elements. This ensures that systems are not just geometry, but start to represent connected topologies.

... more to come.

Signatories: your company here?

Tier 6

• Smart building schemas such as Brickschema must correlate with (or be derived from) IFC. By ensuring design and construction datasets align with operational datasets, this is the first step towards connecting to smart building sensors, IfcEvent, IfcProcedure, etc.
• If requested on the project, I will be able to provide BACNet object identifiers and Brickschema URIs, referenced using IfcLibraryReference as a first step towards connecting live sensor data and building telemetry for building management.
• I will represent geometry of coverings, walls, slabs, beams, members, and columns using standard case material layer sets and profile sets if applicable to the design phase and geometric nature of the object. This is the first step towards allowing parametric modification and continuous updating of the IFC dataset during the project and building lifecycle.
• If EPDs are used on the project, all EPDs must be related using IfcDocumentReference, and correlate with the unit environmental impact values such that if multiplied by the unit quantity in the IfcElementQuantity, the total environmental impact can be derived.
• All project milestones must be reflected in IfcTask with correct scheduled dates.
• All IfcProducts with geometric representations must be assigned to an IfcTask as either an input or an output.
• Non-geometric IfcProducts must be created and assigned to IfcTask if they have a significant impact on duration.
• Construction resources must be identified using IfcConstructionResource. Quality may vary at this tier.
• The system type of all ports must be correctly identified. This is the first step in allowing for users to determine correct port connectivity and do optioneering.
• The directionality of port connectivity must be correct and represent the distribution flow of systems. This allows the ability to do automated upstream and downstream impacts when systems fail or know what is serviced by other systems.
• Circuits must be represented using IfcDistributionCircuit.

Signatories: your company here?

... more to come.

Note: as tiers increase, further elaborate on the data relationships in IFC that have the biggest cost, time, carbon impacts. Highlight the biggest capabilities of working with IFC that allow for real time logistical tracking, visualisation, and data exchange.