Tag Archives: buildingSMART

IFC4 officially released. The Evolution of BIM.


Congratulations to Dr Thomas Liebich and the team on the public release of IFC4!

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.

Visit the full announcement at http://www.buildingsmart-tech.org/news/ifc4-officially-released 


A recent article regarding the significant improvements to the IFC4 schema was included in the Spring edition of JBIM (Journal of Building Information Modelling) by Tim Chipman is deputy leader of buildingSMART International’s Model Support Group.


IFC4: Evolving BIM By Tim Chipman

Tim Chipman is deputy leader of buildingSMART International’s Model Support Group and develops software at Constructivity.
JBIM (Journal of Building Information Modelling) is an official publication of the National BIM Standard (NBIMS) and the National Institute of Building Sciences (NIBS) 

In recent years, the Industry Foundation Classes (IFC) standard for building information modelling (BIM) has seen widespread adoption, supported by approximately 150 registered software applications.

This article describes the next evolution across software applications. The goal of IFC has always been to describe how building information can be leveraged across applications within and across vertical industries, supporting the vast array of disciplines encountered in the building industry. To be useful across such a large ecosystem, such standards must capture necessary detail to describe how a building is to be built, along with the many non-physical aspects describing who is doing what, when, how and why.

Meanwhile, many downstream applications are only concerned with subsets of this information. Another aspect to address is the format of information, which must accommodate changing technology and diverse platforms, such as phones, tablets, desktops and servers.

For basic applications, XML provides ease of integration; compact formats such as STEP Physical Format (SPF) are more practical for representing buildings in detail; spread sheets such as Excel provide access to a wide range of users without custom software; and databases of various forms may support collaboration among concurrent users.

Meanwhile, as more applications adopt IFC, customers have asked for deeper integration to capture more detailed information across applications in a consistent way. To support this growing usage, IFC has evolved with initiatives on multiple fronts.

Data model: A number of enhancements have been introduced in IFC4, with a focus on system-wide improvements while maintaining backward compatibility.

Parametric design: While buildings are ultimately made of discrete components, during the design process it is often desirable to use higher-level representations reflecting the design intent, so that changes can be made in one place, where the composition and layout of components, can be automatically updated to reflect the change.

IFC4 introduces the concept of material profiles, where axis-based components, such as beams, pipes and ducts, can be described by paths and cross-sections of materials, along with offsets relative to the axis and end points. Similarly, a concept of material constituents has been introduced where components, such as doors and windows, can have various parts (for example, framing and glazing) designed by geometric aspects and corresponding materials. Material layers allow flat components, such as slabs and walls, to be described by material thicknesses and boundaries with offsets.

Geometry: IFC4 expands geometry to support more complex shapes as well as simplified geometry. Complex shapes may be exactly described using Non-Uniform Rational B-Spline (NURBS) curves and surfaces. Simplified shapes may be described using tessellated surfaces with compact lists of vertices and triangles, providing the closest mapping to GPUs and more efficient processing as may be suitable for mobile applications.

Libraries: IFC4 supports capturing templates of products, processes, resources and property sets. These files can be referenced by other IFC files that include instances of such templates.

Ports: Ports provide the capability for MEP elements to connect through pipes, ducts or wires. IFC4 extends the capability for defining ports at product templates and standardizes ports on objects according to product type. For example, a water heater may have ports for gas or electricity as input, cold water in and hot water out. This enables products from different manufacturers to be intelligently connected according to system type and connection geometry.

Processes: IFC4 expands the process model to support scheduling of tasks, procedures and events, with expanded detail as found in leading scheduling applications and 4D simulations. Process templates allow common processes to be captured in libraries and re-used.

Resources: IFC4 expands the resource model to track costs and environmental impacts of materials, labour, equipment and other project resources with expanded detail. Resource templates allow common resources to be captured in libraries and re-used.

Constraints: The constraint model has been formalized so that requirements may be directly validated on any object attribute, either directly or along a graph of objects and collections. For example, a requirement may indicate that the height of a space must exceed a certain length. Constraints may also be used to indicate mapping of data to external files, conflicts when multiple versions of a model are merged, formulas based on calculations from other attributes and tables of values that apply for parametric modelling.

Documentation: Published as ISO 16739, the documentation for IFC had to undergo rigorous adaptation to meet requirements for formatting and content. At the same time, documentation was expanded to provide real usage examples for hundreds of product types, while eliminating redundancy by organizing common concepts in a central place. Documentation is now multi-lingual, with translations in five languages as of this writing.

Definitions: IFC, along with hundreds of other engineering standards, is defined using the EXPRESS data definition language, where the rich semantics allow virtually any other schema representation to be derived. The IFC4 documentation now includes a simplified XSD-based representation for all data types, enabling XML to be used in a more compact form with better readability.

