Authoring tools and open standards

Models are created in authoring software, reviewed in coordination software and exchanged between dozens of firms, each using its own tools. A structural engineer may model in one product, the steel detailer in another, the mechanical contractor in a third, and the owner's facility management system may use none of them. This lesson looks at the families of authoring tools a construction manager will meet and, more importantly, at the open standards that let information move between them: IFC, BCF, IDS, COBie and the openBIM principles behind them. The aim is not to teach any product, but to understand what can and cannot be exchanged reliably, and how to write requirements that survive the trip.

Families of authoring tools

Authoring tools fall into a few broad families. Architectural and multidisciplinary building modelers create walls, floors, roofs, rooms and building systems with parametric families. Structural modeling and detailing tools model steel connections, reinforcing and precast elements to fabrication level. MEP fabrication tools model ductwork, piping and electrical containment using manufacturers' content and can output cutting lists and spool drawings. Civil and infrastructure tools model terrain, corridors, alignments and utilities. Each family has several competing products, and many firms use more than one.

Native file formats are the proprietary formats each tool saves in. They carry the full intelligence of the model, including parametric relationships and constraints, but they generally open only in the same product (and sometimes only in the same or newer version). A construction manager should never assume that a model can be opened, let alone edited, by another party without checking software and versions in the BIM execution plan.

Why open standards matter

Openness matters for three reasons. First, project teams change: the designer, contractor and owner rarely use the same software, and an owner may keep a building for decades after the authoring product has changed or disappeared. Second, competition: an owner that accepts only one vendor's files locks itself and its contractors into that vendor. Third, archiving: a public owner that must retain records for many years needs formats that will still be readable.

The international body for open BIM standards is buildingSMART International, a not-for-profit organization with national chapters, including buildingSMART Canada and buildingSMART USA. Its approach, called openBIM, rests on a few principles: interoperability is key to digital transformation; open and neutral standards should be developed to support it; reliable data exchanges depend on independent quality benchmarks; collaboration workflows are enhanced by open and agile data formats; flexibility of choice of technology creates more value for all stakeholders; and sustainability is safeguarded by long-term interoperable data standards.

IFC: Industry Foundation Classes

Industry Foundation Classes (IFC) is the open, vendor-neutral data schema for exchanging building and infrastructure information. It defines entities (such as IfcWall, IfcDoor, IfcBeam, IfcSpace and IfcDuctSegment), their properties and their relationships, and it can be written in several file encodings, the most common being the text-based STEP format with the extension .ifc. IFC 4.3, which extends the schema to infrastructure such as roads, railways, bridges and ports, was approved by buildingSMART and published by ISO as ISO 16739-1:2024.

An IFC file contains not just geometry but a spatial structure (project, site, building, story, space), element types, property sets and quantity sets. Property sets beginning with Pset_ are standardized by buildingSMART; for example, Pset_DoorCommon includes FireRating, IsExternal and AcousticRating. Quantity sets beginning with Qto_ hold measured quantities such as length, area and volume. Projects can add their own property sets for owner-specific data.

IFC is powerful but imperfect. Exports depend on how well the authoring tool maps its internal objects to IFC classes and on the export settings chosen. A common failure is a model in which everything exports as IfcBuildingElementProxy, a generic class, because modelers used the wrong categories. Another is geometry exported correctly but with properties missing. IFC is excellent for coordination, quantities and handover, but round-tripping (exporting, editing in another tool and importing back with full parametric behavior) remains limited.

IFC certification by buildingSMART tests whether software imports and exports particular exchange requirements correctly. Asking which IFC version and which model view definitions a product is certified for is a sensible question during procurement. A model view definition (MVD) is a subset of the IFC schema for a particular purpose; the most widely used for IFC 4 is the Reference View, intended for coordination and viewing rather than editing.

BCF: BIM Collaboration Format

Coordination produces issues: a clash, a missing opening, a question about a detail. Emailing screenshots loses the context. The BIM Collaboration Format (BCF), also from buildingSMART, packages an issue as a small file or an online record containing a title, description, status, assignee, due date, comments, a camera viewpoint and the identifiers (GUIDs) of the elements involved. Anyone opening the issue in a BCF-capable tool is taken to the same view with the same elements selected, regardless of which software created the issue.

BCF can be exchanged as files (.bcfzip) or through a web service API that synchronizes issues between platforms. Using BCF lets a design team keep working in its own authoring software while the contractor manages coordination in a separate tool, without losing track of who must do what.

IDS: Information Delivery Specification

Requirements written in prose ("all doors shall have a fire rating") are hard to check automatically. The Information Delivery Specification (IDS), a buildingSMART standard approved in 2024, expresses information requirements in a machine-readable XML format. An IDS file states, for example, that every IfcDoor on a project must have Pset_DoorCommon.FireRating with a value from a list, or that every IfcSpace must have a name matching a pattern. Checking software can then test an IFC model against the IDS and report which elements fail.

COBie: data for operations

Construction Operations Building information exchange (COBie) is a structured format for delivering the asset information a facility manager needs: spaces, zones, equipment types and components, systems, spare parts, warranties, documents and maintenance jobs. It was developed for U.S. federal owners and is now included in the National BIM Standard–United States; it is also used in Canada, the United Kingdom and elsewhere. COBie can be delivered as an IFC file or, more commonly, as a spreadsheet with standard worksheets.

COBie is simple in principle but laborious in practice. Most of the data, such as serial numbers, installation dates and warranty start dates, exist only after installation and must be collected in the field. Projects that leave COBie to the last month before handover usually deliver it late and incomplete. Lesson 7 shows how field apps can capture this information as equipment is installed and commissioned.

Other exchange formats

Several other formats appear on construction projects. LandXML carries civil data such as surfaces and alignments, and is still widely used for machine control (CON-250). gbXML carries building geometry for energy analysis. Point clouds use formats such as E57 (an open ASTM standard) and LAS. PDF remains the legal document of record on most projects, so models and drawings must be kept consistent. Proprietary formats from the major vendors are often exchanged directly when all parties use the same tool, which is convenient but creates dependence.

Writing software and exchange requirements

Interoperability problems are cheapest to solve before the project starts. The BIM execution plan (Lesson 4) should list, for each party, the authoring software and version, the formats to be exchanged, the IFC version and export settings, the property sets required, the coordinate system and origin, and the frequency of exchange. A short test exchange at the start, in which each party exports a sample model and the coordinator federates and checks it, catches most problems before they affect real work.

Finally, the construction manager should remember that open standards are tools, not guarantees. A perfectly valid IFC file can still contain wrong information. Exchange standards make checking possible; people still have to do the checking.