Summary for faq

The list of frequently asked questions provides a quick answer about the basics of buildingSMART, IAI, and the IFC specification, implementation and usage. It intents to offer newcomers a general overview, and interested people a reference knowledge to check first.

The frequently asked question section is divided into:

General questions about buildingSMART, IAI, and IFC General understanding of the IFC Specification Specific question about the IFC Specification Initial questions for implementing the IFC Specification in Software Basics for introducing and using IFC compatible software

Faq general questions

Q. What/who is buildingSMART? How does it work with IAI/IFC?

A: buildingSMART is an international, non-for-profit organization that has been established to support companies within the AEC/FM industries on "“The route to integrated project working in design, construction and facilities management”. Its vision is "To provide a universal basis for process improvement and information sharing in the design, construction and facilities management industries". buildingSMART is represented internationally as buildingSMART International Ltd. and regionally by buildingSMART chapters. buildingSMART is the new name and brand of the International Alliance for Interoperability, IAI. It is the same organization. Since the foundation of IAI, now buildingSMART, the development of an international format to exchange and share building information has been a core activity. The Industry Foundation Classes, IFC, are the continuous outcome of the mission "buildingSMART is integrated project working and value-based life cycle management using Building Information Modelling and IFC".

Q: Who owns IFC? Can we trust its future?

A: The IFC specification is copyrighted by buildingSMART international, an international non-for-profit industry alliance. Established in 1995 buildingSMART is a long-standing organization that continuously develops and maintains IFC as part of its mission. The IFC specification is a neutral and open specification that is not controlled by a singular vendor or group of vendors. It is freely available on the web.

Q: What is IFC all about?

A: IFC represents a data schema for sharing construction and facility management data across various applications used in the AEC/FM industry domain. It is an object-oriented data schema based on class definitions representing the objects (such as building elements, spaces, properties, shapes, etc.) that are used by different software applications used in construction or facility management project.

Q: What is the difference between BIM and IFC?

A: BIM stands either for the verb "Building Information Modelling", i.e. for an integrated process of designing, engineering, constructing and maintaining a building based on a consistent and shareable computer representation of the facility including both graphical and non-graphical information. Or for the noun "Building Information Model", i.e. a digital representation of the building in software based on object information combining graphical and non-graphical properties. BIM Software often relates to 3D and object-based CAD. IFC is an open standard to represent the information in a building information model that can be used to openly exchange and share this information among many different software systems. It supports BIM as "a computable representation of the physical and functional characteristics of a facility and its related project/life-cycle information using open industry standards to inform business decision making for realizing better value (NIBS - Facility Information Council)"

Q: How does it relate to other file formats?

A: It differentiates itself from other formats by its object focus and its openness. Object focus: IFC is a standard for building information models, not for drawings. It enables to exchange information about building structures, elements, spaces and other objects in a BIM. 3D and 2D shape, properties and attributes, parameters and relationships (e.g. connectivity) among elements are examples for the content of IFC. Actual IFC files are based on a view definition that determines the scope of the IFC exchange. Openness: IFC is an open specification, supported by an international, non-for-profit organization and it is registered with ISO as ISO16739. It is not owned by a single vendor or group of vendors.

Q: Who develops IFC? What is the procedure for IFC development?

A: IFC is developed as an open standard by buildingSMART International that has implemented a standing group, the Modelling Support Group MSG to develop and maintain the IFC standard. This website is the website of buildingSMART MSG and contains all official information around IFC.

Q: Who decides about what becomes part of the IFC standard?

A: The basic development direction of IFC is a decision made by buildingSMART International. New general additions to IFC, increasing general scope, have to be proposed to buildingSMART International as an IFC extension project proposal. The technical decision making group, ITM, votes on accepting such a new IFC extension projects. Minor additions can be handled by the general maintenance process between IFC releases and may lead to an intermediate minor update, i.e. a technical corrigendum. Issues are resolved by the Modeling Support Group MSG based on a consensus driven process. Voting would provide an ultimate decision. Maintaining the integrity of the overall IFC architecture is the responsibility of the MSG lead.