Diagrams: Instance diagrams are now included for all data types. Because building Journal of Building Information Modelling components in the real-world have a vast number of relationships (for example, how connected, where placed, when constructed, who is responsible and what changed). Relationships must also be captured in data model, where diagrams make it more clear how the various objects interact.

Examples: Sometimes it is easier for software developers to understand new concepts by seeing tangible examples rather than sifting through definitions. The IFC4 documentation now includes a comprehensive set of examples in various domains including: architectural; structural; mechanical, electrical and plumbing scheduling; and estimating.

Model views: While the IFC specification defines how to represent BIM electronically, it does not indicate what should be included for particular scenarios. The concept of a model view definition (MVD) has evolved to fulfil this role, describing exactly what information must be included for a handover, such as for a building maintenance request.

Contracts may be written to require information at a particular stage using the referenced model view, where submissions may be electronically validated and enforced.

mvdXML: In parallel with IFC4, the MVD approach has been formalized so that requirements may be defined in a way that is computer-interpretable, yet human-readable in resulting documentation, using a format called “mvdXML.” MVDs may also define mapping formats for translating information into general-purpose applications such as spread sheets. The electronic encoding of MVDs now also makes it possible for a new class of software applications to adapt data to conform to the MVD without prior knowledge.

Tools: buildingSMART International has provided a new tool called ifcDOC for authoring model view definitions and producing resulting schemas, documentation and diagrams. “is same tool is used for generating IFC documentation, the Construction Operations Building information exchange (COBie) specification and a growing population of MVDs.

To take advantage of new BIM capabilities and much-improved software interoperability, visit www.buildingsmart-tech.org to find the growing list of applications supporting IFC4.

The National BIM Standard and the National Institute of Building Sciences are pleased to announce the continuation of our relationship with Matrix Group Publishing in the production of the Journal of Building Information Modeling, an essential information source on business, standards and technical issues related to BIM. http://www.wbdg.org/references/jbim.php

IFC Exporter for Revit 2013 v2.8.0

