B2, Group B - Cummings

Interoperability can represent two things: the ability to exchange data between different applications, and the ability for multiple applications to contribute to a unified model.  The most common case of interoperability is from a comprehensive model to analysis software or a CAD drawing.  In this case, data exchange is one-way.  The analysis software can receive a model, but changes to the comprehensive model cannot be implemented via the software.  The second case might involve a structural engineer making changes to a structural model on their particular software, which would thereby change the architectural model on the architect’s software, for example.  In the early development of BIM software, it was quickly realized that a major problem is going to be uniform language from on platform to another.  Without it, data could either not be properly or not at all translated between applications, and errors would need to be manually fixed, minimizing the incentive of BIM.  

To solve this problem, internationally recognized standards are being developed for how the data in BIM models is to be structured.  Industrial Foundation Classes (IFC) is the most widely used convention, being internationally recognized and public.  This ensures interoperability between various competing platforms without requiring a monopoly.  Each model element (walls, floors, structure, electrical equipment, etc.) has embedded in it data specific to several domains (architecture, mechanical, structural, construction, etc.).  Depending on the domain in which the model is being worked in, such as a structural design software, changes can be made to the structure-specific properties of the element, and can be translated back into the comprehensive model.  The below image shows how data is stored in any given element, in this case a wall feature.

There is, still, quite an array of limitations on the issue of interoperability.  Current geometric capabilities meet almost all design and construction needs.  It can also exchange simple parametric relations between systems, such as walls and extruded shapes, but exchange of complex parametric rules and constraints cannot yet be fully translated.  This is simply because the development of parametric translators is still in its infancy.  Properties are stored in various elements in property sets (P-sets).  These define the performance and contextual properties via things such as weather and geologic data, and intrinsic properties including window glazing, R-values, mechanical properties, concrete reinforcing, etc.  However, tolerance and uncertainty is not covered in this data.  Also names of types of spaces are not yet standardized, which are needed for adhering to building codes and other types of analysis.  These limitations require special manual editing of properties.  Another limitation in the realm of metadata relates to manufacturing requirements.  The level of detail in shop drawings which require all the necessary information for concrete pours and steel fabrication are not yet all stored on comprehensive BIM models.  Specialized IFC software can be used to overcome this, such as Tekla Structures, which contain ever bolt, weld, plate, beam, etc., for steel structures.  

These limitations and why they exist are important to understand for both the program developers and those involved in all disciplines of building design and construction.  Most limitations exist simply because the technology is still in development, and the capabilities thus far reflect the industry’s priorities.  While many in the design and construction industry may not want to get involved in software development, the software architects are not knowledgeable enough in the industry to know what functionalities are needed.  With better understanding of the software among designers, construction managers, fabricators, etc., will yield a better product to all disciplines through more functional interoperability.  


Comments:

Comment to Dianna Vogel: I liked the angle you approached this from.  You performed a good analysis of the architecture of IFC schema structure.  As members of the building industry we traditionally have no reason to be aware of Bezier surfaces and NURBS, which I looked into a bit after and during this reading.  As BIM becomes more elementary in our field, as with all technology (smartphones, for example), we tend to not notice what goes on behind the scenes.  That’s probably okay for operating a smartphone, but when designing a system as complex as a building, whose operation is responsible for the safety of the public, we should have a good understanding of the mechanics of our tools and their limitations.

Comment to Yasmina Shields: Fascinating article you cited on the cost of omitting interoperability.  I can see how most of the savings would travel through the structure of project management directly to the owners, but the architect’s and contractor’s savings are not insignificant compared to the owners.  So on paper the owner has the largest incentive to drive innovation in interoperability, but I wonder how able they are to be impactful in that position?  The designers and contractors are who interoperability directly affects, thus know what is needed in its development.  Working in construction on my last CoOp, better interoperability from Tekla could have made a lot of our work unnecessary.  This seems to raise a separate issue: that most in our industry don’t know or some don’t care about software, and the odds are most software architects don’t particularly care for the building industry.  I think the biggest challenge to the further development of interoperability may be the collaboration of those two traditionally separate industries, and less who the burden of driving progress falls under.