Q: What is the quality assurance system applied to the development and maintenance of IFC?

A: Any new release, minor or major, includes an open review process. The pre-releases, alpha, beta and release candidate, are published on this website, and an announcement for review is made. The internal review is performed by MSG itself. Each part of the IFC specification (short form schema) has an “owner” being responsible for proposing and doing the changes and additions, and 1-2 internal reviewers, counter checking the changes and additions. The external review is open for all interested in further development and quality improvement of IFC. There is a public invitation for review over this website and the online IFC Review issue database, see http://www.iai-tech.org/jira/browse/IFR. The software companies organized in the Implementation Support Group, ISG of buildingSMART are particularly encouraged to participate.

Q: How is the IFC model maintained?

A: The Model Support Group MSG is responsible for maintaining IFC. It keeps on internal issue database to log and resolve all issues brought forward. It keeps a strong link to the Implementation Support Group, ISG to follow and support the IFC implementation activities and to learn from all upcoming questions as being issues to be addressed by improving the IFC Specification, implementation guides and accompanying documents.

Q: Are there any costs attached to using IFC?

A: No. Using the IFC specification and the IFC schema is free. Implementing IFC is royalty free. As a developer you may consider the cost of a toolbox that helps compiling IFC for your application, and for using the buildingSMART certification process for quality assurance. As a user you will see that most of the IFC import/export comes within the main product line at no extra cost, however it is in the software vendor’s own discretion to decide. Being a member of buildingSMART would bring added value to both developers and users worth the membership fee. Membership is required for certification.

Q: I heart that IFC is an exchange standard between CAD programs, can IFC provide more then the exchange of geometry?

A: Yes. In fact, the main purpose of IFC is to exchange information about a building, which may include geometry, but is by no means limited to this. Linking alphanumeric information (properties, quantities, classification, etc.) to the building objects and maintaining the relationships among the building objects is a main feature of IFC. IFC is also not restricted to be an exchange format between CAD programs, it can be used to bridge between different authoring and downstream applications, such as CAD-to-QTO, CAD-to-CAFM, CAFM-to-CAFM, structural modeling application to structural analysis application. The content of the IFC exchange is determined by the IFC view definition, so strictly speaking there is no IFC implementation, but several IFC view implementations.

fag general ifc spec

Q: The notation of the IFC Schema is EXPRESS, what does EXPRESS stand for and where do I get more information?

A: EXPRESS is a data definition standard developed to enable a formal definition of industrial data. It allows to formally validating a population of data types (the entities and attributes). It is an international standard, ISO10303-11, and used in several standards for the definition and exchange of product data, such as STEP, CIS/2 or IFC. ISO documents are copyrighted and published by the member organisations of ISO. An overview of EXPRESS can be found at http://en.wikipedia.org/wiki/ISO_10303-11.

Q: How does the different versions of the IFC model relate to each other?

A: There have been five principal releases of the IFC over since 1996; these had been IFC1.5.1, IFC2.0, IFC2x, IFC2x2 and IFC2x3. Since the release of IFC2x (published in 2000), each release has left the core (or ‘platform’) of the IFC specification unchanged, and has added to it. This platform guarantee has meant that most vendors have had no difficulty in upgrading their application to IFC2x2, IFC2x3 and hopefully in future to IFC2x4. Since the publication of IFC2x new releases where mainly driven by adding new concepts to the IFC specification in order to capture more exchange use cases and to improve existing definitions reflecting the lessons learnt from implementation and usage. Since IFC2x a new major release has been published every 3 years. See also the following overview.

Q: I heard about ifcXML, what is the difference between IFC and ifcXML?

A: Content wise there is no difference. ifcXML represents the same content of the IFC specification as IFC EXPRESS does. The ifcXML XSD schema is generated from the master EXPRESS representation by a language binding described by ISO10303-28ed2. ifcXML files are XML document files that validate against the ifcXML XSD. An IFC model can be written and read from a data file in these ways:

Usually a .ifc file contains the model represented in ‘STEP physical file format’ STF Alternatively exactly the same information can be represented as XML using the ifcXML schema definition. The file extension is .ifcxml. A current proposal within the Implementation Support Group would allow to read/write a zipped .ifc or .ifcxml file directly from a file with the extension *.ifczip

Q: What are the advantages between IFC and ifcXML?

A: ifcXML files are larger than the equivalent *.ifc (SPF) files, they are usually between 4-8 times larger. However the tools and toolkits to read, transform and write XML are freely available. Many enterprise and desktop systems can handle XML. Therefore ifcXML has been added as a valid representation of the IFC specification. The ifcXML XSD releases are published here. More information on ifcXML development and implementation is available in the ifcXML Implementation Guide.

faq specific ifc spec

Q: I keep hearing the word 'schema'. What is a schema and how does it relate to IFC?

A: A schema is a data model in a formal machine-readable notation. The IFC specification consists of such a schema and associated informal human-readable semantic definitions. The schema describes a set of data types and their possible relationships. There are subtly differing termini: While the IFC specification defines a “data model” or “product data model”, a collection of objects — instances — which conform to this data model is called “product model” or, more to the point of IFC, “building model”. Data can be formally checked for conformance to the schema. This ensures that data representations are syntactically correct. To a limited degree, the schema also enforces semantic integrity on a low level.

The IFC schema, like some other data models which are written in EXPRESS, comes in two flavours: The “long form” and the “short form”. Software implementers use the long form schema which is comprised of all data types in a single schema. The short form schema is used for documentation purposes and in schema development. It consists of a number of sub-schemas for different topics, e.g. “shared building elements schema”, “architecture domain schema”, and so on. The term IFC schema, if not specified otherwise, always relate to long form schema.

Q: What is a property set?

A: Most objects can have properties attached to them that have little or no relationship to other objects. The IFC model differentiates between attributes that are directly attached to the object as attribute of the entity, and properties, group in a property set and assigned to the object by an relationship. The latter is the more flexible way to extent applicable properties. Furthermore these properties are evolving over time, and may be specific to particular regions, countries, or projects. The IFC schema supports storing and transmitting these properties in named sets. The IFC schema recommends property sets as part of the IFC Specification already, but regional adoptions and applications may define more. MSG has published an XML schema, called Property Set Definition schema PSD to defined the properties and property sets.

Q: How can I see all entities, sub types, types, etc. in the IFC specification?

A: Use the IFC Specification published as a HTML document set here. Flat lists of all defined types, enumerations, select types, and entity types are available in the HTML documentation via “alphabetical listing” in the “Browsing documentation…” frame. A tree view of all subtypes of entity types is available under “hierarchy listing” in the “Browsing documentation…” frame. This requires JavaScript to be enabled in the browser.

Q: In IFC there are many optional attributes, why? What does it mean, if I receive "empty" optional attributes?

A: An empty attribute (i.e. an attribute having indefinite value) generally means that no value is known or that no particular value is applicable in the respective information exchange. Since the IFC specification is developed to cover many exchange use cases at different stages of the building life cycle, there is hardly any attribute for which providing a value is mandatory at each life-cycle stage and exchange purpose. Therefore almost all attributes are optional in the IFC specification.

A view definition that narrows the scope of IFC implementation for a given exchange use case may determine, that attributes, that are optional in the IFC specification, have to have values asserted. A few attribute definitions in the IFC specifications specify default values which shall be assumed if an exchange file contains the indefinite value.

Q: Which attributes are written to an IFC file and how to obtain the other attributes (inverse and derived attributes)?