As posted  27 February 2013 (http://sourceforge.net/projects/ifcexporter/files/2013/)

(2.8.0) IFC Exporter for Revit 2013 v2.8.0.msi, IFC Exporter for Revit 2013 Source v2.8.0.zip General: – Clean up code dealing with door and window operation and construction type. – Clean up code dealing with getting Solids from element geometry. – Finalize support for FM Handover view. The new functionality for this is included in the lists below. – Replace native function call to create some columns as extrusions with .NET code. – Renamed the shared parameters for many entity properties to have “Ifc” at the front. – Sort parameter names on export to minimize changes in IFC file from subsequent exports of the same file. New Functionality: – Add 11 new IFC common parameter sets, including: Pset_AirTerminalTypeCommon, Pset_DistrubutionFlowElementCommon, Pset_FlowTerminalAirTerminal, Pset_SpaceOccupancyRequirements, Pset_PlateCommon, Pset_ReinforcingBar*Common – Add support for IfcLengthMeaure parameter export. – Add support IfcCircleHollowProfileDef; use for extrusions if appropriate. – Add support for Provisions for Voids. – Allow specification and export of a user-defined classification system, instead of just Uniformat. – Allow exporting elements as IfcDiscreteAccessory/IfcDiscreteAccessoryType. – Allow “IfcExportAs” to take both the entity name and the type name in the format “IfcEntityName.TypeName”. – Export base quantities for 5 elements: IfcBuildingStorey, IfcCovering, IfcDoor, IfcSpace, IfcWindow. Some of these were already supported and were just moved from native to .NET. – Export FabricArea and FabricSheet as IfcReinforcingMesh and IfcGroup, respectively. – Note: that the default export settings have these set as “Not Exported” – these have to be updated manually to “IfcReinforcingMesh” and “IfcGroup”. – Export ceilings as extrusions or BReps if possible, instead of just surface models. – Export surface styles by default for Coordination View 2.0. – Include Ceiling as a room bounding element on export if it is part of only one room. – Stabilise GUIDs for Pset_Building/BuildingStorey/SiteCommon, internal Revit property sets, and slabs in roof containers (only for the case of an IfcRoof containing a single IfcSlab, however.) Bug Fixes: – Changed incorrect “PSet” to correct “Pset” for various parameter set names. – Don’t create openings for doors and windows when the host is exported as parts – Don’t export RepresentationMap for IfcTypeProduct with 0 items. – Don’t ignore an internal Revit parameter on export if it has the same name as a parameter in another group. – Export materials for IfcReinforcementBar; make body representation “AdvancedSweptSolid”. – Fix export of grids so that only one IfcShapeRepresentation is created. – Fix export of some extruded columns that were split into separate components by other elements. – Fix issue where classification reference was not exported in non-English versions of Revit. – Make “NosingLength” parameter of PSet_StairFlightCommon IfcLengthMeasure. – Make GetExportTypeFromClassName not reject some unrecognized IFC class names. – Move the local placement of many entities with extrusions and mapped representations for geometry to be closer to the geometry. – Properly export Pset_ZoneCommon for IfcZones. – Properly label some mislabelled IfcOpeningElements as “Opening” or “Recess”. – Properly scale door panel properties, window frame properties, and base quantities on export. – Remove incorrect PsetLightFixtureCommon.ArticleNumber property.

Downloads: IFC Exporter for Revit 2013 v2.8.0.msi

Downloads: IFC Export UI for Autodesk Revit 2013 v1.8.0.msi

Another Evening with IFC: The Shape of Things to Come

Geometry, Collaboration, & OpenBIM Model Exchange


With the success of our first IFC Evening Event, Cadimage is holding a follow-up presentation featuring a “sneak peak” of IFC4 and its extended geometrical capabilities. Special guest speaker Jon Mirtschin, blogger, engineer and software developer will present his observations, research and tools which utilise the IFC standard for BIM and geometry exchange.

Jon will also demonstrate some of the improvements in the new revision IFC4 (pre-ratification) and will open up discussion on is can be done to motivate software vendors to embrace and utilize this technology, opening up more collaborative and powerful workflows. The presentation will also demonstrate some exchange improvements Jon has developed with BIM software including Revit, Archicad, Tekla and Solibri and some of the projects that have benefited from it.

IFC Melbourne Event: Wednesday February 20th, 2013
05:30 PM – 06:00 PM  Arrival and Registration
06:00 PM – 06:15 PM  Welcome and introduction: Matt Rumbelow, Cadimage
06:15 PM – 06:30 PM  Guest presentation: Recent Arup BIM Projects
06:30 PM – 07:30 PM  Guest presentation: Jon Mirtschin, Geometry Gym
07:30 PM – 08:00 PM  Guest presentation: Matt Rumbelow, Cadimage

CPD Points: Registered attendees will receive 2 CPD points as accredited by the Australian Institute of Architects Continuing Professional Development Program.

Where: Where: Arup Melbourne (street access closed after 6pm) Level 5, 215 Spring Street, Melbourne VIC 3000
RSVP:  Friday, November 15th, 2013
Register : Click here to register online
Ph: 1800 172 893  
Web:  www.cadimagegroup.com

Flashback 2005: IFC Becomes a “Newforma” Interoperability Standard Across in the Building Industry

Flashback 2005.  Jim Forester, as President of Marinsoft, is one of the six members of the then IAI  (later to become buildingSMART) that is developing the initial framework of the IFC model. Assisting in the effort is Ian Howell, the then V.P. of Business Development at Citadon and one of the original founders of the global consortium of commercial companies and research organizations that became the IAI in 1995, whilst Ian was a Director of Autodesk.

In 2005, as directors of a new startup called Newforma, Jim and Ian wrote an article that was published by AECBytes outlining the opportunity that IFC presented to “revolutionise” the building industry. The scene was set to image a Utopic era of 3D vendor neutral collaboration, and Jim and Ian where leading the charge with a “new form of” interoperability standard across the building industry.  That article can be found at this link.

Why the history lesson?

In 2011, I had the opportunity to work directly with Jim and Ian whilst I was account director for Newforma in ANZ. After several meetings with them in Australia and America, I can attest to their drive, enthusiasm and obvious technical insight and vision for the entire AEC industry.

Now, as I  work with Solibri utilising IFC across all sectors of the building industry, its a great thing to see that their initial idea has now developed into a truly international open BIM standard featuring a rich set of  definitions designed specifically to enable unambiguous exchange of data between approximately 150 registered software applications.

With the upcoming release of IFC4, which will see new features including NURBS geometry, constraints, libraries and mvdXML, the IFC project commenced some 20 years ago by Jim and Ian will continue to facilitate interoperability across the building industry and beyond.


Newforma is a venture-funded software development company serving architecture, engineering, construction, and owner-operator (AECO) companies. Newforma aims to dramatically increase the effectiveness and productivity of the AECO industry by developing software that enables the seamless flow of information between every building project team member, in support of both project and business processes.

Jim Forester is Chief Data Architect of Newforma.  Jim is a registered mechanical engineer and his professional background includes software development, design content, and consulting services to the AECO industry.

Ian Howell is Chief Executive Officer of Newforma. Ian is an Australian architect, a co-founder of the International Alliance for Interoperability (now buildingSMART), and has extensive experience in applied technology in the building industry, both as a director at Autodesk and as vice president of Citadon.