This article relies excessively on references to primary sources. Please improve this article by adding secondary or tertiary sources. Find sources: "Industry Foundation Classes" – news · newspapers · books · scholar · JSTOR (March 2017) (Learn how and when to remove this template message)

The Industry Foundation Classes (IFC) is a CAD data exchange data schema intended for description of architectural, building and construction industry data.

It is a platform-neutral, open data schema specification that is not controlled by a single vendor or group of vendors. It is an object-based data schema with a data model developed by buildingSMART (formerly the International Alliance for Interoperability, IAI) to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used collaboration format in Building information modeling (BIM) based projects. The IFC model specification is open and available.[1] It is registered by ISO and is an official International Standard ISO 16739-1:2018.

Because of its focus on interoperability the Danish government in 2010 made the use of IFC format(s) compulsory for publicly aided building projects.[2] In 2017 the Finnish state-owned facility management company Senate Properties started to demand use of IFC compatible software and BIM in all their projects.[3] Also the Norwegian Government, Health and Defense client organisations require use of IFC BIM in all projects as well as many municipalities, private clients, contractors and designers have integrated IFC BIM in their business.[citation needed]. The popularity of the IFC data schema in construction has continued to grow, primarily for the purpose of exchanging geometry.

History

Main article: buildingSMART

The IFC initiative began in 1994, when Autodesk formed an industry consortium to advise the company on the development of a set of C++ classes that could support integrated application development. Twelve US companies joined the consortium. These companies included AT&T, HOK Architects, Honeywell, Carrier, Tishman and Butler Manufacturing.[4] Initially named the Industry Alliance for Interoperability, the Alliance opened membership to all interested parties in September, 1995 and changed its name in 1997 to the International Alliance for Interoperability. The new Alliance was reconstituted as a non-profit industry-led organization, with the goal of publishing the Industry Foundation Class (IFC) as a neutral AEC product model responding to the AEC building lifecycle. A further name change occurred in 2005, and the IFC specification is now developed and maintained by buildingSMART.

IFC Specifications

The following IFC Specification versions are available[5]

File Formats

IFC defines multiple file formats that may be used, supporting various encodings of the same underlying data.[7]

IFC-SPF is in ASCII format which, while human-readable, suffers from common ASCII file issues, in that file-sizes are bloated, files must be read sequentially from start to finish, mid-file extraction is not possible, files are slow to parse, and definitions are non-hierarchical.[8] In addition to ifcXML and ifcZIP, modern data formats include RDF/XML or Turtle (using the ifcOWL ontology), ifcJSON (JavaScript Object Notation, broadly available) and ifcHDF5 (Hierarchical Data Format v5, binary).[8] In 2020, buildingSmart had two JSON projects underway: ifcJSON v4 (a direct mapping from EXPRESS-based IFC v4) and ifcJSON v5, plus a research project experimenting with turning IFC into a binary format.[8]

Architecture

IFC defines an EXPRESS based entity-relationship model consisting of several hundred entities organized into an object-based inheritance hierarchy. Examples of entities include building elements such as IfcWall, geometry such as IfcExtrudedAreaSolid, and basic constructs such as IfcCartesianPoint.[9]

At the most abstract level, IFC divides all entities into rooted and non-rooted entities. Rooted entities derive from IfcRoot and have a concept of identity (having a GUID), along with attributes for name, description, and revision control. Non-rooted entities do not have identity and instances only exist if referenced from a rooted instance directly or indirectly. IfcRoot is subdivided into three abstract concepts: object definitions, relationships, and property sets:

IfcObjectDefinition

IfcObjectDefinition is split into object occurrences and object types. IfcObject captures object occurrences such as a product installation having serial number and physical placement. IfcTypeObject captures type definitions (or templates) such as a product type having a particular model number and common shape. Occurrences and types are further subdivided into six fundamental concepts: actors ("who"), controls ("why"), groups ("what"), products ("where"), processes ("when"), and resources ("how").

IfcRelationship

IfcRelationship captures relationships among objects. There are five fundamental relationship types: composition, assignment, connectivity, association, and definition.

IfcPropertyDefinition

IfcPropertyDefinition captures dynamically extensible property sets. A property set contains one or more properties which may be a single value (e.g. string, number, unit measurement), a bounded value (having minimum and maximum), an enumeration, a list of values, a table of values, or a data structure. While IFC defines several hundred property sets for specific types, custom property sets may be defined by application vendors or end users.

