As news extra an interview with Christopher Zoog – a HOK buildingSMART specialist – describes an example of IFC4 integration in a complex façade study for a major new hospital building in New York City…
Dr.-Ing. Thomas Liebich, the Chair of buildingSMART International Model Support Group, made a long waited announcement:
After 6 years of intensive and hard work and many review and quality assurance cycles, the next generation of buildingSMART’s flagship international standard IFC has been finally released – a collaborative work by buildingSMART‘s Model Support Group and all other contributors:
In spring 2013, the new release of IFC4 was formally published as an ISO standard – ISO 16739.
At the end of a long and meticulous process, IFC emerges stronger and better, and ready to win new fans around the world.
‘Accreditation of IFC4 was a welcome achievement after the efforts of everyone involved,’ says Thomas Liebich, AEC3 DE, who led the work through buildingSMART’s Model Support Group.‘At the last round of voting, the response to ISO 16739 DIS [Draft International Standard] was overwhelmingly positive – 11 ‘yes’ votes and zero ‘no’ votes. It doesn’t get better than that.’
Route to accreditation
The process has involved intensive internal and external reviews to highlight and resolve the issues. As the process took its course, the IFC4 issue database accumulated a total of 1,100 issues that had to be resolved. ‘Software companies usually come in late in the review process,’ explains Thomas. ‘And there was more feedback on the last release candidate than ever before.
IFC has come a long way since the early releases in the mid-1990s. End-users will feel the benefits once IFC4 is implemented in commercial software, and there will be a ripple effect as clients get their projects built more efficiently and sustainably. Until then, newly certified IFC2x3 software should be used.
IFC4 at a glance
• enhances the capability of the IFC specification in its main architectural, building service and structural elements with new geometric, parametric and other features
• enables new BIM workflows – including 4D and 5D model exchanges, manufacturer product libraries, BIM to GIS interoperability, enhanced thermal simulations and sustainability assessments
• links all IFC property definitions to the buildingSMART data dictionary
• improves readability and ease of access to the documentation with numerous implementation concepts and fully linked examples
• contains ifcXML4 schema, fully integrated into the IFC specification in addition to the EXPRESS schema
• has been developed in line with the new mvdXML methodology (as the baseline for future computer-readable model views and data validation services)
• corrects technical problems found since the release of IFC2x3
• enables the extension of IFC to infrastructure and other parts of the built environment
IFC4 has been finalized, and it is officially released on 12. March 2013 for production.
London / Munich / Waltham 12. March 2013
IFC4 officially released
After over 6 years of development and over 1100 issues being resolved, on 12. March 2013 buildingSMART international has finally released the new generation of IFC schemas – IFC4. It will now be the basis of future work of establishing new open BIM enabled work flows by defining new IFC4 based model view definitions. The official IFC4 release includes both the IFC4 EXPRESS schema to support current STEP-based IFC exchanges, and the ifcXML4 XSD schema to support new simple ifcXML transactions,
Christopher Zoog of HOK presented this great explanation to the New York City Revit User Group.
HOK are certainly pushing and pursuing IFC in a number of impressive ways into their workflows, including pressure on software providers.
IFC, what it is, and why you should care:
IFC is often talked about being simply the “DXF format” of BIM, and while it’s true that is an exchange format for design authoring, IFC’s further usefulness is generally not well understood in the AEC industry (at least not in the US). IFC is arguably the best way to leverage data that is typically trapped inside your building information model, often by the very tool used to create it. This lecture will explore IFC’s origin, its current status, as well as how it can unlock that trapped data! Several BIM use workflows will be demonstrated including:
Design Authoring / Computational Design (Grasshopper to Revit, Tekla)
Program Validation / FM handover (dRofus, TIDA, Revit)
Performance based design / Simulation (MassMotion, Simergy, Revit)
Model based coordination / Automated Code Compliance (Solibri, Revit, BIM Collaboration Format)
Design Collaboration (dRofus, Revit, Model Server, BCF)
Various IFC exporting tools, as well as IFC specific editing tools will also be discussed and demonstrated.
It is important to know that the actual IFC file, whether it is an SPF (STEP Physical File) or XML representation, is always defined against a schema. The schema gives meaning (names and relations on top of the knowledge contained in the IFC file). The schema is static for all IFC4 files. It is published by buildingSMART as an EXPRESS schema and alternatively an XML schema.
Currently the latest version is the Release Candidate 4 of IFC4. It can be downloaded at:
On top of the schema MVDs (Model View Definitions) are defined that describe what parts of the schema are used within a certain IFC file and/or extra restrictions on top of the schema. IFC4 is describing each instance of a building component that is contained in the IFC file. Click on picture for schema!
The instance contains semantic data like its name, description, type (wall vs. door), relations with other instances (connections to walls/other objects, opening elements), position and relation in the building structure as well as geometry and property sets. New to IFC4 is that each instance has also a type defined (in previous versions this was only valid for a subset of the instances). Non geometrical information can be attached to instances as well as to types.
Several instances can refer to the same type.
The position of instances is absolute or relative towards the position of another instance, these relative placements can be nested and several levels deep. Geometry of each visible instance is defined. It is however possible to reuse defined geometry from other instances.
Not all defined geometry in an IFC file is visible in CAD or viewers. For example space boundaries between walls and spaces are often defined but mostly not shown. Each instance can have more than 1 geometrical representation and a single 3D representation of an instance can have more than one color.
IFC4 files are full of relations. Many of these relations are inverse relations defined by the schema and not visible in the text view of an IFC file.