Nick Pawlikowski - Interoperability

In its most general sense, interoperability is the ability to pass data between applications so that the applications can work jointly on a single task.  Interoperability can be achieved in part by standardization of file formats.  An early example is IGES (Initial Graphics Exchange Specification).  NASA told the CAD companies it had been working with to develop a standard format to make translation between their applications easier.  The result was IGES, a “middle ground” format that all companies were able to import, export, use and exchange, rather than creating translators for every companies’ proprietary formats.

The diverse nature of the AEC industry and the applications that exist within it demand interoperability to ensure effective collaborative design, planning, and construction.  There are four methods of data exchange in BIM: Direct proprietary links, Proprietary exchange formats, public product data, and XML-based exchange formats.  Direct links provide direct connection between two applications, and rely on middleware software interfaces.  They can have better support for files being exchanged, but are the product of and thus require a business agreement between two companies, and the exchange lasts only as long as the agreement does.

Proprietary file exchange formats are developed by a company to interface outside data formats with that company’s application.  Many are text format, a well-known example beign DXF (Drawing eXchange Format).  They are designed to address specific capabilities needed by the company that created them.  Public product data model exchange formats are designed as an open-standard building model that allows companies to utilize applications jointly beyond what would be provided by any single software company’s specific proprietary method.  Interoperability on this level is critical for projects with large, diverse teams that utilize a variety of software programs with their own data formats.  An example is IFC (Industry Foundation Class), which carries object and material properties, as well as the relationships between objects and geometries.  XML (eXtensible Markup Language) is an extension to HTML.  Exchange formats that are based on XML allow different data structures (called schemas) to exchange many types of data formats between applications. 

As new building system models were being developed (such as for mechanical, electrical, and plumbing systems), new standards were needed.  The International Standards Organization (ISO) launched committees to develop STEP (Standard for the Exchange of Product Model Data), which was based on a few defining principles, such as the development of machine-readable language instead of a traditional file format and the reference of sub-models that are made as subsets of larger, standard models for generic classification.  The ISO-STEP initiative culminated in the creation of the EXPRESS language, which utilized an object-oriented programming.

Many data models used today, including IFC, are based on the EXPRESS language.  The International Alliance for Interoperability has been pushing IFC as a neutral product model for applications in the AEC industry.  IFCs are designed to provide standard data models of building information to allow for exchange between various applications, through the entire lifecycle of a building.  They are designed in a “framework” model; they provide broad, general definitions of object elements from which more detailed models can be developed for specific workflows.  For example, the standard “geometry” framework entity can be specified as a wall, floor, or other sub-entities.  A specific building element is specified in a tree format, with each “branch” holding properties and relationship specific to that branch. 

In IFC data exchange scenarios, modeling information needs to be transferred from a source application to a receiving application.  An export translator within a source application extracts the data and assigns it to the relevant IFC entity classes.  The entity data are mapped from IFC objects to a text file format, which is received by the receiving application and interpreted by the import translator in terms of the IFC objects represented by the text.  The import translator writes the data from the IFC objects into its own data structure.  IFC viewers can be used to access the IFC object data directly.  Specific IFC Views can be developed by companies to interpret IFC object data and integrate it into their own applications.

                As IFC becomes more automated and widely used, the rigor of building model creation and review will need to become more stringent.  Models of all stages of design will need to be checked carefully for accuracy before hand-off to another team to ensure bad data is not transferred.  A new version of the IFC data model standard is released every two years, hich resolves issues and improves upon features in the previous versions.  IFC views will be developed further to include extensive testing to ensure reliability before their release and use in the AEC industry. 

An alternative to IFC is the use of XML schemas.  HTML uses tags to specify the type data that is being transmitted.  The XML extension allows for user defined tags, and therefore user-created schemas.  A few XML schemas that have been developed for the AEC industry are OGC, which deals with geographic information, gbXML, which handles green building information, and aecXML, which represents contract and specification documents, RFIs and RFPs, and other administrative resources. 

Web-based formats such as DWF and PDF to not address the interoperability issues supported by platforms such as IFC and XML, but they are a good way to publish building information for review.  Web-based formats can be generic for basic viewing purposes, or have embedded views of project information which contains non-editable object meta-data.

                Management of file versions is becoming increasingly complex and challenging as they support more and more applications.  An alternative to these file formats are building model repositories, which are database systems based on a published object-based format that allows query, transfer, updates, and management of project information from different applications.  In basic terms, instead of passing a file between applications over and over, all applications draw from and modify the same “pool” of building data.  Repositories are expected to be important for dataset preparation for such processes as energy analysis, building material tabulation, and building operation and management. 

Significant improvements to interoperability have been managed in the past few decades, but there are many issues that are still left to be resolved.  Only a few exchanges allow editing, most are just for viewing.  However, all BIM tools now support IFC in ways that allow basic exchanges to be made with good completeness and accuracy.  The figure below presents the current formats common in the AEC industry and their relative geometries and structure:

COMMENTS:

(On Drew Hovey's Post)
Drew, I think your CFD example explains the concept of parametric modeling well.  In general i think that parametric modelling is a great method of quickly iterating on a design to discover the best option.  Your mention of the different branches of Revit (Architecture, Structure, and MEP) relate to the interoperability chapter of the BIM handbook that I read.  I think that breaking up the Revit software into different sectors allows for the workflows that are specific to a particular sector to be performed with efficiency, and because each branch of Revit is based on common entities, the different sectors can by synced and compared with relative ease. 

(On Peter Dannemann's Post)
Peter, reading your post made me aware of a benefit of BIM that I had not thought about deeply before. I knew BIM was a powerful tool for designers, but your mention of BIM's ability to better inform owners of the state of their projects made me think more about how people other than designers could use BIM to their advantage. I am wondering if extensions or independent software exists that can calculate the cost of a change in design at certain stages in the construction process; that would be use useful tool for owners, contractors, and designers alike.

(On Ronald Herazo's Post)
Ronald, I really enjoyed reading about the advent of 3D computer graphics.  The chapter of the BIM Handbook I read (chapter 3) touched on the Boolean operations that allowed the initial creation of shapes, but you went more in-depth which I appreciate and enjoyed reading.  I would be willing to bet that these same operations, coupled with parametric design, allow the easy creation of families in Revit, such as the combination of a rectangular prism and several cylinders to create a pile / pile cap assembly (which I have had the pleasure of doing many times during my previous co-op).  

CITATIONS:

All information in this blog post was gathered from the BIM Handbook, Chapter 3 – Interoperability:

Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2008). BIM Handbook. Pages 65-91. Hoboken, NJ: John Wiley & Sons, Inc. Retrieved January 21, 2017.