Thomas Sisson - Blog Post 2 - Interoperability

Reading:

C. M. Eastman, “Chapter 3: Interoperability,” in BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers, and Contractors, 2nd ed., Hoboken, NJ: Wiley, 2011, pp. 99-150.

Interoperability, in short, is the ability for multiple disciplines to collaborate on a single model, or be able to import/export their model to another discipline without any fuss. This means that there needs to be a single backbone to every software, and every program that is used during design and construction. This single backbone can be a common library of objects used throughout a building, or just a specific way that these objects are defined and ready by the program which allows the object to behave the same way no matter what software or program it is input to. In a way, this is almost like a Rosetta stone for BIM, where each program is different, but a building model can easily be translated because there is a keystone guiding the way. Obviously, this analogy is highly flawed, since a Rosetta stone in this case would be a program to program specific translation, rather than a single standard that each program uses. The key point is the same, though, where all programs need to be able to look at the same building and offer their specific service. A key example would be a building designed in Revit, which would then need a thermal energy analysis in eQuest. Currently, the transition is bulky, and requires a specialized user of eQuest to take the Revit model and translate what they see into eQuest schematically, or in other words by scratch. The issue in this method is that if there are any changes made to the eQuest model, or the Revit model, the change must then be made in the other program. This introduces a halt in the workflow, and increases labor on both the building design, and the mechanical design. Another example is SAP2000, which uses a stick and node construction of the building to model the structural design. If the building model is changed, a specialized structural engineer must then change the SAP2000 model and the process is similarly effected. This is incredibly inefficient and a way to have the same model be translated into all three programs would greatly increase productivity and improve workflow.

Some companies are already implementing multi-disciplinary design into their program, with a key example being Autodesk. Currently, the company has modeling, BIM, drafting, utilities, structural, and mechanical programs which, while being completely proprietary, can allow easy transitions between disciplines. The issue lies within the proprietary part, since the implementation of this kind of approach would induce a single company holding all the market power. In short, if any firm wanted to optimize their design, they would need to be using Autodesk software. This induces monopolies within the industry. Ideally, a completely open source approach to BIM could solve any issues with interoperability very quickly, but such an approach would not be favorable to a profit-driven market and therefore would not survive. As such, interoperability needs to be treated as a regulation on companies, where their programs can still compete, but they need to follow a standard.

The key function of interoperability currently is certainly to improve workflow within the building industry, but the use extends much further.  The topic relevant to this course is the ability for interoperability to impact the automation of a building’s design. As noted, specialized technicians are needed to complete the various designs required to construct a building. To translate between these designs, more specialized workers are required. Interoperability right off the bat would eliminate these workers, but in the future when more and more of the actual design can be taken over by programs, interoperability would allow one program to oversee it all. Rather than have a specialized program handling the building’s structure, and another program for HVAC, instead a master building program could accomplish all of these tasks. Imagine, a single program, and your building would go from concept to final design. User input could tweak some things here or there, but this could completely change the way we go about putting up a new building. All of this is very idealistic, however, and not particularly relevant to today’s design process. Even without programs taking thousands of engineering jobs, just being able to quickly and easily get your model over to the architect and have their edits not completely ruin your design workflow would be incredibly useful.

Comments:

Abdlmalik A
I appreciate your coverage of the types of BIMs and their general uses. I was wondering if you had any thoughts on the age of the book with respect to how well it defined these tools. You talked about how the book covered the different software available today, but also what kind of models that can be generated from this software. Do you feel that this information is out-dated? I had noticed some of this, especially in the later assigned chapters.

Zac A
I almost completely forgot about the estimation side of BIM when writing my post on Interoperability. I don't have very much experience on the construction management and contractor side of BIM, so you bring up some very good points about the potential cost sink that the old method creates. My question now would be could the programs not do all of the cost estimation based off of the 3D model, rather than have someone look at it. Everything is defined in the model. Every piece, material volumes, plumbing, etc. What purpose do you think the subcontractors would serve in the estimation side if such programs were to be implemented, if they haven't been already?

Sherry L
The interaction between Architect, Engineer, etc that you highlighted seems to be a pretty common theme throughout these few chapters. You talked about how firms may be less likely to use a simple central repository for the building design documents as the learning curve may be too steep and training would cost too much. I am curious though if this will continue to be an issue for companies, since this kind of skill-set is rapidly becoming more commonplace in the industry. Will firms always be so hesitant, and when will the break-even point be where such a central design method will start to become the only economically feasible option? Personally, I think we are rapidly approaching this time, and we may see this centralized design process become common within the next five years.