A: So-called explicit attributes (the usual plain attributes) occur directly in IFC exchange files. If an explicit attribute is defined as OPTIONAL in express and an object (an entity instance) does not provide a value for such an attribute, then the attribute still occurs in the file as a $ (dollar sign). So-called INVERSE attributes (reverse cross references between entities) do never occur in IFC files. So-called DERIVED attributes (attributes which are to be calculated from explicit attributes) either do not occur in a file or occur as a * (asterisk) — see next question. To obtain inverse or derived attributes, you either can rely on a capable ISO10303 toolbox or have to implement them on your own as far as you need them. This is documented in more detail in ISO 10303-21.

Q: What does a dollar character ($) and a star character (*) mean in an IFC file?

A: The $ character encodes the indefinite value, i.e. it appears if an optional attribute has not been filled in. (Note, the indefinite value is sometimes also used in the EXPRESS schema of the IFC data model. There it is encoded as “?”, not as “$”.) The * character encodes so-called omitted parameters. These are attributes which are defined as a regular explicit attribute in a supertype but redefined as a derived attribute in a subtype (and the record in the IFC file is an instance of the subtype). More information about the encoding of IFC files can be found in ISO 10303-21.

faq ifc implementation

Q: Which other software supports already IFC? Is there any IFC related freeware?

A: There is free software available for IFC, several viewers but also several tools to help you implement are freely available or even as open source. An online database is provided that includes all IFC compatible software that had been registered by the software vendors. See also:

http://www.ifcwiki.org/index.php/Free_Software http://www.ifcwiki.org/index.php/Commercial_Software

Q: Are there any development kits available to implement IFC?

A: Yes, they are often called toolkits. These toolkit usually compile the IFC schema and provide different computer language support (C++, C#, Java, VB, etc.) to read and write *.ifc files. Most developers offer a test version including some examples on request. Further links can be found:

http://www.iai-international.org/software/Tools%20for%20IFC%20developers.html http://www.ifcwiki.org/index.php/IFC-Developers

Q: Which IFC version should I implement?

A: At this moment IFC version 2x3 is the best choice to implement, it has the broadest coverage of support of all published IFC releases. In case you expect a really very long period before going to market contact a specialist to decide if it is beneficial to start directly with version 2x4

Q: IFC does not (quite) support a specific need that I have. What can I do about it?

A: Consider if the specific need is for an object (with representations and relationships to other objects in the model) or is the need for some further properties.

For example, an airflow application models spaces and cracks. Spaces are already part of the IFC schema, but there is no representation of a ‘crack’. However any crack is in reality associated to a physical object, a wall, door or window. Hence a property set can be defined to hold the properties of the crack, such the length, average width, and perhaps also the airflow rate expected for a given pressure.

As another example, perhaps your building proposal includes an artistic sculpture in the courtyard. This is clearly not a simple property of the courtyard, and the IFC model supports proxy objects. These function as objects but make no assertion as to their function or role. The application should offer the user the facility to classify or describe the object in detail. See IfcBuildingElementProxy as the extensible proxy definition of the IFC specification.

Q: Where can I find some sample code implementing IFC?

A: There is an example how to write an IFC file from scratch available via: http://www.iai-tech.org/services/get-started/hello-world. Most developers of toolboxes offer a test version including some examples on request. The following links give a set of examples:

http://www.ifcbrowser.com/ifcenginedll.html http://www.ifcbrowser.com/downloads/BETA/ReadWriteExamplePackage.zip

Q: I'd like to learn from existing IFC examples. Where do I find IFC example files, possibly with explanations?

A: There are several sources of IFC sample files. This website includes examples, see “Hello Wall”. More links to examples can be found at ifcWiki page. If you decide to participate in the IFC certification program, see the information about the certification process where you can get access to numerous unit test cases and several complete test buildings.

Q: How do I understand the notation of an IFC file?

A: An *.ifc file follows the notation of ISO10303-21, the STEP physical file format. It is an ASCII encoding of the EXPRESS data model of the IFC specification. There is typically one record per line, and each record represents one instance of an entity. ISO documents are copyrighted and published by the member organisations of ISO. An overview of the STEP physical file format can be found at http://en.wikipedia.org/wiki/ISO_10303-21.