Products

IfcProduct is the base class for all physical objects and is subdivided into spatial elements, physical elements, structural analysis items, and other concepts. Products may have associated materials, shape representations, and placement in space. Spatial elements include IfcSite, IfcBuilding, IfcBuildingStorey, and IfcSpace. Physical building elements include IfcWall, IfcBeam, IfcDoor, IfcWindow, IfcStair, etc. Distribution elements (HVAC, electrical, plumbing) have a concept of ports where elements may have specific connections for various services, and connected together using cables, pipes, or ducts to form a system. Various connectivity relationships are used for building elements such as walls having openings filled by doors or windows.

Materials may be defined for products as a whole, or as layers, profiles, or constituents for specified parts.

Representations may be defined for explicit 3D shape, and optionally as parametric constraints. Each representation is identified by IfcShapeRepresentation with a well-known name.

Placement may indicate position, vertical angle, and horizontal angle.

Quantities may be defined for take-off purposes such as Gross Area, Gross Volume, Gross Weight, Net Weight, etc. IFC defines various quantities specific to each element type and the method of calculation according to geometry and relationships.

Processes

IfcProcess is the base class for processes and is subdivided into tasks, events, and procedures. Processes may have durations and be scheduled to occur at specific time periods. Processes may be sequenced such that a successor task may start after a predecessor task finishes, following the Critical Path Method. Processes may be nested into sub-processes for summary roll-up. Processes may be assigned to products indicating the output produced by the work performed.

Resources

IfcResource is the base class for resources and is subdivided into materials, labor, equipment, subcontracts, crews, and more. Resources may have various costs and calendars of availability. Resources may be nested into sub-resources for granular allocation. Resources may be assigned to processes indicating tasks performed on behalf of a resource.

Contexts

IfcProject encapsulates an overall project and indicates the project name, description, default units, currency, coordinate system, and other contextual information. A valid IFC file must always include exactly one IfcProject instance, from which all other objects relate directly or indirectly. A project may include multiple buildings, multiple participants, and/or multiple phases according to the particular use.

In addition to project-specific information, an IfcProject may also reference external projects from which shared definitions may be imported such as product types. Each external project is encapsulated using IfcProjectLibrary [IFC2x4] along with IfcRelAssociatesLibrary and IfcLibraryInformation to identify the particular revision of the imported project library.

Projects support revision control where any IfcRoot-based entity has a unique identifier and may be marked as added, modified, deleted, or having no change. Such capability allows multiple IFC files to be merged deterministically, ensuring data integrity without human intervention.

See also

References

  1. ^ a b "Industry Foundation Classes (IFC)". buildingSMART. Retrieved 2021-12-21.
  2. ^ "Digital client demands scheme", Archived from the original.
  3. ^ "Sivua ei löydy". Senaatti.fi. 2015-10-23. Archived from the original on 2012-02-26. Retrieved 2017-03-19.
  4. ^ Stephen Hamil (2012-07-02). "BIM, Construction and NBS: The End Of Babel - IFC promotional video". Constructioncode.blogspot.co.uk. Retrieved 2017-03-19.
  5. ^ "IFC Specifications Database". buildingSMART. Retrieved 2021-12-21.
  6. ^ "Welcome to". Buildingsmart-tech.org. Archived from the original on 2013-03-17. Retrieved 2017-03-19.
  7. ^ "IFC Formats". buildingSMART. Retrieved 2021-12-21.
  8. ^ a b c Grabowki, Ralf. "The Future of IFC: Enabling Partial BIM Model Exchange (June 8, 2020)". Upfront E-zine. Retrieved 8 June 2020.
  9. ^ "Start Page of IFC2x3 Final Documentation". Iai-tech.org. Archived from the original on 2011-03-24. Retrieved 2017-03-19.

External links

  1. Sharing Your Model with IFC: An Introduction for Vectorworks Architect
  2. ^ Bentley's IFC Position Paper Archived 2016-03-04 at the Wayback Machine
  3. ^ DDS IFC Certification IFC for DDS
  4. IFC File Analyzer software - Generate a spreadsheet from an IFC file
Building information modeling (BIM)
Categories