Referenced by HPBMS.com
buildingSMART is all about the sharing of information between project team members and across the software applications that they commonly use for design, construction, procurement, maintenance and operations. Data interoperability is a key enabler to achieving the goal of a buildingSMART process. buildingSMART has developed a common data schema that makes it possible to hold and exchange relevant data between different software applications. The data schema comprises interdisciplinary building information as used throughout it’s lifecycle. The name of this format is Industry Foundation Classes (IFC), it is registered by ISO as ISO/PAS 16739 and is currently in the process of becoming an official International Standard ISO/IS 16739.
There are many definitions for a BIM (Building Information Models) are and could be. Many people associate BIM with a 3D model of an architectural design, but it can be so much more than that. A BIM model is a placeholder for the information about a building or a facility, and that can includes also ductwork, electrical installation, fire protection, occupancy, energy consumption, CO2 emissions or whatever information you need to collect regarding a site or a building. A BIM model does not even need to have geometry, only information and still be a BIM. This also means that BIM is the same as a 3D CAD model and vice versa. In fact many BIM building projects does not start with a model made by a CAD system, but from information about a clients requirement for and project brief long before anything about geometry like, shape number of stories, floor plan etc. has been created. This collection of information is also a BIM and can later be feed into a BIM Authoring tool (ie. Architectural CAD/BIM system) to enrich the model with geometry and design. How this is done in day-to-day projects is more about the process than about technology and formats.
Software applications store the building information in a native and proprietary format. In order to make this valuable information available to other project participants, their software applications either all have to understand the native formats of the other applications, or preferably they support IFC as the open format for building information models. IFC can be used to exchange and share BIM data between applications developed by different software vendor without the necessity to support numerous native formats. As it is an open format, it does not belong to a single software vendor and is therefore neutral and independent of a particular vendor’s schedule and development direction. One could say that IFC is open BIM as opposed to proprietary BIM.
Software applications correctly implementing IFC are said to be IFC compliant, as they allow to read and/or write *.ifc files. It is important to understand, that every implementation of an IFC exchange should follow a so called “Exchange Requirement”. An Exchange Requirement documents which information that needs to be present in an exchange/sharing of data at a certain stage in a project. It’s not spesific enough to ask for a IFC file, which basically can be compared with asking for an excel sheet without specifying which data you expect to be present in that excel sheet.
Exchange Requirements are grouped into something called an IFC View”, i.e. a particular subset of IFC dedicated to a set exchange purposes. Most currently available IFC compliant software has implemented the IFC coordination view, but there are other IFC view definitions, e.g. the IFC structural analysis view. within each of these view, there can be several exchange requirements (i.e for different the domains in coordination view etc.)